United States Court of Appeals for the Federal Circuit brief.pdf · Cisco and Arista both appealed certain aspects of the Commission’s decision. Cisco Systems, Inc. v. ITC (Fed

No. 2017-2384

United States Court of Appeals for the Federal Circuit

ARISTA NETWORKS, INC., Appellee,

v.

CISCO SYSTEMS, INC., Appellant.

Appeal from the United States Patent and Trademark Office, Patent Trial and Appeal Board No. IPR2016-00309

APPELLANT CISCO SYSTEM INC.’S OPENING BRIEF

John C. O’Quinn Jason M. Wilcox C. Alex Shank

KIRKLAND & ELLIS LLP 655 15th St., N.W. Washington, D.C. 20005 (202) 879-5000

Counsel for Appellant Cisco Systems, Inc.

September 25, 2017

Case: 17-2384 Document: 20 Page: 1 Filed: 09/25/2017

U.S. Patent No. 7,224,668 Claim 1 (Appx63):

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 phys-ical network interface ports, the port services providing an ability to control and monitor packet flows, as defined by control plane configu-rations;

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 collec-tion of control plane processes in a way that is independent of the physical port interfaces and services applied thereto.


CERTIFICATE OF INTEREST

1. The full name of every party represented by us is: Cisco Systems, Inc.

2. The name of any real party in interest represented by us, and not identified in response to Question 3, is: None.

3. All parent corporations and any publicly held companies that own 10 percent or more of the stock of the parties represented by us are: None.

4. The names of all law firms and the partners or associates that appeared for the party now represented by us in the agency or are expected to appear in this Court (and who have not or will not enter an appearance in this case) are:

Sterne, Kessler, Goldstein & Fox P.L.L.C.: Robert Greene Sterne, Jon E. Wright, Lori A. Gordon, Daniel S. Block.

Dated: September 25, 2017 /s/ John C. O’Quinn

John C. O’Quinn


i

TABLE OF CONTENTS

STATEMENT OF RELATED CASES ..................................................... vii

INTRODUCTION ....................................................................................... 1

JURISDICTIONAL STATEMENT ............................................................ 5

STATEMENT OF THE ISSUES ................................................................ 5

STATEMENT OF THE CASE ................................................................... 6

I. Background ........................................................................................ 6

A. Early Attempts To Protect Switches And Routers Against Denial Of Service Attacks .......................................... 6

B. The ’668 Patent’s Invention Successfully Mitigated Denial of Service Attacks Against The Control Plane ......... 10

C. Arista Built Its Business On Extensively Copying Cisco’s Patented Technology .................................................. 14

II. Asserted Prior Art ........................................................................... 18

A. Amara ..................................................................................... 18

B. CoreBuilder ............................................................................ 20

III. Patent Trial and Appeal Board Proceedings .................................. 21

A. Arista’s Petition and Institution of Review .......................... 22

B. Cisco’s Response ..................................................................... 23

C. Final Written Decision ........................................................... 25

SUMMARY OF THE ARGUMENT ......................................................... 28

STANDARD OF REVIEW ........................................................................ 33

ARGUMENT ............................................................................................. 34

I. The Board Erroneously Construed The Claims To Not Require Application Of Both “Port Services” And “Control Plane Port Services” To All Control-Plane-Destined Packets. ........................ 34

A. The ’668 Patent’s Claims Require That “Port Services” Be Applied To All Control-Plane-Destined Packets, Independent Of And In Addition to The Application Of “Control Plane Port Services.” ............................................... 36


ii

1. The Plain Language Of The Claims Clearly Requires Normal “Port Services” Be Applied To All Packets, Including Those Destined For The Control Plane. ............................................................... 37

2. The Specification Confirms That Normal “Port Services” Must Be Applied To All Packets. ................. 41

3. The Central Advance Of The ’668 Patent Is To Apply “Control Plane Port Services” In Addition To The Normal “Port Services” Applied To All Packets. ......................................................................... 44

B. Because The Board’s Decision Rests On Its Erroneous Construction, All Of Its Obviousness Determinations Should Be Reversed. .............................................................. 51

II. The Board Separately Failed To Adequately Explain How Amara And CoreBuilder Teach “Port Services Providing The Ability To Control And Monitor Packet Flows, As Defined By Control Plane Configurations” ........................................................ 52

III. The Board Improperly Discounted Cisco’s Objective Evidence Of Nonobviousness .......................................................................... 55

A. The Board Failed To Fully Consider Cisco’s Copying Evidence ................................................................................. 57

B. The Board Failed To Fully Consider Cisco’s Evidence Of Long-Felt Need And Made Inconsistent Factual Findings .................................................................................. 62

CONCLUSION ......................................................................................... 66


iii

TABLE OF AUTHORITIES

Page(s)

Cases

Apple Inc. v. Samsung Elecs. Co., Ltd., 839 F.3d 1034 (Fed. Cir. 2016) (en banc) ............................................ 63

Ariosa Diagnostics v. Verinata Health, Inc., 805 F.3d 1359 (Fed. Cir. 2015) ............................................................ 33

Cable Elecs. Prods., Inc. v. Genmark, Inc., 770 F.2d 1015 (Fed. Cir. 1985) ............................................................ 59

Cutsforth, Inc. v. MotivePower, Inc., 636 F. App’x 575 (Fed. Cir. 2016) ........................................................ 34

In re Cyclobenzaprine Hydrochloride Extended-Release Capsule Patent Litig., 676 F.3d 1063 (Fed. Cir. 2012) ............................................................ 56

Dell Inc. v. Acceleron, LLC, 818 F.3d 1293 (Fed. Cir. 2016) ...................................................... 33, 52

Google Inc. v. Intellectual Ventures II LLC, ___ F. App’x ___, 2017 WL 2924132 (Fed. Cir. July 10, 2017) ................................. 53, 61

Hockerson-Halberstadt, Inc. v. Converse Inc., 183 F.3d 1369 (Fed. Cir. 1999) ............................................................ 36

Honeywell Int’l Inc. v. Mexichem Amanco Holdings S.A. DE C.V., 865 F.3d 1348 (Fed. Cir. 2017) ............................................................ 66

Icon Health & Fitness, Inc. v. Strava, Inc., 849 F.3d 1034 (Fed. Cir. 2017) ............................................................ 53


iv

Institut Pasteur v. Focarino, 738 F.3d 1337 (Fed. Cir. 2013) ...................................................... 60, 62

Interactive Gift Express, Inc. v. Compuserve Inc., 256 F.3d 1323 (Fed. Cir. 2001) ............................................................ 36

KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398 (2007) .............................................................................. 34

Kyocera Wireless Corp. v. ITC, 545 F.3d 1340 (Fed. Cir. 2008) ............................................................ 36

In re Man Mach. Interface Techs. LLC, 822 F.3d 1282 (Fed. Cir. 2016) ............................................................ 42

MCM Portfolio, LLC v. Hewlett-Packard Co., 812 F.3d 1284 (Fed. Cir. 2015) ............................................................ 35

Microsoft Corp. v. Proxyconn, Inc., 789 F.3d 1292 (Fed. Cir. 2015) ............................................................ 44

Millennium Pharms., Inc. v. Sandoz Inc., 862 F.3d 1356 (Fed. Cir. 2017) ...................................................... 55, 56

Motor Vehicle Mfrs. Ass’n of the U.S., Inc. v. State Farm Mut. Auto. Ins. Co., 463 U.S. 29 (1983) ................................................................................ 33

In re NuVasive, Inc., 842 F.3d 1376 (Fed. Cir. 2016) ...................................................... 33, 34

Oil States Energy Services v. Greene’s Energy Group, No. 16-712, 2017 WL 2507340 (U.S. June 12, 2017) .......................... 35

Outdry Techs. Corp. v. Geox S.p.A., 859 F.3d 1364 (Fed. Cir. 2017) ............................................................ 34

PPC Broadband, Inc. v. Corning Optical Commc’ns RF, LLC, 815 F.3d 747 (Fed. Cir. 2016) .............................................................. 36

Personal Web Techs., LLC v. Apple, Inc., 848 F.3d 987 (Fed. Cir. 2017) .................................................. 34, 53, 55


v

Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005) (en banc) ............................................ 36

Power Integrations, Inc. v. Lee, 797 F.3d 1318 (Fed. Cir. 2015) .................................................... passim

Pride Mobility Prods. Corp. v. Permobil, Inc., 818 F.3d 1307 (Fed. Cir. 2016) ...................................................... 41, 51

Rovalma, S.A. v. Bohler-Edelstahl GmbH & Co. KG, 856 F.3d 1019 (Fed. Cir. 2017) ............................................................ 34

Securus Techs., Inc. v. Global Tel*Link Corp., 685 F. App’x 979 (Fed. Cir. 2017) ........................................................ 33

Straight Path IP Grp., Inc. v. Sipnet EU S.R.O., 806 F.3d 1356 (Fed. Cir. 2015) ............................................................ 52

Teva Pharms. USA, Inc. v. Sandoz, Inc., 135 S. Ct. 831 (2015) ............................................................................ 33

Transocean Offshore Deepwater Drilling, Inc. v. Maersk Drilling USA, Inc., 699 F.3d 1340 (Fed. Cir. 2012) ............................................................ 60

Trustees of Columbia Univ. v. Symantec Corp., 811 F.3d 1359 (Fed. Cir. 2016) ............................................................ 43

In re Van Os, 844 F.3d 1359 (Fed. Cir. 2017) ............................................................ 53

Vicor Corp. v. SynQor, Inc., ___ F.3d ___, 2017 WL 3723243 (Fed. Cir. Aug. 30, 2017) ..................... 55, 61, 65, 66

VirnetX, Inc. v. Cisco Sys., Inc., 767 F.3d 1308 (Fed. Cir. 2014) ............................................................ 44

WBIP, LLC v. Kohler Co., 829 F.3d 1317 (Fed. Cir. 2016) .................................... 55, 56, 57, 59, 60


vi

West Virginia Univ. Hospitals, Inc. v. Casey, 499 U.S. 83 (1991) ................................................................................ 49

Windsurfing Int’l, Inc. v. AMF, Inc., 782 F.2d 995 (Fed. Cir. 1986) .............................................................. 57

Statutes

28 U.S.C. § 1295.......................................................................................... 5

35 U.S.C. § 141............................................................................................ 5

35 U.S.C. § 142............................................................................................ 5

35 U.S.C. § 311............................................................................................ 5

35 U.S.C. § 319............................................................................................ 5

Rules & Regulations

37 C.F.R. § 42.51 ....................................................................................... 24

37 C.F.R. § 90.3 ........................................................................................... 5


vii

STATEMENT OF RELATED CASES

No appeal has previously been taken from the proceedings below.

The Court’s decision in this appeal could affect two appeals before

this Court: Cisco Systems, Inc. v. ITC (Fed. Cir. No. 17-2289) and Arista

Networks, Inc. v. ITC (Fed. Cir. No. 17-2351). Those appeals stem from

a complaint filed by Cisco against Arista at the International Trade

Commission in December 2014, Investigation No. 337-TA-945. In its

complaint, Cisco asserted that Arista’s switches and necessary

components imported from abroad infringed numerous claims of several

Cisco patents, including U.S. Patent No. 7,224,668. On May 4, 2017, the

Commission determined that Arista’s products infringe two Cisco

patents, including the ’668 patent, but not others. This Court docketed

Cisco’s appeal of the Commission’s decision on July 11, 2017, and Arista’s

appeal of that same decision on July 27, 2017. The Court consolidated

the two appeals on August 3, 2017.

Cisco is also asserting the ’668 patent in a district court action

pending in the Northern District of California, Cisco Systems, Inc. v.

Arista Networks, Inc., Case No. 4:14-cv-05343 (N.D. Cal., filed Dec. 5,

2014). That case is stayed pending final judgment in the 945


viii

investigation and another ITC investigation discussed below.

In addition, Cisco has asserted different patents in a separate

proceeding at the ITC against Arista, Investigation No. 337-TA-944. The

accused products in both investigations are the same. The Commission

ultimately found that Arista’s products infringe three of Cisco’s patents

but not others. Cisco and Arista both appealed certain aspects of the

Commission’s decision. Cisco Systems, Inc. v. ITC (Fed. Cir. No. 16-2539);

Arista Networks, Inc. v. ITC (Fed. Cir. No. 16-2563). This Court heard

oral argument in the consolidated appeals on June 6, 2017.

Arista has filed petitions for inter partes review of certain claims of

five other Cisco patents at issue in the ITC investigations. The Patent

Trial and Appeal Board instituted review on certain claims of U.S. Patent

No. 6,377,577, and, on May 25, 2017, entered a decision finding some of

the claims patentable and others unpatentable. This Court docketed

Arista’s appeal on July 25, 2017 and Cisco’s cross-appeal on July 27,

2017. See Arista Networks, Inc. v. Cisco Systems, Inc., Nos. 17-2336, -

2347. This Court consolidated Arista’s and Cisco’s appeals of the Board’s

decision, and subsequently designated this appeal and the consolidated

’577 patent appeals as companion cases.


ix

The Patent Trial and Appeal Board instituted review on certain

claims of U.S. Patent No. 7,340,597, and, on September 28, 2016, entered

a decision finding some of the claims patentable and other claims

unpatentable. This Court consolidated Arista’s and Cisco’s appeals of the

Board’s decision. Arista filed its opening brief on May 8, 2017. Cisco filed

its opening and response brief on July 19, 2017, and Arista filed its

response and reply brief on August 30, 2017. See Arista Networks, Inc.

v. Cisco Systems, Inc., No. 17-1525; Cisco Systems, Inc. v. Arista

Networks, Inc., No. 17-1577.

The Patent Trial and Appeal Board instituted review on certain

claims of U.S. Patent No. 8,051,211, and, on October 5, 2016, entered a

decision finding some of the claims patentable and others unpatentable.

This Court consolidated Arista’s and Cisco’s appeals of the Board’s

decision. Briefing is now complete in those consolidated appeals. See

Arista Networks, Inc. v. Cisco Systems, Inc., Nos. 17-1313, 1380.

The Patent Trial and Appeal Board instituted review on some of the

claims of U.S. Patent No. 7,162,537, and, on May 25, 2017, entered a

decision finding those claims patentable. This Court docketed Arista’s

appeal of the PTAB’s decision on July 27, 2017. See Arista Networks, Inc.


x

v. Cisco Systems, Inc., No. 17-2349.

The Patent Trial and Appeal Board instituted review on a single

claim of U.S. Patent No. 7,023,853, and, on May 25, 2017, entered a

decision finding that claim patentable. This Court docketed Arista’s

appeal of the PTAB’s decision on July 27, 2017. See Arista Networks, Inc.

v. Cisco Systems, Inc., No. 17-2348. That appeal has been consolidated

with Arista’s ’537 patent appeal.


INTRODUCTION

The Patent Trial and Appeal Board invalidated forty-seven claims

of a patent directed to networking technology that protects devices

against denial-of-service attacks without adversely affecting system

performance. As explained below, the Board found all of these claims

obvious only by misinterpreting the claims and insufficiently addressing

Cisco’s validity arguments.

Denial-of-service attacks were a well-known and growing threat at

the time of Cisco’s invention, but earlier attempts to protect the network

switches and routers that form the backbone of modern networks from

such attacks all had significant drawbacks. These attempted solutions

were almost universally easy to circumvent, impractical to maintain, or

adversely affected device performance. Cisco, however, overcame these

problems through an elegant solution that routed all data packets

destined for the “control plane”—the brain in software that governs how

a network device operates, and is often the primary target of denial-of-

service attacks—through a control plane port entity irrespective of the

physical network port through which the packet entered the device. This

allowed devices to perform normal network processing for all packets at


2

the physical input ports, while reserving the additional, more resource-

intensive processing solely for packets directed to the control plane, once

they reached the control plane port entity. This technique enabled robust

denial-of-service protection that is both easy to maintain and has

minimal impact on device performance, because only packets destined to

the control plane receive additional processing at the control plane port

entity.

The Board’s obviousness determination depends entirely on an

erroneous claim construction. According to the Board, the claims permit

those packets destined for the control plane to receive “control plane port

services” at the control plane port entity without also receiving normal

“port services” at the physical input port. This interpretation deviates

from both the language of the claims and the description of the invention

in the specification. By their terms, the claims require that all packets

receive normal “port services.” Packets destined for the control plane,

thus, receive those normal services and also receive “control plane port

services,” because they additionally pass through a “control plane port

entity.” Indeed, that is what every figure, every embodiment, and every


3

discussion of the invention in the specification shows. This is no

coincidence.

As the record consistently demonstrates, several benefits of the

patented invention depend on control-plane-destined packets receiving

both types of port services. The Board’s construction, in contrast, negates

these benefits. Even under the broadest-reasonable-interpretation

standard, the Board cannot adopt a construction that departs from what

the claim language and the specification so clearly mean. That error

alone requires a remand.

The remainder of the Board’s decision is indistinguishable from

numerous recent cases in which this Court has remanded for want of a

sufficient obviousness analysis. As this Court has repeatedly reminded

the Board, the administrative-law principles that require reasoned

explanations from agencies apply with particular force to questions of

patent obviousness. Here, the Board failed to provide reasoned

explanations for the assumptions on which its decisions depended.

For instance, the PTAB fundamentally misunderstood Cisco’s

arguments concerning another disputed limitation that appears in all the

challenged claims. That caused the Board to reject arguments Cisco


4

never made, rather than evaluate the arguments Cisco actually

presented. The Board likewise rejected Cisco’s arguments that the

patented invention solved a long-felt need without acknowledging, much

less addressing, most of Cisco’s evidence. This Court has frequently

reversed the Board for just such inadequate reasoning.

Along the way, the Board entirely glossed over the compelling

evidence that Arista blatantly copied Cisco’s patented features into its

own products. As the International Trade Commission concluded in a

recent proceeding, Arista was built on a corporate culture of copying

Cisco features. Indeed, in a related proceeding, the Commission found

that Arista had copied the patented technology specifically at issue here,

while willfully blinding itself to Cisco’s ’668 patent. That culture of

copying began with Arista’s founders, who were former Cisco engineers

intimately involved in its switching business. Arista’s CEO, herself a

former Cisco executive, has thus acknowledged that “[t]here is a lot of

Cisco DNA in this company,” Appx11803, and that competing against

Cisco “in a conventional way” is “not a recipe for success” because it would

take “15 years and 15,000 engineers,” Appx11807. Instead, Arista copied

Cisco’s patented products’ functionality down to the name of the


5

infringing feature and the identical command-line expressions for

controlling that functionality. The Board nonetheless dismissed Cisco’s

copying arguments as “weak,” largely without addressing most of Cisco’s

evidence, and without appreciating the significance of that evidence.

The Court should vacate the Board’s decision that claims 1-10, 12,

13, 15-28, 30, 31, 33-36, 55-64, 66-67, and 69-72 are unpatentable and

remand for further proceedings. Once the PTAB’s legal errors are

corrected, the Board should find the claims patentable.

JURISDICTIONAL STATEMENT

The Board had jurisdiction over this inter partes review proceeding

under 35 U.S.C. § 311. It issued its final written decision on June 1, 2017.

Appx1-51. Cisco appealed the Board’s decision on August 1, 2017, and

that appeal is timely under 35 U.S.C. § 142 and 37 C.F.R. § 90.3(a)(1).

This Court has jurisdiction under 35 U.S.C. §§ 141, 319 and 28 U.S.C.

§ 1295(a)(4)(A).

STATEMENT OF THE ISSUES

1. Whether the Board erred in construing the ’668 patent’s

claims not to require that every control-plane-destined packet receive

both normal “port services,” as it enters a physical interface port, and

“control plane port services,” as it enters a control plane port entity;


6

2. Whether, by ignoring Cisco’s argument that neither Amara

nor CoreBuilder teach “monitoring packet flows, as defined by control

plane configurations,” the Board failed adequately to explain how those

references render obvious all of the challenged claims.

3. Whether the Board failed to give due weight to Cisco’s

objective evidence supporting non-obviousness, including evidence that

Arista copied Cisco’s patented technology and evidence of long-felt need.

STATEMENT OF THE CASE

The patent at issue—U.S. Patent No. 7,224,668 (Appx52-65)—

discloses a novel way to protect network devices, such as Ethernet

switches and routers, from denial-of-service (“DoS”) attacks, without

adversely affecting system performance. The Board instituted inter

partes review of several claims of the ’668 patent and ultimately

concluded those claims were obvious.

I. Background

A. Early Attempts To Protect Switches And Routers Against Denial Of Service Attacks

Switches and routers link computers, smartphones, and other

devices into a network of interconnected devices. Appx59(1:6-12);

Appx3635-3636(¶¶46-47). As data traverses the network from its source


7

to its ultimate destination, it hops from one switch to the next, with each

switch moving the data one step closer to its destination. The

convenience from networking multiple devices together also makes it

easier for an attacker to cripple the network through denial-of-service

attacks. Appx59(1:30-40); Appx3633(¶¶42-43), Appx3635-3636(¶¶46-

47). One specific form of denial-of-service attack targets the switches and

routers themselves by flooding the device with network traffic at an

extraordinarily high rate. Appx59(1:41-51); Appx3634(¶44). By

overwhelming a switch, these denial-of-service attacks prevent the

switch from routing legitimate network traffic and may ultimately cause

the switch to crash. Appx59(1:45-51); Appx3634-3636(¶¶44-48).

Successfully attacking a switch can therefore cut off an entire

organization from the Internet. Appx3635-3636(¶¶46-47).

A switch typically divides its functionality into two segments: a

“data plane” (or “transit plane”) and a “control plane.” Appx59(1:52-54);

Appx60(3:31-33); Appx3634(¶44). Switches have multiple ports through

which they connect to other devices, and the data plane is principally

responsible for forwarding network traffic from one port to another based

upon the rules specified by the control plane. Appx59(1:54-56);


8

Appx60(3:22-26); Appx3634(¶44). In that sense, the data plane performs

a device’s network functions. Appx3634(¶44). In contrast, the control

plane governs the device’s network functions. Id. That is, the control

plane is responsible for higher-level functions, such as establishing

routing tables that identify the best path between two devices, providing

a command-line interface for configuring the switch, and manipulating

access control lists. Appx59(1:56-59); Appx60(3:25-33); Appx3634(¶44).

Because of their different functions, the data and control planes

process network traffic at different rates. The data plane is designed to

handle large volumes of traffic. Appx3634(¶44). To successfully manage

that traffic, the data plane operates at “line speed,” i.e., with little delay

on a “fast path.” Id. In contrast, because a network device is relatively

rarely reconfigured, the control plane is designed to handle smaller

traffic volumes, and it processes traffic on a “slow path.” Id. It thus takes

less overall traffic directed toward the control plane, as compared to the

data plane, to overwhelm the switch, making the control plane a more

attractive target for denial-of-service attacks. Appx3635(¶45).

The ’668 patent explains that the prior art attempted to protect the

control plane against denial-of-service attacks in various ways.


9

Appx59(2:23-44); Appx3637-3638(¶¶49-52). One approach, based on

“Reverse Pass Forwarding” verification and “Selective Packet Discard”

techniques, involved selectively filtering out incoming packets whose IP

addresses were known to be associated with malicious or suspicious

activity. Appx59(2:23-31); Appx3635(¶45). That approach, however, had

a fundamental shortcoming: one had to know in advance that an IP

address was suspicious—a nearly impossible task. Appx3637(¶49).

Another approach involved identifying suspicious data based on

their packet “type,” then denying access to, limiting the ingress rate of,

or applying other complex policies to such problematic packets.

Appx59(2:32-44); Appx3637-3638(¶50); Appx3642-3643(¶58). This

approach was also inadequate. It could significantly reduce throughput

for non-control plane traffic (since policies had to be applied to every

packet over every port, regardless of whether the packet was destined for

the control plane), and these policies intended to protect the control plane

had to be deployed and maintained in each of a network’s hundreds, if

not thousands, of ports spread across multiple switches. Appx3637-

3638(¶50); Appx59-60(2:50-3:14); Appx3642-3643(¶58). Thus, before the

’668 patent’s invention, techniques for mitigating DoS attacks were


10

either ineffective or inefficient and difficult to maintain. Appx3638(¶52).

None provided a comprehensive defense against attacks aimed at

overwhelming the control plane. Id.

B. The ’668 Patent’s Invention Successfully Mitigated Denial of Service Attacks Against The Control Plane

The ’668 patent, entitled “Control Plane Security and Traffic Flow

Management,” solves the shortcomings discussed above and others. The

inventors of the ’668 patent, all Cisco employees, recognized traffic

destined for the control plane should be screened by special control plane

security policies that are independent from and in addition to the normal

policies applied by the data plane to every packet entering the switch on

a given port. Appx59-60(2:59-3:9); Appx61-62(6:65-7:15); Appx56(Fig. 4);

Appx58(Fig. 6). By making control plane processing independent from

other general processing, but not mutually exclusive from it, the ’668

patent’s invention ensures that the relatively complicated processing of

control plane packets is not also unnecessarily applied to packets moving

only through the data plane. Appx3642-3643(¶58). As a result, data-

plane “throughput performance is minimally affected because control

plane port services are applied if and only if a packet is first determined

to have a control plane destination.” Appx63(9:6-9); Appx3642-


11

3643(¶58). And by making control plane processing truly independent,

such processing need not be done at every port—it is done in addition to

the normal data plane port services defined in the physical network

interface ports and only at the control plane port entity. Appx60(4:8-13).

Figure 1 (below) shows an illustrative embodiment of the ’668

patent’s invention. Appx53(Fig. 1); Appx60(4:47-49).

The ports 120 are “network connections” through which packets are

input into or output from the device. Appx60(4:51-53); Appx61(5:5-7).

Those ports, the line cards, and the central switch engine make up the

data plane, and are responsible for forwarding “transit” (i.e., data-plane)

packets. Appx61(5:5-9). Data packets received from the ports 120 are


12

fed from the line cards to the central switch engine. Appx60(4:55-58).

The central switch engine then performs “normal input port services”—

such as access control filtering or quality of service processing—on every

packet it receives. Appx61-62(6:65-7:18); Appx63(9:23-25); Appx3639-

3640(¶55). In the embodiments described in the specification, it is only

after applying these normal port services to the packet that the central

switch engine determines whether the packet is destined for the control

plane. This is illustrated in Figure 4 from the specification:

Appx56(Fig. 4). If the packet is not destined for the control plane, the

central switch engine routes the packet to the appropriate output port,


13

typically at “high speed.” Appx60(4:56-58); Appx61(5:5-9); Appx61(5:34-

36).

All packets destined for the control plane are instead passed from

the central switch engine to a special control plane port entity. This

access path to the collection of control plane processes provided by the

control plane port entity is central to the ’668 patent’s goal of providing a

tool for processing control-plane-destined packets that is independent of,

but not mutually exclusive from, the normal processing of all packets that

occurs at the physical input/output ports of the device. Appx61(5:36-40);

Appx60(4:65-67); see also Appx60(3:48-50); Appx60(4:58-60). By having

control-plane-destined packets pass through a designated control plane

port entity, “a set of port services unique to the control plane may be

applied” to such packets, “ensur[ing]” that such “control plane port

services” are applied only to “packets entering and exiting each of the

control plane processes.” Appx60(3:54-58) (emphasis added);

Appx61(5:53-6:1); Appx61(6:39-44) (“transit packets will not invoke

control plane port services, but will continue to invoke normal input and

output port services”). Because the “control plane port [] can be treated

as a traditional hardware port,” the specification further explains that “a


14

full range of traditional port control features can be applied to help

protect the control plane [] from a DoS attack.” Appx61(5:66-6:3).

For example, a network administrator could set a rule limiting the

rate at which a certain type of packet is fed to the control plane.

Appx61(6:8-23). For a packet entering such a device, “port input services

are applied to the port,” “a switching decision is made in the data plane,”

and, “if and only if [the] packet has been first determined to have a

destination of the control plane,” then the rate-limiting rule is “applied

by the control plane services” to the control plane port entity, rather than

to the physical port. Id.; Appx62(7:13-14) (“the control plane port 140

then performs the aggregate control plane port services on the packet”).

Any packets that exceed the rate limit are discarded before reaching the

control plane and potentially overwhelming its processing capabilities.

Appx61(6:18-23).

C. Arista Built Its Business On Extensively Copying Cisco’s Patented Technology

Cisco for years has incorporated the technology of the ’668 patent

into its products and marketed the advantages of that technology to its

customers. Appx3669(¶102); Appx3757-3772. In particular, a hardware-

based feature in some Cisco devices, dubbed control plane policing


15

(“CoPP” or “CPP”), “protects the control plane and separates it from the

data plane, which ensures network stability, reachability, and packet

delivery.” Appx3757-3772; Appx4475. Through CoPP, for instance, users

can

configure a Quality of Service (QoS) filter that manages the traffic flow of control plane packets to protect the control plane of Cisco routers and switches against reconnaissance and Denial of Service (DoS) attacks allowing the Control Plane (CP) to maintain packet forwarding and protocol states despite an attack or heavy load on the router or switch.

Appx6343; see also Appx5540. CoPP, building off of the ’668 patent’s

innovative technology, offers this protection by using an independent

control plane port that is the sole point of access for the control plane

services on Cisco’s 7500 series, Nexus 7000 series, and Catalyst 6500

series switches. Appx3763-3768; Appx3774; Appx5541; Appx6344;

Appx6363.

In 2004, years after Cisco developed the technology claimed in the

’668 patent, David Cheriton and Andreas Bechtolsheim left Cisco with at

least thirteen other former Cisco employees to found Arista. Appx13235-

13236; In re Certain Network Devices, Related Software and Components

Thereof(I), Inv. No. 337-TA-944, USITC Pub. 575521 at 134 (Mar. 11,


16

2016) (Initial Determination) (“944 Investigation”), available at Fed. Cir.

Appeal No. 16-2563, ECF No. 133 (Corrected Appendix) (A888.143-.145).

Dr. Cheriton, Mr. Bechtolsheim, and their colleagues built Arista’s

business largely by copying Cisco’s technology. As Arista’s CEO,

Jayshree Ullal, admitted with remarkable candor, she “had a big hand in

shaping Cisco’s enterprise switching strategy, and it helped me

appreciate what to do and what not to do.” Appx11809-11810; see also

Appx11802 (“There is a lot of Cisco DNA in” Arista). The International

Trade Commission, in its ruling that Arista infringed a different patent,

found this reliance on Cisco’s DNA fostered a “corporate culture of

copying” Cisco. In re Certain Network Devices, Related Software and

Components Thereof (I), Inv. No. 337-TA-944, U.S.I.T.C. Pub. No. 609119

at 20 (Apr. 19, 2017) (Commission Op.), available at Fed. Cir. Appeal No.

16-2563, ECF# 133 (Corrected Appendix) (A566.020).

Arista’s strategy of copying rather than innovating extended to

Cisco’s CoPP technology. Appx3669(¶102); Appx3757-3768. In its ruling

that Arista infringed the ’668 patent, the ITC affirmed that Arista

“copied” the “patented features of Cisco’s products and marketed those

features to its customers.” In re Certain Network Devices, Related


17

Software and Components Thereof (I), Comm’n Op., Inv. No. 337-TA-945,

2017 WL 3614521, at *63 (June 1, 2017). The copying of Cisco’s patented

CoPP technology was in fact so endemic that Arista copied the name of

the feature (like Cisco, Arista calls its control plane security technology

“Control Plane Policing”) and even copied verbatim many of Cisco’s multi-

word command-line expressions for configuring the CoPP functionality:

Cisco’s Command-Line Expressions

Arista’s Command-Line Expressions

“class-map type control-plane” Appx9291

“class-map type control-plane” Appx10680

“policy-map type control-plane” Appx9301

“policy-map type control-plane” Appx10693

“show policy-map control-plane” Appx9372-9373

“show policy-map control-plane” Appx10718

“show policy-map interface con-trol-plane” Appx9301

“show policy-map interface con-trol-plane” Appx10722

“copp-system-policy” Appx9294; Appx9436

“copp-system-policy” Appx10621

Default CoPP policy configuration

“copp-system-class-[traffictype],” where the “traffictypes” include: • igmp • arp • lacp • lldp • bgp

Default CoPP policy configuration

“copp-system-[traffictype],” where the “traffictypes” include: • igmp • arp • lacp • lldp • bgp


18

• glean • default • 13dest-miss • ospf • isis • excp-ttl Appx9294-9295

• glean • default • 13destmiss • OspfIsis • l3ttl1 Appx10623; Appx10628; Appx10635; Appx10639-10640; Appx10647; Appx10652; Appx10654-10655; Appx10657; Appx10659-10660; Appx10662; Appx10666; Appx10668; Appx10671-10672; Appx10705; Appx10707-10708; Appx10710; Appx10712-10713

II. Asserted Prior Art

Two prior art systems for protecting routers and switches against

denial-of-service attacks are relevant here: (1) U.S. Patent No. 6,674,743

to Amara (Appx872-880); and (2) the CoreBuilder 3500 Implementation

Guide (Appx997-1588).

A. Amara

Amara describes methods and systems for a packet-forwarding

device, such as a switch or router. Appx872; Appx3643(¶59). Figure 3,

depicting the internal architecture of such a device, is illustrative:


19

Appx875(Fig. 3); Appx878(5:52-53); Appx3643-3644(¶60). Interfaces

202-206 transmit and receive packets by way of nodes 208-212.

Appx878(5:53-55). Packet classifiers 214-218 classify packets received

from the interfaces as either “internally-destined” or “external.”

Appx878(5:55-58); Appx3643-3644(¶60). This classification occurs before

any policies are applied. Appx3644(¶61).

External and internally destined packets are sent to separate, and

mutually exclusive, policy engines for further processing. Id. External

packets are forwarded to packet forwarder 222 via policy engines 224-

228, which apply “a set of rules specifying the manner in which a given

packet should be handled” if the packet “match[es] certain predefined

criteria.” Appx878(5:14-16); Appx878(5:60-62); Appx878(6:12-14). In


20

contrast, internally destined packets are forwarded to a special internal

policy engine 232, but never pass through policy engines 224-228.

Appx878(5:56-6:16); Appx3644(¶61). Policy engine 232 applies its own

unique set of policies to the internally destined packets destined for

internal applications 230. Appx878(6:9-12). Thus, unlike the ’668 patent,

internally directed packets do not also receive the normal processing that

externally directed packets do.

B. CoreBuilder

CoreBuilder is a user guide for “configuring, using, and managing”

the CoreBuilder 3500 system. Appx1017. One management interface in

CoreBuilder is the “Administration Console,” a menu-drive command-

line interface embedded in the system software. Appx1024-1025;

Appx1028; Appx1031. A network administrator can configure a variety

of settings for the CoreBuilder system through the Administration

Console, such as settings for Ethernet interfaces, IP addresses, and

certain “packet filters.” Appx1068; Appx1206; Appx1253. Packet

filtering allows a switch to make a “permit-or-deny” decision for each

packet based on its contents. Appx1206. By configuring packet filters,


21

an administrator can “improve LAN performance, shape traffic flows, or

implement security controls.” Appx1026; Appx1205-1252.

III. Patent Trial and Appeal Board Proceedings

Arista petitioned for inter partes review of the ’668 patent on

several grounds. Appx74-75. As relevant here, Arista challenged

independent claims 1, 19, and 55 (plus several dependent claims) as

obvious over Amara and CoreBuilder. Id. Claim 1 exemplifies the

relevant claim language:

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 configu-rable by control plane processes;

b. port services, for operating on packets entering and exiting the physical network interface ports, the port ser-vices providing an ability to control and monitor packet flows, as defined by control plane configurations;

c. a control plane, comprising a plurality of internet-working control plane processes, the control plane pro-cesses 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


22

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 phys-ical port interfaces and services applied thereto.

Appx63(9:17-40) (emphasis added). The other asserted grounds relied on

adding other art to the combination of Amara and CoreBuilder to chal-

lenge various dependent claims. Appx74-75. Based on Arista’s petition

and Cisco’s preliminary patent owner response, the Board instituted re-

view of the ’668 patent’s claims. Appx2; Appx203-226.1

A. Arista’s Petition and Institution of Review

In its petition, Arista asserted that Amara’s policy engines 224-228

execute “port services,” its policy engine 232 executes “control plane port

services,” and its internal applications 230 are “control plane processes.”

Appx87-88(Fig. 3); Appx96-98; Appx101-103; Appx216-217. Arista

further contended that CoreBuilder’s “packet filters” provide for the

ability to “control and monitor packet flows, as defined by control plane

1 Relying on many of the same references, Arista twice unsuccessfully petitioned for inter partes review of the ’668 patent prior to the petition in this case. Arista Networks, Inc. v. Cisco Systems, Inc., IPR2015-00974, Paper 2 (P.T.A.B. filed Apr. 1, 2015); Arista Networks, Inc. v. Cisco Systems, Inc., IPR2015-01710, 2016 WL 1083023, at *1 (P.T.A.B. Feb. 16, 2016).


23

configurations,” specifically identifying “logging” packets as a way to

“monitor” packet flows. Appx98-99 (emphasis added).

B. Cisco’s Response

After institution, Cisco filed its patent owner response on the

merits. Cisco explained that the art recognized problems caused by

denial-of-service attacks, the “serious limitations” of prior-art approaches

to addressing those attacks, and the ’668 patent’s introduction of a

“novel” solution for mitigating attacks against the control plane.

Appx280-288. As part of that solution, the ’668 patent’s claims require

that packets destined for the control plane are necessarily operated on by

normal “port services” as they enter a physical port, and additionally by

“control plane port services” if they are identified as destined for the

control plane. Appx292-299. Cisco showed that Amara failed to disclose

applying both “port services” and “control plane port service[]” on control-

plane-destined packets, since “Amara’s ‘policy engines 224-228’ operate

solely on external packets and are therefore incapable of operating on

control plane packets.” Appx299-302 (emphasis added) (citing Appx3657-

3659(¶¶81-84)).


24

Cisco separately argued that the combination of Amara and

CoreBuilder failed to teach “port services providing the ability to control

and monitor packet flows, as defined by control plane configurations,”

because CoreBuilder’s packet filters—Arista’s only support for “defined

by control plane configurations”—do not “log” (i.e., “monitor”) packet

flows. Appx306-307.

Cisco further asserted that objective evidence—including Arista’s

blatant copying, long-felt need, and the failure of others—confirmed the

patentability of the ’668 patent’s claims. Appx332-343. Cisco highlighted

the publicly available evidence of Arista’s copying, Appx338-343;

Appx3669(¶102). But Cisco could not provide the PTAB with the full

record of Arista’s copying developed in the ITC proceeding because Arista

designated that material—and even the fact that evidence relevant to

copying existed—confidential. Cf. 37 C.F.R. § 42.51(b)(1)(iii) (in IPR

proceedings, “[u]nless previously served, a party must serve relevant

information that is inconsistent with a position advanced by the party

during the proceeding concurrent with the filing of the documents or

things that contain the inconsistency”). Cisco also presented evidence

that the art recognized the need to prevent denial-of-service attacks


25

against the control plane before Cisco’s invention of the patented

technology, and that others had previously tried and failed to develop a

workable solution.

C. Final Written Decision

In its final written decision, the Board found all of the challenged

claims (claims 1-10, 12-13, 15-28, 30, 31, 33-36, 55-64, 66-67, and 69-72)

obvious.

Claim Construction. Each of the challenged independent claims

requires that “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.” Appx8-12 (emphasis added);

Appx63(9:36-41) (claim 1); Appx63(10:43-54) (claim 19); Appx65(13:23-

34) (claim 55). The Board agreed with Cisco that the claimed control-

plane-destined packets must be “received from specific, predetermined

physical ports” (these are the “physical port interfaces” referenced in

limitation d.ii). The Board further recognized that “port services” must

be applied at physical port interfaces, as required by limitation b.

Appx10.


26

The Board, however, did not recognize the significance of those

conclusions, id., namely that packets destined for the control plane must

receive both normal port services (because they enter a physical port),

and control plane port services (because they enter the control plane port

entity). Instead, it concluded that the claims do “not impose an

affirmative requirement that port services be applied at the physical port

interface to every packet” destined for the control plane. Id.; Appx11-12.

Amara and CoreBuilder. The Board reviewed claims 1-6, 8, 9, 15-

22, 24-27, 33-36, 55-58, 60-63, and 69-72 and found them obvious over

Amara and CoreBuilder, based on its conclusion that packets destined

for the control plane need not receive both normal port services and

control plane port services. Appx19. In so doing, the Board also rejected

Cisco’s argument that, even under the Board’s construction, neither

Amara nor CoreBuilder taught or suggested another claim limitation

common to all of the challenged claims: “monitor[ing] packet flows, as

defined by control plane configurations.” Appx24-25 (emphasis added);

Appx63(9:23-27); Appx63(10:39-42); Appx64(11:62-65); Appx65(13:19-

22). The Board found it was enough that Amara taught “the ability to ...

monitor packet flows,” without addressing whether Amara and


27

CoreBuilder disclose controlling such monitoring through control plane

configurations. Appx24-25.

The Remaining Claims. The Board found the remaining dependent

claims obvious over Amara and CoreBuilder in combination with other

art. Appx35; Appx45. Each of these findings depended on the Board’s

conclusion that Amara and CoreBuilder render independent claims 1, 19,

and 55 obvious.

Objective Indicia of Nonobviousness. The Board found that a long-

felt need existed for better ways to manage DoS attacks. Appx27-28. It

also found a sufficient nexus between the CoPP feature of Cisco’s

products and the ’668 patent’s claims. Appx28-30. But it nonetheless

found that Cisco had not addressed whether solutions before Cisco’s

invention or Cisco’s invention itself satisfied that need. Appx28; Appx30.

The Board made no findings as to whether Arista’s products

actually embody Cisco’s claims. Instead, the Board found that, “even

assuming that Arista’s products embody the limitations of the challenged

claims” and that Arista copied Cisco’s CoPP feature name and command-

line expressions, that was still “not sufficient evidence to show that

[Arista] copied the functionality claimed in the ’668 patent.” Appx33


28

(emphasis added). It reached that conclusion despite the fact that those

command-line expressions are how users configure and control the

patented “functionality” of Cisco’s CoPP. Nor did it address the fact that,

like Cisco, Arista uses “Control Plane Policing” to “prioritize[] control

plane and management traffic and limit[] the rate of CPU bound control

plane traffic to prevent denial of service traffic.” Appx6419. The Board

also said nothing of Arista’s conceded incorporation into its EOS of the

“operational look and feel” of Cisco’s IOS. Appx11809. And it declined to

make any findings on Arista’s access to Cisco’s products embodying the

’668 patent’s invention.

This appeal follows.

SUMMARY OF THE ARGUMENT

I. All Control-Plane-Destined Packets Must Receive Both “Port

Services” And “Control Plane Port Services.” The Board erroneously

construed the ’668 patent’s claims not to require that that both normal

“port services” and “control plane port services” be applied to all control-

plane-destined packets. Each claim requires (i) “physical network

interface ports” to which “port services, for operating on packets entering

and exiting” those ports are applied, and (ii) a “control plane port entity”


29

to which “control plane port services” are applied, where the control plane

port services “operate on packets received from” the physical interface

ports “in a way that is independent of the physical port interfaces and

services applied thereto.” The claims do not limit which “packets”

entering a “physical network interface port” receive “port services”—all

such packets do. And because all control-plane-destined packets are

received from “physical ports,” they also receive “port services,”

independent from (but not mutually exclusive with) the receipt of “control

plane port services.” By their terms, the claims thus require that all

control-plane-destined packets receive both “port services” (when they

enter a physical network interface port) and “control plane port services”

(when they enter the control plane port entity).

The specification confirms that reading. Its embodiments describe

that control-plane-destined packets receive control plane port services

only “after port input services” have been applied, and every disclosed

example identifies control-plane-destined packets receiving both types of

services. It also explains how the requirement furthers the invention’s

purpose of mitigating harm caused by control-plane-focused DoS attacks

without compromising data-plane throughput—by allowing normal input


30

“port services” to be applied to all packets, while independently applying

“control plane port services” only to control-plane-destined packets.

The Board erroneously construed the claims otherwise by

effectively reading into them a limitation that only “some packets”

entering the physical ports receive normal “port services.” But the claims

do not say “some.” The Board further erred by misunderstanding the

patent’s central advance and by myopically reading a single line of the

specification, divorced from context. Because all of the Board’s

obviousness determinations depended on finding that Amara disclosed

“control plane services operat[ing] on packets … in a way that is

independent of the physical port interfaces and services applied thereto”

only under the Board’s erroneous construction, its decision must be

vacated and remanded.

II. Neither Amara Nor CoreBuilder Teach Monitoring Packet

Flows “As Defined By Control Plane Configurations.” The Board

separately failed to adequately explain how Amara and CoreBuilder

teach “port services providing the ability to control and monitor packet

flows, as defined by control plane configurations.” Although Cisco focused

its patentability arguments on that second requirement, the Board never


31

evaluated those arguments and instead rejected one that Cisco never

made. That cannot be reasoned decision-making. Both the Board and

Arista concede that Amara does not disclose using a control plane to

configure “monitoring packet flows.” And CoreBuilder cannot fill that

gap: Arista identified only one example of “monitoring packet flows”—

“logging” packets—but CoreBuilder nowhere discloses configuring its

packet filters to perform such “logging.” By ignoring Cisco’s arguments

on that front, the Board’s decision lacks the necessary findings to

facilitate judicial review or to support its obviousness determination.

That independently requires vacatur and remand.

III. Objective Indicia of Nonobviousness. The Board further erred

by relegating Cisco’s objective evidence of nonobviousness to secondary

status, particularly as to copying and long-felt need. The Board properly

found that Cisco’s CoPP-enabled switches embodied the claimed

invention. And Cisco presented evidence that Arista both had access to

those switches—many of Arista’s engineers and executives worked at

Cisco during the development and patenting of the ’668 patent’s

technology—and that Arista specifically engineered its products to allow

its customers to configure functionality identical to Cisco’s patented


32

technology using identical command-line expressions. That behavior

aligned with Arista’s admitted copying of Cisco’s products’ “look and feel”

and with the ITC’s ultimate finding of pervasive copying. Not only did

the Board skip over Cisco’s evidence, shirking its responsibility to

address all adequately developed patentability arguments, it failed to

fulfill its obligations under this Court’s precedents to consider whether

that evidence supported an inference of copying. Those errors alone

require a remand.

Moreover, despite finding a long-felt need to prevent denial-of-

service attacks, the Board determined that the ’668 patent did not fulfill

a long-felt need for two reasons: Cisco purportedly did not introduce

evidence showing that no earlier solution existed, or that its commercial

products satisfied that need. The Board again reached those conclusions

by overlooking Cisco’s evidence and arguments. Both Cisco and its expert

identified and explained the inadequacies of earlier attempts to defend

against DoS attacks. And both explained how the CoPP functionality in

Cisco’s products “elegant[ly]” protected the control plane against DoS

attacks in way that earlier solutions could not. The Board never

acknowledged, much less addressed, that evidence and argument. That,


33

and the Board’s internally inconsistent treatment of other evidence of

long-felt need, independently requires vacatur and remand.

STANDARD OF REVIEW

This Court reviews the Board’s claim constructions de novo where,

as here, those constructions turn on intrinsic evidence. Teva Pharms.

USA, Inc. v. Sandoz, Inc., 135 S. Ct. 831, 840-41 (2015); Dell Inc. v.

Acceleron, LLC, 818 F.3d 1293, 1298 (Fed. Cir. 2016). It reviews the

Board’s legal conclusion of obviousness de novo and reviews any

underlying factual findings for substantial evidence. Ariosa Diagnostics

v. Verinata Health, Inc., 805 F.3d 1359, 1364 (Fed. Cir. 2015).

The Court reviews final agency action for compliance with the

Administrative Procedure Act. Dell, 818 F.3d at 1298. Under the APA,

an agency must provide “a satisfactory explanation for its action

including a rational connection between the facts found and the choice

made.” Motor Vehicle Mfrs. Ass’n of the U.S., Inc. v. State Farm Mut.

Auto. Ins. Co., 463 U.S. 29, 43 (1983); In re NuVasive, Inc., 842 F.3d 1376,

1381-82 (Fed. Cir. 2016); Securus Techs., Inc. v. Global Tel*Link Corp.,

685 F. App’x 979, 987 (Fed. Cir. 2017). That includes addressing the

“important aspect[s] of the problem” presented to it. State Farm, 463


34

U.S. at 43. And it includes “straightforwardly and thoroughly

assess[ing]” each party’s “critical” arguments. Power Integrations, Inc. v.

Lee, 797 F.3d 1318, 1334-35 (Fed. Cir. 2015).

The need for specificity applies with particular force to agency’s

analysis of obviousness, which “should be made explicit,” include

“articulated reasoning with some rational underpinning,” and “cannot be

sustained by mere conclusory statements.” KSR Int’l Co. v. Teleflex Inc.,

550 U.S. 398, 418 (2007); Outdry Techs. Corp. v. Geox S.p.A., 859 F.3d

1364, 1370 (Fed. Cir. 2017) (the Board must “explain why it accepts the

prevailing argument”); Rovalma, S.A. v. Bohler-Edelstahl GmbH & Co.

KG, 856 F.3d 1019, 1025 (Fed. Cir. 2017); Personal Web Techs., LLC v.

Apple, Inc., 848 F.3d 987, 991-92 (Fed. Cir. 2017); NuVasive, 842 F.3d at

1381-82; Cutsforth, Inc. v. MotivePower, Inc., 636 F. App’x 575, 577-78

(Fed. Cir. 2016).

ARGUMENT

I. The Board Erroneously Construed The Claims To Not Require Application Of Both “Port Services” And “Control Plane Port Services” To All Control-Plane-Destined Packets.

Each of the challenged claims requires (i) “physical network

interface ports,” where “port services, for operating on packets entering


35

and exiting the physical network interface ports” are applied and (ii) a

“control plane port entity” where “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.”

Appx63(9:17-40). By their terms, the claims thus require that all control-

plane-destined packets receive both “port services” (because they

necessarily come from “physical ports”), and also “control plane port

services” (because they also pass through a “control plane port entity”).

By failing to read the claims as a whole and by taking a myopic view of

selected specification sentences, the Board erroneously construed the

claims not to have that requirement. That alone requires remand.2

2 In Oil States Energy Services v. Greene’s Energy Group, No. 16-712, the Supreme Court granted certiorari on the question of “[w]hether inter partes review … violates the Constitution by extinguishing private property rights through a non-Article III forum without a jury.” Pet. for Writ of Certiorari at i, Oil States Energy Servs., LLC v. Greene’s Energy Grp., LLC, No. 16-712 (filed Nov. 23, 2016), available at 2016 WL 6995217. Here, Cisco’s patent was invalidated under the same inter partes review procedures challenged as unconstitutional in Oil States. However, panels of this Court are bound by circuit precedent, foreclosing such a challenge. See MCM Portfolio, LLC v. Hewlett-Packard Co., 812 F.3d 1284, 1290-93 (Fed. Cir. 2015). Although Cisco supports the IPR process and believes it is constitutional, Cisco reserves its rights to


36

A. The ’668 Patent’s Claims Require That “Port Services” Be Applied To All Control-Plane-Destined Packets, Independent Of And In Addition to The Application Of “Control Plane Port Services.”

Claim construction begins with the language of the claims. Phillips

v. AWH Corp., 415 F.3d 1303, 1314 (Fed. Cir. 2005) (en banc); Interactive

Gift Express, Inc. v. Compuserve Inc., 256 F.3d 1323, 1331 (Fed. Cir.

2001). In determining the meaning of a particular claim term, this Court

“does not interpret [that term] in a vacuum, devoid of the context of the

claim as a whole.” Kyocera Wireless Corp. v. ITC, 545 F.3d 1340, 1347

(Fed. Cir. 2008). Instead, the Court recognizes that “[p]roper claim

construction … demands interpretation of the entire claim in context, not

a single element in isolation,” Hockerson-Halberstadt, Inc. v. Converse

Inc., 183 F.3d 1369, 1374 (Fed. Cir. 1999), read in view of the

specification. PPC Broadband, Inc. v. Corning Optical Commc’ns RF,

LLC, 815 F.3d 747, 751, 755 (Fed. Cir. 2016) (an “interpretation must be

reasonable in light of the claims and specification”). Here, the Board’s

erroneous construction of “the control plane port services … and services

applied thereto” stemmed from its fundamental misunderstanding of the

advance arguments, at an appropriate point in this proceeding, based on the Supreme Court’s decision.


37

interaction between related claim elements, as well as its failure to

appreciate why the independence of “port services” and “control plane

port services”—key to the ’668 patent’s invention—requires that all

control plane destined packets receive both types of services.

1. The Plain Language Of The Claims Clearly Requires Normal “Port Services” Be Applied To All Packets, Including Those Destined For The Control Plane.

Despite the plain language of the claims, the Board failed to

recognize that each packet entering the ’668 patent’s physical interface

ports necessarily receives normal “port services.” That, in turn, led the

Board to erroneously construe the claims in a manner that did not require

application of such “port services” to all control-plane-destined packets.

Appx10-12. However, the ’668 patent’s claims, read in view of the

specification, require otherwise: that all control-plane-destined packets

receive both normal “port services” and, independently, “control plane

port services.”

Claim 1, of course, envisions the claimed device having two

independent, but not mutually exclusive, functional planes: a first plane,

which, like conventional data planes, comprises “physical network

interface ports” and “port services”; and a second “control plane,” which


38

is accessed via a “control plane port entity” to which “control plane port

services” are applied. Appx63(9:17-41). Element d requires that the set

of “control plane port services” be applied to packets at the “control plane

port entity,” not the physical interface ports, and requires that they be

applied “independent” of what occurs with the packets received at the

physical port interfaces. Appx63(9:32-41).

Critically, the claim elements show that all packets destined for the

control plane necessarily receive “port services” and then, independent

from that, “control plane port services.” Element b requires that all

packets “entering and exiting the physical network interface ports”

receive normal “port services.” The Board’s approach, however, reads

that limitation out as applied to packets destined for the control plane

port entity. That makes no sense. Element b does not qualify or limit

the “packets” to which it applies. By its terms, element b requires that

“port services” operate—without qualification—on all packets “entering

and exiting the physical network interface ports,” regardless of whether

control plane port services may later be applied. It does not say “some

packets.” Neither do the parallel limitations in method claims 19 and 55,

which require “executing port services on packets entering and exiting


39

the physical network interface ports.” Appx63(10:39-40); Appx65(13:19-

20). This language again reinforces that normal port services operate on

every packet moving through the physical network interface ports

without exception.

Nor can there be any doubt that packets destined for the control

plane are received through the “physical network interface ports” that

must receive the port services required by element b. Rather, element

d.ii of claim 1 makes clear that packets “destined to the collection of

control plane processes” must be received from “physical ports,” in

addition to which they have “control plane port services operate on” them.

Appx63(9:36-39). In other words, because the packets must come

through a physical port before receiving control plane port services, they

must receive the normal “port services” that all packets that come

through a physical port receive (or at the very least have the capability

to receive). Were it otherwise, then the application of “control plane port

services” would not be truly “independent” of the “physical port interfaces

and services applied,” as element d.ii expressly requires. Appx63(9:36-

41). Application of the control plane port services would be dependent on

the decision not to apply normal port services.


40

In line with the foregoing, the Board concluded that “services

applied thereto” in element d.ii of claim 1 refers to the “port services” in

element b, which are “for operating on packets entering and exiting the

physical network interface ports.” Appx10. The Board also concluded

that element d.ii requires each control-plane-destined packet first be

received by a “physical port interface.” Id. But the Board went astray in

failing to read elements b and d.ii together: Because all control-plane-

destined packets are received by a “physical network interface port,” and

each “physical network interface port” applies “port services” to each

packet, every control-plane-destined packet must receive “port services.”

Although control plane port services are applied independently, that does

not render element b inapplicable merely because a packet is destined for

the control plane.

Indeed, the claims’ description of what “port services” do reinforces

that those services must be applied to all packets entering the device’s

physical ports, regardless of whether they will additionally (and

independently) receive control plane port services. Specifically, the

claims require that “port services” “provid[e] an ability to control and

monitor packet flows.” Appx63(9:23-25); see Appx63(10:40-41);


41

Appx65(13:20-21). That “controlling and monitoring” of packet flows

encompasses the fundamental ability to turn a port “on” or “off” with

respect to receiving or outputting packets. The claims thus require that

at least some “port services” are applied to each packet passing through

a “physical network interface port.”

2. The Specification Confirms That Normal “Port Services” Must Be Applied To All Packets.

Consistent with the claims, the specification summarizes the

invention as follows: “With the control plane being treated as a

traditional port, rules can be established using the method according to

the invention that is enforced after port input services and the switching

decision has been made. These rules are supplied if and only if the packet

has been first determined to have a destination of a control plane.”

Appx63(9:1-6) (emphasis added); see also Appx61(6:13-16) (similar). As

described below, the specification’s repeated identification of control-

plane-destined packets as receiving both normal “port services” and

“control plane port services” confirms that all control-plane-destined

packets must receive both services (or at minimum have the capability to

receive both services). The specification thus confirms what the claims

already make clear. See Pride Mobility Prods. Corp. v. Permobil, Inc.,


42

818 F.3d 1307, 1314 (Fed. Cir. 2016); In re Man Mach. Interface Techs.

LLC, 822 F.3d 1282, 1287 (Fed. Cir. 2016).

For example, figures 4 and 6 show that “the packet” entering the

device is first “receive[d]” by a port on a “line card.” Appx56(Fig. 4);

Appx61(6:65-67); Appx58(Fig. 6); Appx62(8:3-7). Normal “port services”

are then applied to each entering packet. The specification explains that,

in embodiments with a centralized switching architecture, the central

switch engine “performs normal input port services and Quality of

Services (QoS) processing on the received packet.” Appx61-62(6:67-7:2).

Packets destined for the control plane cannot skip this step. Rather, “all

packets destined to the control plane [] must pass through the central

switch engine [] prior to being routed to the functions [] in the control

plane.” Appx61(5:37-41). Likewise, in embodiments with a distributed

switching architecture, a “distributed switch engine performs normal

input port services and quality of service processing” for each packet

received by its associated line card. Appx62(8:7-9).

There is a reason normal port services are applied to each packet

entering the device regardless of its destination. When packets enter the

physical port and are processed by the switch engine, the device is


43

agnostic as to whether the received packet is destined for the control

plane. Appx56(Fig. 4); Appx58(Fig. 6). It is only after performing normal

“port services” that the central switch engine “determines if the packet is

destined to the [control plane]”:

Appx56(Fig. 4); Appx62(7:3-12); see also Appx58(Fig. 6); Appx62(8:10-

12). Then, only after a packet is determined to be destined for the control

plane, does “the control plane port … perform[ ] the aggregate control

plane port services on the packet.” Appx62(7:13-14); see also

Appx62(8:12-24). Indeed, there is no path depicted in Figure 4 by which

a packet can reach the control plane without first having normal “port

services” applied. Trustees of Columbia Univ. v. Symantec Corp., 811


44

F.3d 1359, 1364 (Fed. Cir. 2016) (“[T]he patentee’s choice of preferred

embodiments can shed light on the intended scope of the claims.”).

Thus, all packets—whether or not destined for the control plane—

receive the normal “port services” applied at the physical network

interface ports, and also independently receive control plane port

services. That is exactly how every disclosed example works. See

Appx61(5:34-40); Appx61(6:12-16); Appx61-62(6:65-7:18); Appx62(8:7-

12); Appx63(9:1-6); see generally Appx56(Fig.4); Appx58(Fig. 6); Appx61-

62(6:65-7:2); Appx62(8:7-24). There is simply no basis for ignoring these

clear statements about what the claimed invention requires. See, e.g.,

Microsoft Corp. v. Proxyconn, Inc., 789 F.3d 1292, 1299 (Fed. Cir. 2015);

VirnetX, Inc. v. Cisco Sys., Inc., 767 F.3d 1308, 1317 (Fed. Cir. 2014).

3. The Central Advance Of The ’668 Patent Is To Apply “Control Plane Port Services” In Addition To The Normal “Port Services” Applied To All Packets.

The Board’s approach—treating application of normal “port

services” as mutually exclusive from “control plane port services”—

fundamentally misunderstands not only what the claims require but also

how the ’668 patent advanced the art. The ’668 patent did not advance

the art by departing from the application of normal “port services” to


45

packets entering a device’s physical input ports regardless of their

ultimate destination. Instead, the key insight is the ability to

independently apply “control plane port services” only to packets

destined for the control plane. As Cisco’s expert, Dr. Almeroth,

explained, “[b]y applying input port services to incoming traffic, the ’668

patent provides the flexibility needed to allow normal input port services

to be applied to traffic received on any port of the device, while allowing

control-plane-specific policies to be independently applied solely to traffic

intended for the control plane.” Appx3642(¶58). The invention of the

’668 patent thus protects the control plane from denial-of-service attacks

without sacrificing administrative convenience or data-plane throughput

precisely because it applies “port services” to all packets entering its

physical ports and independently applies “control plane port services”

only to control-plane-destined packets.

Before the ’668 patent’s invention, both normal port services and

control plane services (in devices that used them) were applied to packets

whether the packet was destined to the control plane or not. Appx59-

60(2:23-3:2); see also Appx3637-3638(¶¶49-52). This significantly slowed

data throughput, and required updates for port services be applied at all


46

ports, consuming substantial device resources. Appx59-60(2:23-3:2);

Appx3637-3638(¶¶49-52) (having to execute “additional control plane

classes and policies” “for transit packets as well as control plane destined

packets,” “markedly reduced” “overall transit traffic performance” and

could “hinder proper operation” of the system). For example, in “Reverse

Pass Forwarding” verification and “Selective Packet Discard,” every

packet was subjected to a filter to determine whether it was associated

with a suspicious IP address. Appx59-60(2:23-31); Appx3637(¶49). And

other techniques to fend off denial-of-service attacks similarly applied

access lists, class maps, and related policies to each packet entering every

interface of a device, to provide limited protection to the control plane.

Appx59(2:32-39); Appx59(2:50-58); Appx3637-3638(¶50).

To be sure, a device could attempt to overcome these shortcomings

by processing control-plane-destined packets and ordinary network

traffic on separate, mutually exclusive paths. But the ’668 patent further

recognized this would cause some of the very same administrability

problems that plagued the prior art. See Appx3639(¶54). The separate,

control-plane-only processing path would need to duplicate the normal

port services rules applied at any of the many physical input ports on a


47

typical switch. Appx59(2:55-58) (noting “there may typically be

hundreds, if not thousands of ports in even a modest network”).

Duplicating these rules would often require more than simply copying

each rule verbatim. That is because the normal-port-services rules

applied at one physical port can differ from those applied at a different

physical port. The control plane variants of those rules thus would likely

need to be modified to account for the fact that they should only apply to

traffic received from specific ports, even though control plane port

services are applied to traffic received from every port. It is thus simply

not feasible for a network administrator to maintain and update the same

or similar rules in multiple places. See id. The process is too time

consuming and error prone.

The Board dismisses all of these key insights by misreading a single

sentence in the specification. Appx11-12. The Board fundamentally

misunderstood the specification’s statement that “[s]ince control plane

150 destined packets will invoke only control plane services, transit

traffic and system performance is minimally impacted. That is, transit

packets will not invoke control plane port services, but will continue to

invoke normal input and output port services.” Appx61(6:38-43). The


48

Board reads the first part of that statement to teach that in some

instances packets destined for the control plane will have control plane

port services applied without also receiving normal port services. But

context proves otherwise—the statement is emphasizing the

performance benefits from not applying control plane port services to

most network traffic.

The rest of the specification illustrates that the Board’s reading of

this isolated statement cannot be correct. Take the sentence immediately

following the statement the Board latches onto. Starting with “That is,”

words indicating the specification is clarifying its previous statement,

this sentence explains the upshot of the previous sentence is that transit

packets passing through the device claimed in the ’668 patent “will not

invoke control plane port services.” Appx61(6:41-43) (“That is, transit

packets will not invoke control plane port services, but will continue to

invoke normal input and output port services.”). Moreover, the

statement the Board relies upon is describing the same embodiment the

specification two paragraphs earlier explained applies control plane port

services “after port input services are applied.” Appx61(6:12-16). The

Board thus reads the specification to describe the same embodiment in


49

two different, irreconcilable ways. But this Court and the Board should

strive “to make sense rather than nonsense out of the” words of the

specification. West Virginia Univ. Hospitals, Inc. v. Casey, 499 U.S. 83,

101 (1991).

That the Board misread the one sentence upon which its entire

construction depends is in fact evident from the sentence itself, the point

of which is that the claimed invention has “minimal[] impact” on “transit

traffic.” Appx61(6:38-41). Whether control-plane-destined packets

receive normal port services in addition to control plane port services is

irrelevant to normal transit traffic. Rather, as discussed above, the

performance benefits of the invention for transit traffic comes from not

applying unnecessary control plane port services to that traffic. Appx59-

60(2:59-3:1); Appx3637-3638(¶50); Appx3642-3643(¶58).

The Board nonetheless insists its reading of the specification is the

correct one because otherwise the invention “would deprive a user of

control over the flow of traffic destined to the control plane.” Appx11 n.3

(citing Appx61(6:37-39)). The Board again misreads the specification.

The “significant control over the flow of traffic destined to the control

plane” the ’668 patent affords users comes from its decision to treat the


50

control plane “as an addressable single port.” Appx61(6:12-13);

Appx61(6:37-39). By treating the control plane port entity like a

traditional physical port, users can employ the full range of traditional

port control features to protect the control plane from denial-of-service

attacks and prioritize particular classes of packets. Appx61(5:66-6:2);

Appx61(6:24-31); see generally Appx61(5:66-6:39).

This differentiates the ’668 patent from prior art techniques that

relied upon more limited, specialized control plane protection

mechanisms that are unable to provide the flexibility of the full range of

traditional port services, not only to maintain security but also to

guarantee quality of service. Appx62(8:51-67). For example, Figure 5

provides not only the ability to rate limit telnet packets destined to the

control plane, but also prioritizes trusted addresses so that an

administrator may still “connect to the router, even while it is under

attack, since the rate limit and access list would permit the session

connected from the trusted host while rate limiting other connectors.”

Appx61(6:24-32); Appx62(7:22-61). None of this, however, depends on

applying control plane port services to some packets destined for the

control plane without also applying normal port services.


51

In sum, the ’668 patent was an improvement over the prior art, not

by making normal “port services” and “control plane port services”

mutually exclusive, but by continuing to apply normal “port services” to

all packets, while taking a flexible approach to permit the additional,

“independent” application of “control plane port services” only to those

packets that are determined to be destined for the control plane. The

claim language in element b, supported by the specification, shows that

the ’668 patent’s claims affirmatively require application of “port

services” to all packets entering a “physical port interface.” The Board’s

misreading of a single sentence in the specification cannot “support a

departure from what the claim language and the specification so clearly

mean.” Pride Mobility, 818 F.3d at 1314.

B. Because The Board’s Decision Rests On Its Erroneous Construction, All Of Its Obviousness Determinations Should Be Reversed.

Each of the Board’s obviousness determinations depended on its

decision that Amara disclosed the “control plane services operate on

packets … in a way that is independent of the physical port interfaces

and services applied thereto” limitation under its erroneous construction.

It never addressed in the alternative whether Amara discloses this


52

limitation under the construction Cisco proposed. Appx23-24. Because

the Board did not consider the issue, the Court should remand for the

Board to consider in the first instance whether Amara discloses this

limitation under the correct construction. See Dell, 818 F.3d at 1300;

Straight Path IP Grp., Inc. v. Sipnet EU S.R.O., 806 F.3d 1356, 1363-64

(Fed. Cir. 2015). Cisco is confident that the Board will conclude it does

not.

II. The Board Separately Failed To Adequately Explain How Amara And CoreBuilder Teach “Port Services Providing The Ability To Control And Monitor Packet Flows, As Defined By Control Plane Configurations”

Each of the challenged claims separately requires “port services

providing an ability to control and monitor packet flows, as defined by

control plane configurations.” Appx63(9:22-26); Appx63(10:39-42)

(materially similar); Appx65(13:19-22) (same). The PTAB fundamentally

misunderstood Cisco’s arguments concerning this limitation, which

caused the Board to reject arguments Cisco never made rather than

evaluate the arguments Cisco actually presented. This is exactly what

this Court has said the Board cannot do. See Power Integrations, Inc. v.

Lee, 797 F.3d 1318, 1323-25 (Fed. Cir. 2015) (holding the PTAB “failed to

provide a full and reasoned explanation for its decision” where “a


53

significant portion of the Board’s opinion is devoted to rejecting an

argument that [the party] never made”); Google Inc. v. Intellectual

Ventures II LLC, ___ F. App’x ___, 2017 WL 2924132, at *6 (Fed. Cir. July

10, 2017) (reversing Board for failing to “acknowledge, let alone address

[an] argument”). As in Power Integrations and Google, when the Board’s

action is “insufficiently or inappropriately explained,” this Court has

consistently remanded for further proceedings. In re Van Os, 844 F.3d

1359, 1362 (Fed. Cir. 2017); see also, e.g., Icon Health & Fitness, Inc. v.

Strava, Inc., 849 F.3d 1034, 1042-44, 1047 (Fed. Cir. 2017); Personal Web,

848 F.3d at 992. It should do so again here.

The “port services” limitation, by its terms, requires (i) “an ability

to control and monitor packet flows” and (ii) that the manner in which

the port services perform this monitoring and control be “defined by

control plane configurations.” Appx63(9:22-26). Cisco’s invalidity

arguments focused on the second requirement. Appx306-307.

In its patent owner response, for instance, Cisco argued that Arista

“failed to show that the combination of Amara and CoreBuilder teaches

or suggest[s] configuring policies for ‘monitor[ing] packet flows.’”

Appx307 (emphasis added); see also Appx3661-3662(¶¶88-89). Although


54

Amara discloses logging packets received at an input port, it does not

disclose using the control plane to configure how that logging is

performed, Appx3661(¶88)—a point Arista and the Board both concede,

Appx90; Arista Networks, Inc. v. Cisco Systems, Inc., IPR2015-00974,

Institution Decision at 13-14 (PTAB Feb. 16, 2016). Nor can CoreBuilder,

and its disclosure of configuring a packet filter through an

Administration Console, fill this gap. Appx306-307. CoreBuilder’s

packet filters do not log packets, and that reference accordingly nowhere

discloses configuring the packet filters to do so. Appx3662(¶89). Absent

that disclosure, CoreBuilder cannot teach using control plane

configurations to define policies for monitoring packet flows under the

only example of “monitor[ing] packet flows” that Arista identified,

namely logging the packets. Appx306-307; Appx3662(¶89).

Rather than address that argument, the Board, at Arista’s urging,

evaluated whether Amara’s logging policies “teach[] a ‘port service[]

providing the ability to … monitor packet flows.’” Appx25 (quoting

Appx63(9:22-26)); see also Appx513. The Board concluded that it did,

which is unsurprising since Cisco never argued otherwise. Appx24-25.

Having rejected an argument Cisco never made, the Board failed to make


55

any findings about whether Amara and CoreBuilder teach the “as defined

by control plane configurations” limitation. Id.

The Board’s silence on that issue requires a remand for the Board

to consider Cisco’s arguments. See Vicor Corp. v. SynQor, Inc., ___ F.3d

___, 2017 WL 3723243, at *11 (Fed. Cir. Aug. 30, 2017); Power

Integrations, 797 F.3d at 1323-25. Without findings on the “as defined

by control plane configurations” limitation, the Board’s decision lacks the

necessary findings to facilitate meaningful judicial review or to support

a determination that the challenged claims are obvious. Power

Integrations, 797 F.3d at 1323-25; Personal Web, 848 F.3d at 991-92. The

Board did not find that any other references rendered this limitation

obvious, and Arista never even asked the Board to do so.

III. The Board Improperly Discounted Cisco’s Objective Evidence Of Nonobviousness

The Board also gave Cisco’s objective evidence of nonobviousness

inadequate consideration. “Secondary considerations,” or “objective

indicia of nonobviousness,” constitute one of the four Graham factors and

are an indispensable part of any obviousness analysis. WBIP, LLC v.

Kohler Co., 829 F.3d 1317, 1328 (Fed. Cir. 2016); Millennium Pharms.,

Inc. v. Sandoz Inc., 862 F.3d 1356, 1367 (Fed. Cir. 2017). Objective


56

evidence “play[s] an important role as a guard against the statutorily

proscribed hindsight reasoning in the obviousness analysis” and “may

often be the most probative and cogent evidence in the record.” WBIP,

829 F.3d at 1328; see also Millennium, 862 F.3d at 1368; In re

Cyclobenzaprine Hydrochloride Extended-Release Capsule Patent Litig.,

676 F.3d 1063, 1076 n.3, 1079-80 (Fed. Cir. 2012). Despite the recognized

importance of such objective evidence, this Court has frequently needed

to remind trial courts, agencies, and litigants that such evidence may not

be “relegate[d] to ‘secondary status’” in an obviousness analysis.

Cyclobenzaprine, 676 F.3d at 1078.

This proceeding is yet another example of the Board’s

inappropriately low regard for objective evidence for two separate and

independent reasons. First, under a proper analysis, the evidence of

Arista’s blatant copying should have been compelling. It is indisputable

that Arista copied Cisco’s patented technology down to the command-line

expressions and even the name of the patented feature. Yet the Board

gave this evidence little weight for legally irrelevant reasons. Second,

Cisco presented virtually unrebutted evidence of a long-felt need for the

patented technology and the failure of others to develop an efficient and


57

practical way protect the control plane from denial-of-service attacks.

The Board rejected these arguments by ignoring Cisco’s evidence and

adopting internally inconsistent findings. Any one of these errors is

enough to warrant a remand for the Board to reconsider its obviousness

analysis.

A. The Board Failed To Fully Consider Cisco’s Copying Evidence

Copying a “claimed invention, rather than one within the public

domain, is indicative of non-obviousness.” Windsurfing Int’l, Inc. v. AMF,

Inc., 782 F.2d 995, 1000 (Fed. Cir. 1986); WBIP, 829 F.3d at 1336. And

this is a quintessential copying case. The ITC has already found as much.

Certain Network Devices, 2017 WL 3614521, at *63-64.

Mr. Bechtolsheim and Dr. Cheriton were in senior engineering

positions at Cisco when they left with at least thirteen other former Cisco

employees to found Arista, a company that exclusively sells network

switches. Appx13235-13236; Appx13239-13243; Appx13245. Arista soon

added another employee, its current CEO, who is the former head of

Cisco’s switching business unit and “shap[ed] Cisco’s enterprise

switching strategy.” Appx11809-11810; see also Appx11802-11804;

Appx13241. Arista leveraged this knowledge of Cisco’s products into a


58

business built on copying Cisco’s technology. Appx11803 (“There is a lot

of Cisco DNA in” Arista). Arista’s CEO acknowledged this culture of

copying quite bluntly, explaining that “[w]here we don’t have to invent,

we don’t.” Appx11809.

Arista’s culture of copying extended to Cisco’s CoPP functionality,

which the Board found is a commercial embodiment of the invention

claimed in the ’668 patent, Appx28-30. Like Cisco’s CoPP-enabled

switches, Arista’s products “prioritize[ ] control plane and management

traffic and limit[ ] the rate of CPU bound control plane traffic to prevent

denial of service traffic.” Appx6419; see also Appx10662-10665. Dr.

Almeroth mapped Arista’s implementation of this capability onto both

the independent claims of the ’668 patent and the relevant features of

Cisco’s CoPP-enabled devices. Appx3669(¶102); Appx3757-3772. The

similarities identified by Dr. Almeroth are not a coincidence. Arista

designed its products to compete against Cisco’s offerings, with its

customers reporting that “they appreciate the way they can leverage

their deep [Cisco] experience [to] easily upgrade … to Arista.”

Appx11813; Appx11809 (Arista anticipates former Cisco customers can

start using Arista’s devices “right away”); Appx11776.


59

In addition to the functional similarities between the two

companies’ products, Arista has publicly acknowledged that it copied the

“operational look and feel” of Cisco’s devices. See, e.g., Appx11814

(“Arista CLI commands same as Cisco IOS.”). The commands to

configure Arista’s identically named “Control Plane Policing”

functionality copy the commands to configure equivalent functionality in

Cisco’s devices word-for-word. See supra, pp. 17-18. Copying Cisco’s look

and feel to invoke the same control plane policing functions as in Cisco’s

products thus allows Arista’s customers to configure functionality

identical to Cisco’s patented CoPP technology using identical command-

line expressions.

Arista’s behavior exemplifies the type of conduct that strongly

suggests the ’668 patent was far from obvious. See WBIP, 829 F.3d at

1336 (“The fact that a competitor copied technology suggests it would not

have been obvious.”). This Court has often recognized that a party’s

access to a product embodying the claimed invention, and its subsequent

production of substantially similar devices, “create[s] a strong inference

of copying.” Cable Elecs. Prods., Inc. v. Genmark, Inc., 770 F.2d 1015,

1027 (Fed. Cir. 1985), overruled on other grounds by Midwest Indus., Inc.


60

v. Karavan Trailers, Inc., 175 F.3d 1356 (Fed. Cir. 1999); see also WBIP,

829 F.3d at 1336-37; Institut Pasteur v. Focarino, 738 F.3d 1337, 1347

(Fed. Cir. 2013); Transocean Offshore Deepwater Drilling, Inc. v. Maersk

Drilling USA, Inc., 699 F.3d 1340, 1352 (Fed. Cir. 2012). Here, Arista

had far more than access to Cisco’s CoPP-enabled switches. Many of

Arista’s engineers and executives worked at Cisco when it developed and

patented the ’668 patent’s technology. Appx13235-13236; Appx13239-

13243; Appx13245. And there is more than an inference of copying here.

A jury found Arista copied at least Cisco’s user interfaces—a finding that

remains highly relevant even though the jury also found Arista was not

liable for that copying as a matter of copyright law because the scènes à

faire doctrine excused its copying. Appx1943. Whether Arista’s copying

is unlawful under the copyright laws does not detract from the fact that

there was actual copying here, which is what this Court has treated as

relevant.

The Board wrote off Cisco’s copying evidence as “very weak”

because “[n]either the feature name nor the command-line expressions

are claimed in the ’668 patent.” Appx33. That misses the point. Arista’s

copying of these features is powerful proof that Arista copied every aspect


61

of Cisco’s CoPP technology down to the smallest detail. Indeed, there is

little reason to copy Cisco’s CoPP command-line expressions unless

Arista also copied the underlying functionality.

Regardless, the Board failed to consider the combined weight of the

evidence that:

i. Arista copied at least these aspects of Cisco’s technology;

ii. Arista’s products embody the independent claims of the ’668 patent;

iii. Arista’s products have features that are at the very least substantially similar to the relevant features of Cisco’s CoPP-enabled devices; and

iv. Arista was founded by former Cisco employees familiar with Cisco’s proprietary switching technology.

The Board did not even address Cisco’s evidence that Cisco’s and Arista’s

products are functionally similar, if not identical, and that Arista’s em-

ployees are deeply familiar with Cisco’s technology. Appx33. By skipping

over this evidence, the Board shirked its responsibility under the APA to

address all adequately developed arguments in favor of patentability.

See Vicor, 2017 WL 3723243 at *11; Google, 2017 WL 2924132 at *5 (va-

cating PTAB decision where the Board failed to “explain why it consid-

ered [certain] evidence unconvincing”). For similar reasons, the Board

likewise did not fulfill its obligation under this Court’s obviousness cases


62

to consider whether Arista’s access to Cisco’s patented technology and the

similarity between the two companies’ products supports an inference of

copying. See, e.g., Institut Pasteur, 738 F.3d at 1348. The Court should

remand for the Board to perform the analysis the APA and this Court’s

obviousness precedents both require.

B. The Board Failed To Fully Consider Cisco’s Evidence Of Long-Felt Need And Made Inconsistent Factual Findings

Separating the “control plane port services” applied to control-

plane-destined packets from the normal “port services” applied to all

packets satisfied a long-felt need. After emerging in the 1990s, denial-

of-service attacks proliferated rapidly, causing increasing disruption at a

time when society was becoming more dependent on networking

technology. Appx59(1:21-29); Appx3635-3636(¶¶46-48); Appx3638(¶51);

Appx13202; Appx13218-13223; Appx13232-13234. For example, during

one week in October 2002, a coordinated attack caused seven of the

thirteen servers managing global Internet traffic to fail. Appx59(1:25-

29). Earlier attempts to protect the control plane against such attacks—

such as the techniques discussed in the specification—all had “significant

shortcomings.” Appx3637-3638(¶¶49-52); see also supra, pp. 8-10. These


63

attempted solutions were almost universally easy to circumvent,

impractical to maintain, or adversely affected switch performance.

Appx59-60(2:23-3:13); Appx3637-3638(¶¶49-52).

The ’668 patent solved these problems, as Dr. Almeroth explained

to the Board, by “directly mitigating the root of certain DoS attacks—

their reliance on directing traffic to the control plane—in an elegant

fashion that did not make configuration difficult.” Appx3639(¶54);

Appx3642-3643(¶58). As discussed above, the ’668 patent achieves this

remarkable advance over the prior art by applying “port services” to all

packets entering the physical ports and also, independently, applying

“control plane port services” only to the control-plane-destined packets.

This elegant solution to a longstanding problem further confirms the

challenged claims are not obvious. See Apple Inc. v. Samsung Elecs. Co.,

Ltd., 839 F.3d 1034, 1056 (Fed. Cir. 2016) (en banc). “[I]t is reasonable

to infer the need would not have persisted had the solution been obvious.”

Id.

Despite finding a long-felt need to prevent denial-of-service attacks

existed at the time of Cisco’s invention, Appx27-28, the Board determined

that the ’668 patent did not fulfill a long-felt need for two separate


64

reasons: Cisco supposedly introduced no evidence establishing that

earlier solutions did not exist and no evidence that its commercial

products in fact fulfill the need. Both determinations suffer from the

same basic flaw. The Board reached those conclusions by once again

overlooking Cisco’s evidence and arguments.

The Board first faulted Cisco for supposedly never “address[ing]”

whether “the need was [ ] satisfied earlier by another.” Appx27-28. But

Cisco and Dr. Almeroth identified earlier attempts to defend against such

attacks—including Reverse Pass Forwarding verification, Selective

Packet Discard, and access control lists applied to all incoming packets—

and explained why those solutions were inadequate. Appx3637-

3638(¶¶49-52); Appx280; Appx283-284 (section entitled “[e]xisting

approaches to addressing DoS attacks had serious limitations”). Nothing

in principle or precedent required Cisco to do more, especially where

Arista did not dispute the shortcomings of these earlier approaches. See

Appx529.

The Board committed the same mistake again when finding that

Cisco “ha[d] not shown that its commercial embodiments satisfy the

aforementioned long-felt need.” Appx30 (“Patent Owner does not assert


65

that its [commercial products] satisfied the long-felt need to protect

against DoS attacks.”). As the Board found, the CoPP functionality in

Cisco’s commercial products is coextensive with the claims of the patent.

Appx28-30; Appx3669(¶102); Appx3757-3772. Cisco and Dr. Almeroth,

in turn, explained how the invention described in those claims

“elegant[ly]” protects the control plane against denial-of-service attacks

in a way that previous solutions could not. Appx3639(¶54); Appx3642-

3643(¶58); Appx280; Appx284-288 (section entitled “[t]he ’668 patent

presents the novel solution to handling DoS attacks”). The Board never

acknowledges, let alone addresses this evidence and argument. Appx30.

For that reason alone, the Court should remand for the Board to consider

Cisco’s evidence and its impact on the Board’s obvious analysis. Vicor,

2017 WL 3723243 at *11; Power Integrations, 797 F.3d at 1325.

But the Board further erred by finding that a Cisco document

“describ[ing] DoS attacks as problems as recently as March 2013”

undermined Cisco’s claim that the ’668 patent satisfied a long-felt need.

Appx30. That document describes the continuing threat from denial-of-

service attacks generally, without mentioning attacks directed

specifically at the control plane. See Appx1986-2002. When addressing


66

Cisco’s evidence concerning the failure of others, however, the Board

dismissed evidence “focused on DoS attacks generally rather than efforts

to protect the control plane” as largely irrelevant. Appx31 (giving such

evidence “little weight”). The Board offered no explanation for these

inconsistent conclusions regarding the weight afforded to evidence

addressing denial-of-service attacks in general. Id.

This Court has twice recently reversed the Board for just such

unexplained, “internally inconsistent” findings. Honeywell Int’l Inc. v.

Mexichem Amanco Holdings S.A. DE C.V., 865 F.3d 1348, 1354 (Fed. Cir.

2017); Vicor, 2017 WL 3723243 at *10-11. So too here, the Court should

remand for the Board to either adopt a consistent position or offer “some

reasoned basis” for its seemingly irreconcilable conclusions. Vicor, 2017

WL 3723243 at *11.

CONCLUSION

For the foregoing reasons, the Court should vacate the Board’s

decision and remand for further proceedings.


67

September 25, 2017 Respectfully submitted, /s/John C. O’Quinn

John C. O’Quinn Jason M. Wilcox C. Alex Shank KIRKLAND & ELLIS LLP 655 15th St., N.W. Washington, D.C. 20005 (202) 879-5000

Counsel for Appellant Cisco Systems, Inc.


ADDENDUM

Final Written Decision ................................................................. Appx1-51

U.S. Patent No. 7,224,668 .......................................................... Appx52-65


[email protected] Paper 52 571-272-7822 Entered: June 1, 2017

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, MIRIAM L. QUINN, and MATTHEW R. CLEMENTS, Administrative Patent Judges.

CLEMENTS, Administrative Patent Judge.

FINAL WRITTEN DECISION 35 U.S.C. § 318(a) and 37 C.F.R. § 42.73

Appx000001


IPR2016-00309 Patent 7,224,668 B1

2

I. INTRODUCTION 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.”).

On June 11, 2016, we instituted an inter partes review of claims 1–10,

12, 13, 15–28, 30, 31, 33–36, 55–64, 66, 67, and 69–72 of the ’668 patent.

After institution of trial, Patent Owner filed a Patent Owner Response (Paper

18, “PO Resp.”) and Petitioner filed a Reply (Paper 33, “Pet. Reply”).1

Petitioner relies on the Declaration of Dr. Bill Lin (Ex. 1002). Patent Owner

relies on the Declaration of Dr. Kevin C. Almeroth (Ex. 2006).

Petitioner filed a Motion to Strike (Paper 41) to which Patent Owner

filed an Opposition (Paper 48).

Patent Owner filed a Motion to Strike Petitioner’s Reply (Paper 42) to

which Petitioner filed an Opposition (Paper 44).

An oral hearing was held on March 7, 2017. Paper 49 (“Tr.”).

The Board has jurisdiction under 35 U.S.C. § 6. In this Final Written

Decision, issued pursuant to 35 U.S.C. § 318(a) and 37 C.F.R. § 42.73, we

determine that Petitioner has met its burden of showing, by a preponderance

of the evidence, that all of the claims for which trial was instituted are

unpatentable. Petitioner’s Motion to Strike is dismissed-as-moot. Patent

Owner’s Motion to Strike is dismissed-as-moot.

1 Patent Owner’s Motion to Seal (Paper 20) and Petitioner’s Motion to Seal (Paper 35) were granted in our Order of May 7, 2017 (Paper 51).

Appx000002


IPR2016-00309 Patent 7,224,668 B1

3

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 and IPR2015-01710. 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 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. DoS attacks were commonly directed at the control plane. Id. at 1:59–

67. Attempts to solve such problems were difficult to administer and could

Appx000003


IPR2016-00309 Patent 7,224,668 B1

4

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.

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

Appx000004


IPR2016-00309 Patent 7,224,668 B1

5

between central 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 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 quality of service (“QoS”).

Id. at 5:1–4, 5:66–6:44.

C. Illustrative Claim

Of the challenged claims, claims 1, 19, 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

Appx000005


IPR2016-00309 Patent 7,224,668 B1

6

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.

D. Evidence Relied Upon

Petitioner relies upon the following references:

Amara US 6,674,743 B1 Jan. 6, 2004 Ex. 1004Moberg US 6,460,146 B1 Oct. 1, 2002 Ex. 1005Subramanian US 6,970,943 B1 Nov. 29, 2005 Ex. 1006Hendel US 6,115,378 Sept. 5, 2000 Ex. 10073Com, COREBUILDER 3500 IMPLEMENTATION GUIDE, 3Com MSD Technical Publications, November 1999 (“CoreBuilder”)

Ex. 1009

Pet. 2–3. Petitioner also relies upon the Declaration of Dr. Bill Lin (“Lin

Decl.”) (Ex. 1002).

E. The Instituted Grounds of Unpatentability

We instituted inter partes review based on the following grounds:

References Basis Claims challengedAmara & CoreBuilder § 103 1–6, 8, 9, 15–22, 24–27,

33–36, 55–58, 60–63, and 69–72

Amara, CoreBuilder, & Moberg § 103 7, 23, and 59

Appx000006


IPR2016-00309 Patent 7,224,668 B1

7

References Basis Claims challengedAmara, CoreBuilder, & Hendel § 103 10, 12, 13, 28, 30, 31, 64,

66, and 67

Dec. 23.

II. ANALYSIS

A. 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).

Applying that standard, we interpret the claim terms according to their

ordinary and customary meaning in the context of the 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. In our Decision on

Institution, we construed only “specific, predetermined ports,” which we

determined “encompasses all ports of the networking device, and is not

limited to a subset of ports.” Dec. 8. Apart from Patent Owner alluding to

its Preliminary Response (PO Resp. 11), neither party contested or addressed

our construction of these terms.2 Accordingly, we see no reason to modify

our prior determination in light of the record developed at trial.

2 We previously instructed Patent Owner that “any arguments for patentability not raised in the [Patent Owner Response] will be deemed waived.” Paper 7, 3; see also 37 C.F.R. § 42.23(a) (“Any material fact not specifically denied may be considered admitted.”); In re Nuvasive, 842 F.3d 1376, 1379-1382 (Fed. Cir. 2016) (holding Patent Owner waived argument

Appx000007


IPR2016-00309 Patent 7,224,668 B1

8

“[O]nly those terms need be construed that are in controversy, and

only to the extent necessary to resolve the controversy.” Vivid Techs., Inc. v.

Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999)). The parties

dispute the meaning of “the control plane port services operate on packets

. . . in a way that is independent of the physical port interfaces and services

applied thereto.” Compare PO Resp. 16–22, with Pet. Reply 2–7.

Accordingly, we construe that phrase expressly.

“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”

Patent Owner argues that “[b]ased on the plain meaning of the claims,

both port services and control plane port services are applied to control plane

packets.” PO Resp. 17. Petitioner counters that “[t]he Challenged Claims

do not require both ‘port services’ and ‘control plane port services’ be

applied to control plane packets.” Pet. Reply 2. For the reasons discussed

below, we agree with Petitioner.

a. Claim language

First, based on the language of the claims, Patent Owner contends that

“services applied thereto” refers to “packets received from specific,

predetermined physical ports and destined to the collection of control plane

processes.” PO Resp. 17–18. According to Patent Owner, “the control

plane packets first pass through the ‘specific, predetermined physical ports’

addressed in Preliminary Response by not raising argument in the Patent Owner Response).

Appx000008


IPR2016-00309 Patent 7,224,668 B1

9

and ‘port services’ are ‘applied thereto.’ Then the control plane packets

enter the ‘control plane port entity’ where ‘control plane ports services’

operate [execute] on the packets.” Id.

Petitioner counters that “services applied thereto” refers to the

services, if any, applied to the recited “physical port interfaces,” not to the

“packets . . . destined to the collection of control plane processes,” and

provides the following annotated claim element:

Pet. Reply 3–4. According to Petitioner, “the term ‘thereto’ acts as a

modifier in identifying to what the recited ‘services’ are applied. Because

the object ‘physical port interfaces’ comes immediately before this phrase,

grammar dictates that the term ‘thereto’ references ‘physical port

interfaces.’” Id. at 4. Petitioner contends that “the ‘physical port interfaces’

are what the recited ‘services’ are applied to” and that “this reading is the

only one that removes all ambiguity as to what type of ‘services’ are referred

to in the ‘services thereto’ portion of 1 d.ii—i.e., normal port services.” Id.

at 5. As a result, according to Petitioner, the limitation “requires the control

plane port services to operate on packets in a way that is independent of any

port services that have been applied to a physical port interface, but does not

require a packet to receive normal port services as a prerequisite to receiving

control plane port services.” Id. at 4.

Appx000009


IPR2016-00309 Patent 7,224,668 B1

10

We agree with Petitioner. The most natural reading of “thereto” is as

a reference to “physical port interfaces” that immediately precedes it in the

limitation. Moreover, we understand “the physical port interfaces” to have

its antecedent basis in the “specific, predetermined ports” recited earlier in

the claim, and we understand “services” to mean the “port services, for

operating on packets entering and existing the physical network interface

ports” recited earlier in the claim. As a result, we agree with Patent Owner

that packets destined for the control plane processes are “received from

specific, predetermined physical ports,” but we do not agree that the claim

language itself requires port services be applied to every packet received on

a physical port. The claim does not recite, for example, “port services, for

operating on every packet entering and exiting the physical network

interface ports.” After considering the parties’ arguments, we find that the

language of this limitation requires that the operation of the “control plane

port services” be “independent of” the physical port interfaces and services

(if any) applied to those interfaces, but does not impose an affirmative

requirement that port services be applied at the physical port interface to

every packet “received from specific, predetermined physical ports and

destined to the collection of control plane processes.”

b. Specification

Patent Owner argues that the Specification describes applying control

plane port services “after, and in addition to, normal input port services.”

PO Resp. 19 (citing Ex. 1001, 9:1–4, 6:12–15). According to Patent Owner,

“the only embodiments described in the specification . . . apply port services

to control plane packets.” Id.; see also id. at 19–22 (identifying description

of applying port services to control plane packets in both the aggregated

Appx000010


IPR2016-00309 Patent 7,224,668 B1

11

control plane services embodiment and the distributed control plane services

embodiment).

Petitioner counters that the ’668 patent “explicitly recognizes that

some packets entering a physical network interface port will not receive

normal port services, but will receive control plane port services, if they are

destined for the control plane.” Pet. Reply 2–3 (footnote omitted) (emphasis

added) (citing Ex. 1001, 6:38–423 (“Since control plane 150 destined

packets will invoke only control plane services, transit traffic and system

performance is minimally impacted.”)). Petitioner also argues that the

Specification “refers to services being applied to ports.” Id. at 5 (citing Ex.

1001, Abstract, 3:54–56, 4:8–12, 6:12–16, 10:24–25, 11:45–46). Finally,

Petitioner argues that Patent Owner is attempting to import a preferred

embodiment into the claim language. Id. at 6–7.

Again, we agree with Petitioner. There is no doubt that the ’668

patent discloses embodiments in which control plane port services are

applied after, and in addition to, normal input port services, as Patent Owner

contends. We are not persuaded, however, that the claims are limited to

3 At oral argument, Patent Owner argued Petitioner takes this statement out of context. Tr. 72:20–73:13. Even when considering this sentence in the context of the whole paragraph, however, we are not persuaded it is merely a typographical error (i.e., a misplacement of “only” in front of “control plane services” instead of in front of “control plane 150 destined packets”). The preceding sentence, for example, states that “the user is afforded significant control over the flow of traffic destined to the control plane 150 just as if the control plane 150 were a hardware interface.” Ex. 1001, 6:37–39. Patent Owner’s interpretation, however, would deprive a user of control over the flow of traffic destined to the control plane by requiring that such traffic always receive normal port services before being forwarded to the control plane 150.

Appx000011


IPR2016-00309 Patent 7,224,668 B1

12

these embodiments for the reasons discussed above in our analysis of the

claim language. Moreover, our analysis of the claim language is consistent

with the Specification’s disclosure that “[s]ince control plane 150 destined

packets will invoke only control plane services, transit traffic and system

performance is minimally impacted.” Ex. 1001, 6:39–42 (emphasis added).

For all of the foregoing reasons, we determine that the challenged

claims do not require both “port services” and “control plane port services”

be applied to control plane packets.

B. Level of Ordinary Skill in the Art

Petitioner contends that a hypothetical person of ordinary skill in the

art, with respect to and at the time of the’668 patent, would have the

following qualifications:

would have had a Masters of Science Degree (or a similar technical Masters Degree, or higher degree) in an academic area emphasizing computer networking or, alternatively, a Bachelor Degree (or higher degree) in an academic area emphasizing the design of electrical, computer, or software engineering and having several years of experience in computer network engineering and the design of computer networks.

Pet. 5; Ex. 1002 ¶ 9.

Patent Owner’s expert, Dr. Almeroth, essentially agrees:

[A] person of ordinary skill in the field of art would be a person with a Bachelor of Science degree, or its equivalent, in electrical engineering, computer engineering, computer science, or a related field and either a Master of Science degree, or its equivalent, in one of those fields or approximately two years of related experience in the field of network devices.

Ex. 2003 ¶ 40. Nominally, we determine that the hypothetical person of

ordinary skill in the art would have had either a Masters degree in an

Appx000012


IPR2016-00309 Patent 7,224,668 B1

13

academic area involving computer networking, or a Bachelor’s degree in

such an area and several years of work experience in computer networking.

We note, however, that neither party has explained substantively any

significance that the difference in the proffered levels of ordinary skill in the

art would play in the obviousness analysis. See Graham v. John Deere Co.,

383 U.S. 1, 17–18 (1966); Okajima v. Bourdeau, 261 F.3d 1350, 1355 (Fed.

Cir. 2001) (“[T]he level of skill in the art is a prism or lens through which a

judge, jury, or the Board views the prior art and the claimed invention.”);

Ryko Mfg. Co. v. Nu-Star, Inc., 950 F.2d 714, 718 (Fed. Cir. 1991) (“The

importance of resolving the level of ordinary skill in the art lies in the

necessity of maintaining objectivity in the obviousness inquiry.”). To that

end, we note that the prior art itself often reflects an appropriate skill level.

See Okajima, 261 F.3d at 1355.

C. The Parties’ Post-Institution Arguments

In our Decision on Institution, we concluded that the arguments and

evidence advanced by Petitioner demonstrated a reasonable likelihood that

claims 1–6, 8, 9, 15–22, 24–27, 33–36, 55–58, 60–63, and 69–72 were

unpatentable as obvious over Amara and CoreBuilder, claims 7, 23, and 59

were unpatentable as obvious over Amara, CoreBuilder, and Moberg, and

claims 10, 12, 13, 28, 30, 31, 64, 66, and 67 were unpatentable as obvious

over Amara, CoreBuilder, and Hendel. Dec. 23. We must now determine

whether Petitioner has established by a preponderance of the evidence that

the specified claims are unpatentable over the cited prior art. 35 U.S.C.

§ 316(e). We previously instructed Patent Owner that “any arguments for

patentability not raised in the [Patent Owner Response] will be deemed

waived.” Paper 9, 3; see also 37 C.F.R. § 42.23(a) (“Any material fact not

Appx000013


IPR2016-00309 Patent 7,224,668 B1

14

specifically denied may be considered admitted.”); In re Nuvasive, 842 F.3d

1376, 1379-1382 (Fed. Cir. 2016) (holding Patent Owner waived argument

addressed in Preliminary Response by not raising argument in the Patent

Owner Response). Additionally, the Board’s Trial Practice Guide states that

the Patent Owner Response “should identify all the involved claims that are

believed to be patentable and state the basis for that belief.” Office Patent

Trial Practice Guide, 77 Fed. Reg. 48,756, 48,766 (Aug. 14, 2012).

With a complete record before us, we note that we have reviewed

arguments and evidence advanced by Petitioner to support its unpatentability

contentions where Patent Owner chose not to address certain limitations in

its Patent Owner Response. In this regard, the record now contains

persuasive, unrebutted arguments and evidence presented by Petitioner

regarding the manner in which the asserted prior art teaches corresponding

limitations of the claims against which that prior art is asserted. Based on

the preponderance of the evidence before us, we conclude that the prior art

identified by Petitioner teaches or suggests all uncontested limitations of the

reviewed claims. The limitations that Patent Owner contests in the Patent

Owner Response are addressed below.

D. Status of CoreBuilder as a Prior Art Printed Publication

Before reaching the merits of Petitioner’s obviousness contentions, all

of which are based on CoreBuilder, we must determine as a threshold issue

whether CoreBuilder is a prior art printed publication under 35 U.S.C.

§ 102(b).4 See Pet. 3 (citing Ex. 1009; Ex. 1010). Petitioner has the burden

4 All references to 35 U.S.C. §§ 102, 103 herein will be pre-AIA.

Appx000014


IPR2016-00309 Patent 7,224,668 B1

15

of persuasion to prove unpatentability by a preponderance of the evidence.

See 35 U.S.C. § 316(e); Dynamic Drinkware, LLC v. Nat’l Graphics, Inc.,

800 F.3d 1375, 1379 (Fed. Cir. 2015).

For purposes of instituting trial, we accepted Petitioner’s contention,

unchallenged in the Preliminary Response, that CoreBuilder was available as

§ 102(b) prior art as of November 1999. Dec. 9–10. During trial, however,

Patent Owner challenged that contention (PO Resp. 30–32), and Petitioner

provided additional argument and evidence in reply (Pet. Reply 13–16).

The determination of whether a document is a “printed publication”

under 35 U.S.C. § 102 “involves a case-by-case inquiry into the facts and

circumstances surrounding the reference’s disclosure to members of the

public.” In re Klopfenstein, 380 F.3d 1345, 1350 (Fed. Cir. 2004).

“Because there are many ways in which a reference may be disseminated to

the interested public, ‘public accessibility’ has been called the touchstone in

determining whether a reference constitutes a ‘printed publication’ bar under

35 U.S.C. § 102(b).” Blue Calypso, LLC v. Groupon, Inc., 815 F.3d 1331,

1348 (Fed. Cir. 2016) (quoting In re Hall, 781 F.2d 897, 898–99 (Fed. Cir.

1986)). “A reference will be considered publicly accessible if it was

‘disseminated or otherwise made available to the extent that persons

interested and ordinarily skilled in the subject matter or art exercising

reasonable diligence[] can locate it.’” Id. (quoting Kyocera Wireless Corp. v.

Int’l Trade Comm’n, 545 F.3d 1340, 1350 (Fed. Cir. 2008)).

Having reviewed the parties’ arguments and supporting evidence, we

determine that Petitioner has demonstrated sufficiently that CoreBuilder

([Ex. 1009]) is a printed publication based on the following reasons and

factual findings. First, we find that CoreBuilder was shipped with the

Appx000015


IPR2016-00309 Patent 7,224,668 B1

16

CoreBuilder 3500 Switch to 3Com customers at least as early as November

1999. We base our findings on the testimony of Declaration of Patricia

Crawford, an employee of 3COM, filed as Exhibit 1010. We also support

our findings based on the indicia of publication found on CoreBuilder,

Exhibit 1009.

Petitioner asserts that, “[a]s established by the Declaration of Patricia

Crawford ([Ex. 1010]), CoreBuilder ([Ex. 1009]) was shipped with the


1999 and thus is prior art under 35 U.S.C. § 102(b).”5 Pet. 3. Ms. Crawford

testifies that

Exhibit 1009 was shipped with the 3Com CoreBuilder 3500 switch at least as of November, 1999 at least because (1) the process used to ensure that proper documentation was shipped with 3Com products did not change after I transitioned to a SQA Engineer, (2) Exhibit 1009 was given a part number, (3) the cover of Exhibit 1009 indicates it was published November, 1999, and (4) Exhibit 1009 itself indicates it was shipped with the CoreBuilder 3500 switch.

Ex. 1010 ¶ 9.

Patent Owner argues that Petitioner’s reliance on the Crawford

Declaration “is an improper incorporation by reference.” PO Resp. 31.

Petitioner counters that the citation to the Crawford Declaration is proper

because “[t]he Petition itself recites the necessary facts.” Pet. Reply 13–14.

We agree with Petitioner. Section 42.6(a)(3) of Title 37 of the Code of

Federal Regulations states that “[a]rguments must not be incorporated by

reference from one document into another document.” The Board has found

5 All references to 35 U.S.C. §§ 102, 103 herein will be pre-AIA.

Appx000016


IPR2016-00309 Patent 7,224,668 B1

17

improper incorporation by reference where, for example, a petition supports

conclusory statements by citing to a declaration that, in turn, includes claim

charts purporting to show how certain claim elements were met by the prior

art. Cisco Sys., Inc. v. C-Cation Techs., LLC, IPR2014-00454, Paper 12

(PTAB Aug. 29, 2014) (“Cisco”). As explained in Cisco, improper

incorporations by reference impose on the Board’s time by asking us to sift

through the exhibits to locate specific arguments. Cisco at 10. Here,

though, the Petition states that CoreBuilder “was shipped with the


1999 and thus is prior art under 35 U.S.C. § 102(b)” (Pet. 3), and the cited

testimony is factual in nature and is very limited in scope (Ex. 1010 ¶¶ 1–

10), both of which mitigate our concern about imposing on the Board’s time

and/or unfairly circumventing word limits. We determine, therefore, that the

citation to the Crawford Declaration is not an improper incorporation by

reference.

Patent Owner also argues that the Crawford Declaration should be

afforded no weight because Ms. Crawford has no personal knowledge of

Exhibit 1009. PO Resp. 31–32. Petitioner replies that Ms. Crawford’s

testimony as to practices and procedures is based on personal knowledge and

is sufficient to meet Petitioner’s burden of proof. Pet. Reply 14–15. We

agree with Petitioner. As an initial matter, Patent Owner’s assertion that

“[t]he Crawford declaration never establishes that Ex. 1009 was ever

shipped with a 3Com product” (PO Resp. 31) is contradicted by Ms.

Crawford’s explicit testimony that “the cover indicates that Exhibit 1009

was first shipped with the CoreBuilder 3500 Switch in November, 1999”

(Ex. 1010 ¶ 8). With respect to personal knowledge, Patent Owner cites no

Appx000017


IPR2016-00309 Patent 7,224,668 B1

18

law to support the proposition that personal knowledge of Exhibit 1009 is

necessary in order for Ms. Crawford’s testimony to be accorded weight.

Although Ms. Crawford did not author Exhibit 1009, she has personal

knowledge of the practices and procedures involving technical

documentation, such as CoreBuilder, followed by 3Com. Ex. 1010 ¶¶ 3–9.

In particular, Ms. Crawford testifies that, “[u]nder the normal procedure at

3Com at the time, when a publication date was included on the front page of

3Com documentation, the publication date indicates the date when the

documentation was first shipped with the corresponding product.” Id. ¶ 8.

Based on this personal knowledge, she testifies that “Published November

1999” on the first page of CoreBuilder “indicates that Exhibit 1009 was first

shipped with the CoreBuilder 3500 Switch in November, 1999.” Id. Patent

Owner suggests that Ms. Crawford’s testimony is relevant only to the period

when she was a technical writer (PO Resp. 31–32), but that suggestion is

contradicted by Ms. Crawford’s testimony that “the process used to ensure

that proper documentation was shipped with 3Com products did not change

after I transitioned to a SQA Engineer” (id. ¶ 10; see also id. ¶ 7) a position

she remained in until the year 2000 (id. ¶ 5).

Finally, we are not persuaded by Patent Owner’s argument that the

publication date on Exhibit 1009 is insufficient evidence of public

availability and is inadmissible hearsay for that purpose. PO Resp. 32

(citing Standard Innovation Corp. v. Lelo, Inc., Case IPR2014-00148, Paper

42, 13–18 (PTAB April 23, 2015)). As Petitioner points out, Standard

Innovation Corp. v. Lelo, Inc. is inapposite because the petitioner in that

case relied solely on a document’s copyright date, whereas Petitioner is

relying on the publication date on Exhibit 1009 in combination with

Appx000018


IPR2016-00309 Patent 7,224,668 B1

19

Ms. Crawford’s testimony explaining its meaning and significance. Pet.

Reply 15–16. In particular, Ms. Crawford testifies that “Exhibit 1009 was

shipped with the 3Com CoreBuilder 3500 switch at least as of November,

1999.” Ex. 1010 ¶ 10). Moreover, Petitioner points out that CoreBuilder

was publicly accessible on the 3Com website. Pet. Reply 15 n.10 (“The

document also states: ‘The most current versions of guides and release notes

are available in Adobe Acrobat Reader Portable Document Format (PDF) or

HTML from the 3Com World Wide Web site: http://www.3com.com,’ Ex.

1009 at 21.”). In light of the evidence that Exhibit 1009 was shipped to

3Com customers, and available electronically to anyone, as early as

November 1999 (three years before the Nov. 27, 2002, filing date of the

’668 patent), we determine that Exhibit 1009 was “disseminated or

otherwise made available to the extent that persons interested and ordinarily

skilled in the subject matter or art exercising reasonable diligence, [could]

locate it.” SRI Int'l, Inc. v. Internet Sec. Sys. Inc., 511 F.3d 1186, 1194 (Fed.

Cir. 2008) (quoting Bruckelmyer v. Ground Heaters, Inc., 445 F.3d 1374,

1378 (Fed. Cir. 2006)).

E. Claims 1–6, 8, 9, 15–22, 24–27, 33–36, 55–58, 60–63, and 69–72 –Obviousness Over Amara and CoreBuilder

Petitioner argues that claims 1–6, 8, 9, 15–22, 24–27, 33–36, 55–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

Appx000019


IPR2016-00309 Patent 7,224,668 B1

20

provides policy-based services for internal applications. Ex. 1004, Title,

Abstract. 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

Appx000020


IPR2016-00309 Patent 7,224,668 B1

21

engines 224–228, based on the destination addresses of the packets. Id. at

6:3–8.

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

Appx000021


IPR2016-00309 Patent 7,224,668 B1

22

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

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.

Petitioner’s Initial Positions

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. We have reviewed the Petition, Patent Owner's

Response, and Petitioner’s Reply, as well as the relevant evidence discussed

in those papers and other record papers, and are persuaded that the record

sufficiently establishes Petitioner’s contentions for claims 1–6, 8, 9, 15–22,

24–27, 33–36, 55–58, 60–63, and 69–72, and we adopt Petitioner’s

contentions discussed below as our own. 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–228 that execute and apply policies—e.g., dropping, logging,

encrypting/decrypting, network address translation, and prioritization—to

Appx000022


IPR2016-00309 Patent 7,224,668 B1

23

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 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’s Assertions Concerning the References

i. “the control plane port services operate on packets . . . in a way that is independent of the

physical port interfaces and services applied thereto”

Patent Owner argues that the combination of Amara and CoreBuilder

does not teach this limitation because Amara’s policy engines 224–228—

alleged by Petitioner to be the recited “port services”—do not operate on

Amara’s internally destined packets—alleged by Petitioner to be the recited

“packets . . . destined to the collection of control plane processes.” PO Resp.

22–25. This argument is unavailing because it is predicated upon a

construction of this limitation that we declined to adopt for the reasons

discussed above.

Appx000023


IPR2016-00309 Patent 7,224,668 B1

24

Patent Owner also argues that “Petitioner’s new theory regarding

Amara’s ‘packet classifiers’ performing ‘port services’ has no merit.” PO

Resp. 25–28. Petitioner counters that, “[e]ven under Cisco’s flawed

construction, Amara discloses applying both ‘port services’ and ‘control

plane port services’ to the control plane packets.” Pet. Reply 8–11. Again,

these arguments are based upon a construction of this limitation that we

declined to adopt for the reasons discussed above. As a result, we do not

rely on Petitioner’s arguments and evidence in support of this alternative

position.

ii. “the port services providing the ability to control and monitor packet flows, as

defined by control plane configurations”

Patent Owner argues that “Petitioner has failed to show that the

combination of Amara and CoreBuilder teaches or suggests configuring

policies for ‘monitor[ing] packet flows’” because “CoreBuilder’s packet

filters do not log packets.” PO Resp. 30. Petitioner counters that “[b]ecause

Amara discloses port services that ‘monitor packet flows,’ CoreBuilder need

not.” Pet. Reply 11.

We agree with Petitioner. Patent Owner’s argument mischaracterizes

our Institution Decision in Arista Networks, Inc. v. Cisco Systems, Inc.

IPR2015-00974, Paper 7 (PTAB Feb. 16, 2016) (“974 DI”). Patent Owner

suggests that we determined that Amara’s teaching of logging packets does

not teach “monitor packet flows,” as claimed. PO Resp. 29 (“Petitioner

admits, and the Board agreed, that Amara does not disclose that the alleged

“‘port services providing the ability to control and monitor packet flows’ of

Amara are ‘defined by control plane configurations.’”). To the contrary, our

determination in that case was based Petitioner’s failure to persuade us that

Appx000024


IPR2016-00309 Patent 7,224,668 B1

25

Amara discloses, for anticipation purposes, that its dropping, prioritizing,

and logging policies are “defined by control plane configurations,” as

required by the claim. 974 DI 13–14. As a result, we concluded that

“Amara does not adequately disclose this limitation expressly or inherently.”

Id. at 13.

In this case, Petitioner challenges the claims based on obviousness,

not anticipation, and is relying upon CoreBuilder to teach the “defined by

control plane configurations” limitation (Pet. 27), not to teach a port service

that provides the ability to monitor packet flows. Pet. Reply 12. For that,

Petitioner relies upon Amara. Id. We are persuaded that Amara’s teaching

of logging policy teaches a “port service[] providing the ability to . . .

monitor packet flows.” See Pet. 27 (citing Ex. 1004, 1:36 38, 5:16 21;

Ex. 1002 ¶ 36).

Evidence of Secondary Considerations

Patent Owner asserts that even if all of the other factors weigh in

favor of the obviousness of certain claims, those factors are outweighed by

Patent Owner’s proffered evidence concerning objective indicia of non-

obviousness, i.e., secondary considerations. PO Resp. 55–66 (citing Exs.

2015–2024, 2028–2045). Petitioner disagrees. Pet. Reply 26–27 (citing

Exs. 1001, 1024–1027, 2015, 2032–2040, 2043–2045).

i. Law – Objective Indicia of Nonobviousness

Factual inquiries for an obviousness determination include secondary

considerations based on objective evidence of non-obviousness. Graham v.

John Deere Co., 383 U.S. 1, 17–18 (1966). Notwithstanding what the

teachings of the prior art would have suggested to one of ordinary skill in the

art at the time of the invention, the totality of the evidence submitted,

Appx000025


IPR2016-00309 Patent 7,224,668 B1

26

including objective evidence of non-obviousness, may lead to a conclusion

that the challenged claims would not have been obvious to one of ordinary

skill in the art. In re Piasecki, 745 F.2d 1468, 1471–72 (Fed. Cir. 1984).

We note that it is not sufficient that a product or its use merely be

within the scope of a claim in order for objective evidence of

nonobviousness tied to that product to be given substantial weight. There

must also be a causal relationship, termed a “nexus,” between the evidence

and the claimed invention. Merck & Co. v. Teva Pharm. USA, Inc., 395

F.3d 1364, 1376 (Fed. Cir. 2005). A nexus is required in order to establish

that the evidence relied upon traces its basis to a novel element in the claim,

not to something in the prior art. Institut Pasteur v. Focarino, 738 F.3d

1337, 1347 (Fed. Cir. 2013). Objective evidence that results from something

that is not “both claimed and novel in the claim” lacks a nexus to the merits

of the invention. In re Kao, 639 F.3d 1057, 1068 (Fed. Cir. 2011).

All types of objective evidence of nonobviousness must be shown to

have nexus. In re GPAC Inc., 57 F.3d 1573, 1580 (Fed. Cir. 1995) (nexus

generally); In re Huang, 100 F.3d 135, 140 (Fed. Cir. 1996) (commercial

success); Wm. Wrigley Jr. Co. v. Cadbury Adams USA LLC, 683 F.3d 1356,

1364 (Fed. Cir. 2012) (copying); Rambus Inc. v. Rea, 731 F.3d 1248, 1256

(Fed. Cir. 2013) (long-felt need); Muniauction, Inc. v. Thomson Corp., 532

F.3d 1318, 1328 (Fed. Cir. 2008) (praise). The stronger the showing of

nexus, the greater the weight accorded the objective evidence of

nonobviousness. See Ashland Oil, Inc. v. Delta Resins & Refractories, Inc.,

776 F.2d 281, 306 (Fed. Cir. 1985), cert. denied, 475 U.S. 1017 (1986).

“Where the allegedly obvious patent claim is a combination of prior

art elements, . . . the patent owner can show that it is the claimed

Appx000026


IPR2016-00309 Patent 7,224,668 B1

27

combination as a whole that serves as a nexus for the objective

evidence . . . .” WBIP, LLC v. Kohler Co., 829 F.3d 1317, 1330 (Fed. Cir.

2016) (citing Rambus, 731 F.3d at 1258). “[T]here is a presumption of

nexus for objective considerations when the patentee shows that the asserted

objective evidence is tied to a specific product and that product is the

invention disclosed and claimed in the patent.” WBIP, 829 F.3d at 1329.

Secondary consideration evidence is accorded less weight for claims that are

considerably broader than the particular features in the merits of the claimed

invention. See ClassCo, Inc. v. Apple, Inc., 838 F.3d 1214, 1221 (Fed. Circ.

2016).

ii. Long-Felt Need

Establishing long-felt need first requires objective evidence that an art

recognized problem existed in the art for a long period of time without

solution. See In re Gershon, 372 F.2d 535, 539, (CCPA 1967); Orthopedic

Equip. Co., Inc. v. All Orthopedic Appliances, Inc., 707 F.2d 1376 (Fed. Cir.

1983). Second, the long-felt need must not have been satisfied by another

before the invention by applicant. Newell Cos. v. Kenney Mfg. Co., 864 F.2d

757, 768 (Fed. Cir. 1988). Third, the invention must in fact satisfy the long-

felt need. In re Cavanagh, 436 F.2d 491 (CCPA 1971). See also Perfect

Web Techs., Inc. v. InfoUSA, Inc., 587 F.3d 1324, 1332–33 (Fed. Cir. 2009)

(articulating all three factors).

a. Recognized Need for Long Period of Time

Patent Owner asserts that “a long-felt need existed to better manage

DoS attacks and improve QoS.” PO Resp. 58. “After emerging in the

1990s, DoS attacks proliferated rapidly, causing increasing disruption at a

time when society was becoming more dependent on networking

Appx000027


IPR2016-00309 Patent 7,224,668 B1

28

technology.” Id. (citing Ex. 2042). Exhibit 2042 includes a “timeline to

highlight some of the major trend events in attack technology evolution” that

begins in July 1999. Ex. 2042, 4. Patent Owner also cites a report titled,

“The Changing Face of Distributed Denial of Service Mitigation.” Id. at 59

(citing Ex. 2041 (“DDoS attacks continue to increase, going up 60 percent in

the past 3 years”)).

We find that the cited exhibits support adequately Patent Owner’s

assertion that DoS attacks were a need to be solved, and that it was long-felt

since at least 1999.

b. Not Satisfied Earlier by Another

Patent Owner does not address whether other solutions satisfied the

need to protect against DoS attacks, or even assert that it was first to satisfy

the aforementioned long-felt need. PO Resp. 58–59. As a result, we do not

find that Patent Owner has shown that the need was not satisfied earlier by

another.

c. Nexus

Patent Owner asserts that its “Catalyst 6500 Series Switches, Nexus

7000 Series Switches and 12000 Series Routers, for example, are

commercial embodiments of the claimed invention because they employ

Patent Owner’s Internet Operating System or Nexus Operating System

(collectively, “IOS”), which includes Patent Owner’s Control Plane Policing

(“CoPP”) feature, which includes command-line expressions to configure

and implement a control plane port entity and control plane port services.

PO Resp. 56–57. According to Patent Owner, “[t]he control plane port

entity and control plane port services . . . are coextensive with the claims as

Appx000028


IPR2016-00309 Patent 7,224,668 B1

29

a whole.” Id. at 57 (citing Ex. 2015; Ex. 2006 ¶ 102).6 Patent Owner further

argues that it “is entitled to a presumption of nexus for its objective evidence

because [it] has established that [its] CoPP feature provided in a [Patent

Owner] device running [IOS] is coextensive with the claims.” Id. at 57

(citing WBIP, 829 F.3d at 1329).

Petitioner asserts that “[t]here is no nexus for the secondary

considerations.” Pet. Reply 26. Specifically, Petitioner asserts that we

should disregard Exhibit 2015 because Patent Owner’s reliance on it

“improperly attempts to bypass word limits by reference to a lengthy claim

chart” and because it “contains only conclusory assertions and disparate

quotations” that do not adequately explain how the products meet the claim

limitations. Id.

IOS supports hundreds of command-line expressions. See, e.g.,

Ex. 2032. Of those, only six are associated with the CoPP feature. PO

Resp. 56–57. As a result, Patent Owner does not assert that its routers are

coextensive with the merits of the claimed invention. Instead, Patent Owner

asserts that its “control plane port entity and control plane port services

included in” its routers are coextensive with the merits of the claimed

invention. Id. at 57. Patent Owner equates its control plane entity and

control plane port services with its CoPP feature. Id. at 58 (“Cisco is

entitled to a presumption of nexus for its objective evidence because Cisco

has established that Cisco’s CoPP feature provided in a Cisco device running

Cisco IOS is coextensive with the claims.”) (citing Ex. 2015).

6 Exhibit 2015 is the subject of Petitioner’s Motion to Strike (Paper 41), which we address below.

Appx000029


IPR2016-00309 Patent 7,224,668 B1

30

We are persuaded that Patent Owner has shown sufficient nexus

between the CoPP feature of IOS and the claims of the ’668 patent.

d. Whether Proposed Solution Satisfies Need

Patent Owner does not assert that its Catalyst 6500 Series Switches,

Nexus 7000 Series Switches and 12000 Series Routers running IOS with its

CoPP feature satisfied the long-felt need to protect against DoS attacks. PO

Resp. 58–59. Petitioner points out that a page on Cisco’s website describes

DoS attacks as problems as recently as March 2013. Pet. Reply 27 (citing

Ex. 1027). We find that Patent Owner has not shown that its commercial

embodiments satisfy the aforementioned long-felt need.

e. Conclusion

In summary, we find that Patent Owner has not provided sufficient

supporting evidence and analysis to show adequately that (1) the long-felt

need was not earlier satisfied by another, and (2) Patent Owner’s proffered

solution satisfied that need. Accordingly, we find that Patent Owner has

proffered very weak evidence of long-felt need for the invention set forth in

independent claims 1.

iii. Failure of others

As evidence that others tried, and failed, to protect against DoS

attacks, Patent Owner identifies three techniques discussed in the ’668

patent, including “reverse pass forwarding,” “selective packet discard,” and

“identification, based on packet type, using an access list configured on an

input interface to explicitly deny or limit specific problematic packet types.”

PO Resp. 59–60 (citing Ex. 1001, 2:24–34, 2:59–65, 3:10–14). Patent

Owner also cites articles stating that, “[t]here still does not exist a tool or

process that can fully protect a Web site from a DDoS attack” (Ex. 2041, 3)

Appx000030


IPR2016-00309 Patent 7,224,668 B1

31

and “the problem of denial of service on the Internet has not significantly

changed in recent years” (Ex. 2042, 19). PO Resp. 60–61.

Petitioner argues that Patent Owner “has not shown that the claimed

invention addressed . . . a problem that others had failed to solve.” Pet.

Reply 27 (citing Ex. 1027). Exhibit 1027 is a page on Cisco’s website that

describes DoS attacks as a problem as recently as March 2013.

After describing the techniques identified by Patent Owner (Ex. 1001,

2:24–44), the ’668 patent states that “[w]hile these methods all provide some

level of control plane protection . . . [t]here also remain packet types and

scenarios in which a stated feature set[] do[es] not provide adequate control

plane protection” (id. at 2:45–49). Elsewhere, the ’668 patent states that

“[t]he primary goal of Denial of Service (DoS) protection, or otherwise

maintaining a specific Quality of Service (QoS) at the control plane 150 is to

maintain packet forwarding and protocol states while the device 100 is either

under attack or experiencing normal to heavy traffic load.” Id. at 5:24–28.

Accordingly, we understand the problem that the ’668 patent purports to

solve to be protecting the control plane of internetworking devices, such as

routers, from DoS attacks. Exhibit 2041 describes a lack of tools or

processes “that can fully protect a Web site,” not a router, from a DoS attack.

Ex. 2041, 3. Exhibit 2042 is similarly focused on DoS attacks generally

rather than efforts to protect the control plane of an internetworking device.

As a result, we give these documents little weight as evidence of the failure

of others to protect the control plane of an internetworking device.

Accordingly, the only evidence of failure of others to which we give any

substantial weight is the description in the background section of the ’668

patent itself.

Appx000031


IPR2016-00309 Patent 7,224,668 B1

32

In summary, we find that Patent Owner has provided some evidence

and analysis to show that others tried, and failed, to solve the specific

problem solved by the ’668 patent. Accordingly, we find that Patent Owner

has proffered weak evidence of failure of others to solve the specific

problem solved by the ’668 patent.

iv. Copying

Patent Owner asserts that Petitioner copied the patented control plane

entity and control plane port services embodied in Cisco’s CoPP feature in

Petitioner’s commercial internetworking devices:

Arista copied the patented control plane entity and control plane port services embodied in Cisco’s CoPP feature in its commercial internetworking devices. (See Ex. 2015; Ex. 2032; Almeroth Decl., ¶ 102.) Arista’s copying is well-documented and evinces a deliberate effort to duplicate the claimed subject matter. (See Ex. 2045; Ex. 2034; Ex. 2035; Ex. 2036; Ex. 2037; Ex. 2033; Ex. 2043; Ex. 2044; Ex. 2015.) Beyond reproducing every element of independent claims 1, 19, and 55 in rival commercial products, Arista even copied Cisco’s name for its innovative feature: “Control Plane Policing.” (See Ex. 2024, p. 47; Ex. 2031, pp. 1217–1219.) As shown below in a chart comparing the products, Arista also copied verbatim the series of unique command-line expressions used with Cisco’s CoPP feature. (Compare Ex. 2028; with Ex. 2031).

PO Resp. 61. Patent Owner also argues that Petitioner’s employees, as

former employees of Patent Owner, had access to and knowledge of Patent

Owner’s proprietary technology. Id. at 61–63. Patent Owner also argues

that Petitioner copied the name of its feature (i.e., “Control Plane Policing”)

and the names of the CLI commands associated with that feature. Id. at 63–

66.

Appx000032


IPR2016-00309 Patent 7,224,668 B1

33

Petitioner asserts that Patent Owner “fails to establish any nexus

between the alleged ‘copying evidence’ and the ’668 patent claims” because

“the cited evidence relates to allegations about feature names and command

line interfaces (CLIs),” but “none of the claims recite feature name(s) or CLI

expressions.” Pet. Reply 27.

We agree with Petitioner. Neither the feature name nor the command-

line expressions are claimed in the ’668 patent. Even assuming that

Petitioner copied these aspects of IOS, and even assuming that Arista’s

products embody the limitations of the challenged claims, as asserted in

Exhibit 2015, that is not sufficient evidence to show that Petitioner copied

the functionality claimed in the ’668 patent.

In summary, we find that Patent Owner has not provided sufficient

supporting evidence and analysis to show adequately that Petitioner copied

the functionality claimed in the ’668 patent. Accordingly, we find that

Patent Owner has proffered very weak evidence of copying of the

functionality claimed in the ’668 patent.

v. Overall Weighing of Relevant Factors Concerning Obviousness, Including Secondary Considerations

We now weigh Patent Owner’s evidence of secondary consideration

in conjunction with the other factors relevant to obviousness for independent

claim 1. In summary, we find, for the reasons set forth above, that Amara

and CoreBuilder account for all of the limitations of independent claim 1.

We find further that Petitioner has identified sufficient evidence, in the cited

prior art, that the modification itself, as well as the rationale for the

modification, were well known to one of ordinary skill in the art, at the time

of the invention.

Appx000033


IPR2016-00309 Patent 7,224,668 B1

34

Against the above findings, we weigh the Patent Owner’s evidence of

secondary considerations, each of which we have analyzed above, and

summarize as follows: (1) very weak evidence of long-felt need; (2) weak

evidence of failure of others; and (3) very weak evidence of copying.

Overall, upon weighing the Graham factors, we determine that the

very weak evidence of each of long-felt need and copying, and the weak

evidence of failure of others, does not outweigh our finding, based on strong

evidence, that the internetworking device of Amara/CoreBuilder accounts

for every limitation of independent claim 1. Furthermore, as claims 2–6, 8,

9, and 15–18, each depend ultimately from independent claim 1, we

determine that a similar weighing for each of claims 2–6, 8, 9, 15–18 results

in the same conclusion. We reach the same result with respect to

independent claims 19 and 55, and claims 20–22, 24–27, 33–36, 56–58, 60–

63, and 69–72 for the same reasons.

Accordingly, for these reasons, we determine that Petitioner has met

its burden of showing that the subject matter of claims 1–6, 8, 9, 15–22, 24–

27, 33–36, 55–58, 60–63, and 69–72 would have been obvious in view of

the combination of Amara and CoreBuilder for the reasons discussed above.

Conclusion

For the foregoing reasons, we are persuaded that Petitioner has

established, by a preponderance of the evidence, 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.

Appx000034


IPR2016-00309 Patent 7,224,668 B1

35

F. Claims 7, 23, 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. We have reviewed the

Petition, Patent Owner's Response, Petitioner’s Reply, as well as the relevant

evidence discussed in those papers and other record papers, and are

persuaded that the record sufficiently establishes Petitioner’s contentions for

claims 7, 23, 41, and 59, and we adopt Petitioner’s contentions discussed

below as our own.

Petitioner’s Initial Positions

The claims require the control plane processes to be distributed across

multiple processors. 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.

Moberg’s Status as Prior Art

Patent Owner argues that “Moberg is not prior art under § 102(a)

because the inventors of the ʼ668 patent conceived of the invention prior to

October 1, 2002, and the inventors and their patent attorney exercised

reasonable diligence in constructively reducing the invention to practice

Appx000035


IPR2016-00309 Patent 7,224,668 B1

36

during the entirety of the 59 day critical period;” and (2) “Moberg cannot be

used to establish unpatentability even as § 102(e) art because, at the time of

the invention, the ’668 patent and Moberg patent were both subject to

assignment to Cisco, thus disqualifying Moberg under § 103(c).” PO Resp.

34–35.

Petitioner counters that (1) Moberg is prior art under § 102(a) because

Cisco has not met its burden to prove an earlier invention date and has not

shown reasonably continuous diligence; (2) Patent Owner cannot rely on

§ 103(c) because the claimed invention was not assigned to Patent Owner

until November 26, 2002, and Patent Owner has not provided evidence that

the named inventors of the ’668 patent were “subject to an obligation of

assignment,” as required by § 103(c). Pet. Reply 21–22.

We agree with Petitioner that Moberg is prior art for the reasons

explained below.

a. Principles of Law

Petitioner has the burden of persuasion to prove unpatentability by a

preponderance of the evidence. Dynamic Drinkware, LLC v. Nat’l Graphics,

Inc., 800 F.3d 1375, 1379 (Fed. Cir. 2015). Petitioner also has the initial

burden of production to show that a reference is prior art to certain claims

under a relevant section of 35 U.S.C. § 102. Id. Once Petitioner has met

that initial burden, the burden of production shifts to Patent Owner to argue

or produce evidence that the asserted reference is not prior art to certain

claims, for example, because those claims are entitled to the benefit of

priority of an earlier-filed application. Id. at 1380. Once Patent Owner has

met that burden of production, the burden is on Petitioner to show that the

Appx000036


IPR2016-00309 Patent 7,224,668 B1

37

claims at issue are not entitled to the benefit of priority of the earlier filed

application. Id.

Section 102(a) recites “[a] person shall be entitled to a patent

unless . . . (a) the invention was known or used by others in this country, or

patented or described in a printed publication in this or a foreign country,

before the invention thereof by the applicant for patent” (emphasis added).

An inventor “may date his patentable invention back to the time of its

conception, if he connects the conception with its reduction to practice by

reasonable diligence on his part, so that they are substantially one

continuous act.” Mahurkar v. C.R. Bard, Inc., 79 F.3d 1572, 1577 (Fed. Cir.

1996) (internal citation and quotations omitted).

“Conception must be proved by corroborating evidence which shows

that the inventor disclosed to others his completed thought expressed in such

clear terms as to enable those skilled in the art to make the invention.”

Coleman v. Dines, 754 F.2d 353, 359 (Fed. Cir. 1985). The requirement for

corroboration of inventor’s testimony arose out of a concern that inventors

testifying at trial would be tempted to remember facts favorable to their case

by the lure of protecting their patent or defeating another’s patent.

Mahurkar, 79 F.3d at 1577 (citing Price v. Symsek, 988 F.2d 1187, 1195

(Fed. Cir. 1993)); see also Kridl v. McCormick, 105 F.3d 1446, 1449 (Fed.

Cir. 1997) (“The tribunal must also bear in mind the purpose of

corroboration, which is to prevent fraud, by providing independent

confirmation of the inventor’s testimony.”). However, “[t]here is no

particular formula that an inventor must follow in providing corroboration of

his testimony of conception.” Singh v. Brake, 222 F.3d 1362, 1367 (Fed.

Cir. 2000) (citing Kridl, 105 F.3d at 1450). Rather, a rule of reason applies

Appx000037


IPR2016-00309 Patent 7,224,668 B1

38

to determine whether the inventor’s testimony has been corroborated. Price,

988 F.2d at 1194. “The rule of reason, however, does not dispense with the

requirement for some evidence of independent corroboration.” Coleman,

754 F.2d at 360.

“Reasonable diligence must be shown throughout the entire critical

period, which begins just prior to the competing reference's effective date

and ends on the date of the invention's reduction to practice.” Perfect

Surgical Techniques, Inc. v. Olympus Am., Inc., 841 F.3d 1004, 1007 (Fed.

Cir. 2016) (citation omitted); see also id. at 1009 (“A patent owner . . . must

show that there was reasonably continuous diligence.”). “Under this

standard, an inventor is not required to work on reducing his invention to

practice every day during the critical period.” Id. (citing Monsanto Co. v.

Mycogen Plant Sci., Inc., 261 F.3d 1356, 1369 (Fed. Cir. 2001)). “[P]eriods

of inactivity within the critical period do not automatically vanquish a patent

owner's claim of reasonable diligence.” Id. Rather, “the point of the

diligence analysis . . . is to assure that, in light of the evidence as a whole,

‘the invention was not abandoned or unreasonably delayed.’” Id. (quoting

Brown v. Barbacid, 436 F.3d 1376, 1379 (Fed. Cir. 2006). A party alleging

diligence must provide corroboration with evidence that is specific both as to

facts and dates. Gould v. Schawlow, 363 F.2d 908, 920 (CCPA 1966);

Kendall v. Searles, 173 F.2d 986, 993 (CCPA 1949). The rule of reason

does not dispense with the need for corroboration of diligence that is specific

as to dates and facts. Gould, 363 F.2d at 920; Kendall, 173 F.2d at 993; see

Coleman v. Dines, 754 F.2d 353, 360 (Fed. Cir. 1985).

Appx000038


IPR2016-00309 Patent 7,224,668 B1

39

Section 103(c)(1) recites

Subject matter developed by another person, which qualifies as prior art only under one or more of subsections (e), (f), and (g) of section 102, shall not preclude patentability under this section where the subject matter and the claimed invention were, at the time the claimed invention was made, owned by the same person or subject to an obligation of assignment to the same person.

b. Whether Moberg is Prior Art Under § 102(a)

Applying the framework from Dynamic Drinkware, we determine that

Petitioner has met its initial burden of production by asserting that Moberg is

prior art under 35 U.S.C. § 102(a). Pet. 3 (“Moberg published prior to the

Critical Date and thus is prior art under 35 U.S.C. §§ 102(e) & 102(a).”).

The burden of production having shifted to Patent Owner, Patent

Owner asserts that “Moberg is not prior art under § 102(a) because the

inventors of the ʼ668 patent conceived of the invention prior to October 1,

2002, and the inventors and their patent attorney exercised reasonable

diligence in constructively reducing the invention to practice during the

entirety of the 59 day critical period.” PO Resp. 35–42. For conception,

Patent Owner provides a draft specification, titled “Control Plane Security

and Quality of Service Functional Specification” (Ex. 2009, “CoPP

Specification”) and testimony from R. Wayne Ogozaly (Ex. 2008), a named

inventor of the ’668 patent. Id. at 35–37. Mr. Ogozaly testifies that he and

his co-inventors “conceived of the invention recited in the ’668 Patent in the

United States prior to July 19, 2002.” Ex. 2008 ¶ 6. Mr. Ogozaly’s

testimony is corroborated by the CoPP Specification, which Ms. Laurie Wall

testifies was deposited in Patent Owner’s document management system on

July 19, 2002 (Ex. 2010 ¶¶ 6–7). Patent Owner’s declarant, Dr. Almeroth,

maps the disclosure from the CoPP Specification to claims 7, 23, and 59.

Appx000039


IPR2016-00309 Patent 7,224,668 B1

40

Ex. 2047; PO Resp. 36. For reduction to practice, Patent Owner provides

the testimony of Dr. Ogozaly, the billing records from David J. Thibodeau,

Jr. (the patent attorney who prepared and filed the application that eventually

issued as the ’668 patent) (Ex. 2011), testimony of Ms. Wall authenticating

those records, and the testimony of Mr. Thibodeau (Ex. 2012) regarding his

work between September 30, 2002 (just prior to the issuance of Moberg) and

November 27, 2002 (constructive reduction to practice). PO Resp. 37–42.

In light of Patent Owner’s arguments and evidence, we determine that

Patent Owner has met its burden of production, and the burdens7 concerning

this issue are on Petitioner. Petitioner replies that Moberg is prior art under

102(a) because Cisco has not met its burden to prove an earlier invention

date. Pet. Reply 17–20. Specifically, Petitioner contends that the CoPP

Specification “does not confirm the inventors conceived of having two

processors simultaneously perform control plane services.” Id. at 17–18

(citing Ex. 2009, 17 for a “standby” processor). We agree. The claims

require the “control plane processes”—as opposed to the “control plane port

services”—be distributed across multiple processors. Dr. Almeroth

identifies, for claim 1, disclosure in the CoPP Specification of “Distributed

CP Services” performed by a “distributed Switch Engine” in each linecard,

(Ex. 2047, 5–6), but these disclosures relate to distributed control plane port

services, not to distributed control plane processes. Dr. Almeroth identifies,

for claim 7, disclosure in the CoPP Specification of “active and standby

Control Plane Processors.” Id. at 6. But he does not identify, and we cannot

discern, where the CoPP Specification describes distributing control plane

7 We mean both the burden of production and the burden of persuasion.

Appx000040


IPR2016-00309 Patent 7,224,668 B1

41

processes across both the active and the standby Control Plane Processors.

Moreover, based on the use of “active” and “standby,” we are persuaded by

Petitioner’s argument that “a ‘standby’ processor . . . presumably takes over

if the primary (active) control plane processor fails.” Pet. Reply 17.

Having considered the parties’ arguments and evidence, we are

persuaded that Petitioner has met its burden of persuasion by showing

sufficiently that Moberg is “before the invention thereof by” the named

inventors of the ’668 patent.

c. Whether Moberg Can Preclude Patentability Under § 103(c)

Although we determine above that Moberg is prior art under § 102(a),

we exercise our discretion to determine whether Petitioner has shown that

Moberg is also prior art under § 102(e). Again applying the framework from

Dynamic Drinkware, we determine that Petitioner has met its initial burden

of production by asserting that Moberg is prior art under 35 U.S.C. § 102(e).

Pet. 3 (“Moberg published prior to the Critical Date and thus is prior art

under 35 U.S.C. §§ 102(e) & 102(a).”).

The burden of production having shifted to Patent Owner, Patent

Owner asserts that “as § 102(e) prior art, Moberg cannot be used to establish

unpatentability of the ’668 patent under § 103(c) because both the ’668

patent and the Moberg reference were assigned, or subject to assignment, to

[Patent Owner] at the time of the invention.” PO Resp. 42–43. Specifically,

Patent Owner argues that Moberg was assigned to Patent Owner on January

27, 1999, that the named inventors of the ’668 patent were under “an

obligation of assignment to the same person,” and that, on November 26,

2002, the named inventors of the ’668 patent assigned their rights in the

invention to Patent Owner. Id. As a result, according to Patent Owner,

Appx000041


IPR2016-00309 Patent 7,224,668 B1

42

“both the ’668 patent and the Moberg reference were assigned, or subject to

assignment, to [Patent Owner] at the time of the invention,” and therefore

“cannot preclude patentability of the ’668 patent.” Id. at 43.

In light of Patent Owner’s arguments and evidence, we determine that

Patent Owner has not met its burden of production. Under § 103(c) of

Title 35 of the U.S. Code, Moberg shall not preclude patentability only

“where [Moberg] and the claimed invention were, at the time the claimed

invention was made, owned by the same person or subject to an obligation of

assignment to the same person.” Emphasis added. Patent Owner does not

identify a “time the claimed invention was made.” To the extent that Patent

Owner is relying upon its conception date (see PO Resp. 36–37) of July 19,

2002, Petitioner points out correctly that (1) the claimed invention was not

yet owned by Patent Owner because the named inventors of the ’668 patent

did not assign their rights in the invention to Patent Owner until

November 26, 2002; and (2) there is no evidence, such as employment

agreements, to support Patent Owner’s contention that the named inventors

of the ’668 patent were “subject to an obligation of assignment.” Pet. Reply

21–22. Patent Owner’s sole assertion in this regard (PO Resp. 43) is

uncorroborated by documentary evidence. As a result, Patent Owner has not

met its burden of production to show that Moberg cannot preclude

patentability under § 103(c).

Furthermore, to the extent that Patent Owner is relying upon the

November 27, 2002, filing date as “the time the claimed invention was

made” for 103(c) purposes, both Moberg and the ’668 patent would then be

commonly owned “at the time the claimed invention was made,” but

Appx000042


IPR2016-00309 Patent 7,224,668 B1

43

Moberg would be prior art under § 102(a) and the § 103(c)(1) exception

would not apply.

Having considered the parties’ arguments and evidence, we are

persuaded that Petitioner has met its burden of persuasion by showing

sufficiently that Moberg issued before the November 27, 2002, filing date of

the ’668 patent and, therefore, is prior art to the ’668 patent under 102(e).

Whether Moberg Teaches Distributing Control Plane Processes Across Multiple Processors

Patent Owner argues that Moberg “does not 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. PO Resp. 43–44. Patent Owner

acknowledges that Moberg teaches that some functions may be offloaded to

a secondary processor, but argues that “[t]his statement does not mean the

primary processor can offload all types of processing performed by the

primary CPU.” Id. at 45. According to Patent Owner, Moberg distinguishes

between “communication intensive tasks” that are distributed across

processor and slow-path tasks that are performed by primary processor 166.

Id. at 46.

Petitioner counters that Patent Owner’s distinction is irrelevant

because the “communication intensive tasks” it identifies are described in

Moberg as being performed by a third set of processors in the interfaces 160.

Pet. Reply 17.

We agree with Petitioner. Patent Owner’s distinction between

fast-path and slow-path tasks is not persuasive because Moberg teaches

explicitly that the “communications intensive tasks” are performed by “an

Appx000043


IPR2016-00309 Patent 7,224,668 B1

44

independent processor” in each interface. Ex. 1005, 5:6–20. Petitioner, in

contrast, relies upon Moberg’s teaching of “such router tasks as routing table

computations and network management.” Id. at 4:45–46. Although Moberg

states that “primary CPU 166 may be responsible” (id. (emphasis added)) for

those tasks, Moberg also teaches a secondary processor that can offload

work from the primary processor such that the router “make[s] use of both

processors simultaneously.” Id. at 2:26–30. Specifically, Moberg teaches “a

list of projects or functions that are to be assigned to and performed by the

secondary processor” which “may include functions and projects typically

performed by the primary processor.” Id. at 6:11–15. “The software

designer may determine which functions are to be performed by the

secondary processor rather than the primary processor.” Id. at 6:15–17.

Moberg teaches that “anything that was off-loaded from the primary

processor to the secondary processor is run by the secondary processor”

even when the initialization sequence for the secondary processor otherwise

remains suspended. Id. at 8:25–27.

Dr. Lin testifies that Moberg’s “routing table computations and

network management” are, like Amara’s internal applications 230, functions

for controlling and configuring the routing device, and that a person of

ordinary skill in the art would have understood that “some of the internal

applications 230 would be off-loaded from the primary CPU to the

secondary CPU” (emphasis added) because doing so “would provide the

benefit of increased processing power.” Ex. 1002 ¶¶ 74–75. As a result, we

are persuaded that a person of ordinary skill in the art would have found it

obvious to offload some control plane functions to a secondary CPU while

Appx000044


IPR2016-00309 Patent 7,224,668 B1

45

continuing to execute other control plane functions on the primary CPU,

thereby rendering them “distributed across multiple processors.”

Conclusion

For the foregoing reasons, we are persuaded that Petitioner has

established, by a preponderance of the evidence, that claims 7, 23, and 59

are unpatentable as obvious over the combination of Amara, CoreBuilder,

and Moberg.

G. Claims 10, 12, 13, 28, 30, 31, 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. In particular, Petitioner argues that a person of ordinary

skill in the art would have combined Amara, CoreBuilder, and Hendel

because doing so would “provide the ability to support larger amounts of

system traffic and a larger network” (e.g., a greater number of physical

interface ports) by reducing the risk of a single policy engine 232 becoming

a bottleneck. Id. at 56–57 (citing Ex. 1002 ¶¶ 99–101).

We have reviewed the Petition, Patent Owner's Response, Petitioner’s

Reply, as well as the relevant evidence discussed in those papers and other

record papers, and are persuaded that the record sufficiently establishes

Petitioner’s contentions for claims 10, 12, 13, 28, 30, 31, 43, 48, 49, 64, 66,

and 67, and we adopt Petitioner’s contentions discussed below as our own.

Patent Owner argues that Petitioner fails to meet its burden to show

that a person of ordinary skill in the art would have combined Hendel with

Appx000045


IPR2016-00309 Patent 7,224,668 B1

46

Amara and CoreBuilder. PO Resp. 47–55. Specifically, Patent Owner

argues that Petitioner presents no evidence that adding more ports to a

device necessarily results in more control plane traffic. Id. at 52. Petitioner

replies that Hendel teaches that distributing policy processing is beneficial

because traffic increases with increasing ports, and that, even assuming

control plane traffic increases more slowly than transit traffic, nothing in

Hendel suggests that distributing processing would not be beneficial for

control plane traffic as well. Pet. Reply 24. We agree with Petitioner.

Hendel teaches a “scalable architecture which allows for easily increasing

the number of subsystems 210 as a way of increasing the number of external

connections, thereby allowing greater flexibility in defining the surrounding

network environment.” Id. at 7:14-18; see also Pet. 56 (describing Hendel’s

teachings regarding the advantages of a scalable architecture). We credit the

testimony of Dr. Lin that a person of ordinary skill in the art at the time of

the invention would have understood this advantage would apply to

distribution of control plane port services, such those performed by Amara’s

policy engine 232, as well as normal port services.

Patent Owner also argues that (1) Dr. Lin’s testimony is unsupported

by “actual evidence of such bottlenecks ever occurring;” and (2) Petitioner

presents no evidence that a device having so many ports that its control

plane traffic overwhelmed a single policy engine actually existed. Id. at 51–

53. Petitioner replies that “actual evidence of router bottlenecks or

overloading . . . is irrelevant.” Pet. Reply 25. We agree with Petitioner.

Petitioner need not provide evidence of actual occurrences of bottlenecks in

order to show sufficiently that a person of ordinary skill in the art at the time

Appx000046


IPR2016-00309 Patent 7,224,668 B1

47

would have appreciated Hendel’s teachings regarding the advantages of

distributed policy processing.

Patent Owner also argues that “Dr. Lin attempted to present a new

theory that a single ‘policy engine’ could be overwhelmed during a denial-

of-service attack.” PO Resp. 53–54. This theory was not articulated in the

Petition (see Pet. 55–57) and, therefore, we do not rely on it.

Finally, Patent Owner argues that there would be no need to distribute

control plane port services to Hendel’s subsystems because “Hendel

explicitly states that it is unconcerned about the throughput of its control

plane.” PO Resp. 54 (citing Ex. 1007, 7:53–57 (“The communication

between the CPS and the individual subsystems need not be as fast or

reliable as the internal links between subsystems, because, as appreciated

below, the CPS is not normally relied upon to forward the majority of traffic

through the MLDNE.”). Petitioner replies that this disclosure is not a

teaching away, but rather “simply recognizes an uncontroversial fact that

control plane communications require less bandwidth than data plane

communications.” Pet. Reply 25. Petitioner asserts that, “precisely because

the control plane communications are not “as fast or reliable,” the control

plane policies (i.e., policy engine 232 in Amara) should be applied before

the control plane bus (element 251 in Hendel)—and therefore in the

distributed subsystems.” Id. at 25–26. We agree with Petitioner. Hendel’s

acknowledgement that communications between the CPS and individual

subsystems (over which control plane traffic passes) “need not be as fast or

reliable as” the internal links between subsystems (over which transit traffic

passes) does not lead us to understand Hendel as being “unconcerned” about

the throughput of its control plane, as Patent Owner contends. We find that

Appx000047


IPR2016-00309 Patent 7,224,668 B1

48

Hendel’s recognition that control plane traffic requires less reliability or

speed than transit traffic does not contradict its teaching to use a distributed

architecture. Stated differently, the advantages of a distributed architecture

of acquiring flexibility and scalability are not undercut by Hendel’s

statement that control plane traffic need not be as fast or reliable as other

traffic. See Meiresonne, v. Google, 849 F.3d 1379, 1383 (Fed. Cir. 2017)

(describing a website abstract as sometimes as informative as “gibberish”

did not amount to promoting abandonment of text descriptions).

For the foregoing reasons, we are persuaded that Petitioner has shown,

by a preponderance of the evidence, that claims 10, 12, 13, 28, 30, 31, 64,

66, and 67 are unpatentable as obvious over the combination of Amara,

CoreBuilder, and Hendel.

H. Petitioner’s Motion to Strike

Petitioner filed a Motion to Strike (Paper 41) to which Patent Owner

filed an Opposition (Paper 48). Petitioner moves to strike Exhibits 2015 and

2047 and exhibits discussed exclusively therein (Exhibits 2016–2023 and

2027) on the grounds that they are improperly incorporated by reference into

Paten Owner’s Response. Paper 41, 1–3. Exhibit 2015 is a claim chart

mapping descriptions of Patent Owner and Petitioner’s products to the

claims of the ’668 patent. Exhibit 2047 is a claim chart mapping disclosure

from a document relied upon to corroborate a conception date to claims 7,

23, and 59.

Even considering Exhibit 2015, we determine that Patent Owner’s

secondary considerations arguments and evidence do not outweigh the

evidence of obviousness. Likewise, even considering Exhibit 2047, we

Appx000048


IPR2016-00309 Patent 7,224,668 B1

49

determine that Patent Owner’s evidence of its conception date is insufficient.

As a result, we dismiss Petitioner’s Motion to Strike as moot.

I. Patent Owner’s Motion to Strike

Patent Owner filed a Motion to Strike Petitioner’s Reply (Paper 42) to

which Petitioner filed an Opposition (Paper 44). Patent Owner moves to

strike (1) “Petitioner’s new argument that claimed ‘port services’ are

executed by Amara’s ‘packet classifiers’” (Paper 42, 2–5); and (2)

“Petitioner’s new argument that CoreBuilder discloses ‘monitoring packet

flows’” (id. at 5).

We do not rely upon either of Petitioner’s alleged new arguments and,

therefore, Patent Owner’s Motion to Strike is dismissed as moot.

J. Papers Under Seal

This Final Written Decision discusses or cites information in papers

that are subject to a Protective Order. For those papers, the Parties should

follow the guidance related to 37 C.F.R. § 42.56. See Office Patent Trial

Practice Guide, 77 Fed. Reg. 48,756, 48,761 (Aug. 14, 2012).

III. CONCLUSION Petitioner has demonstrated, by a preponderance of the evidence, that

claims 1–10, 12, 13, 15–28, 30, 31, 33–36, 55–64, 66, 67, and 69–72 of the

’668 patent are unpatentable. Petitioner’s Motion to Strike is dismissed-as-

moot. Patent Owner’s Motion to Strike is dismissed-as-moot.

Appx000049


IPR2016-00309 Patent 7,224,668 B1

50

IV. ORDER Accordingly, it is

ORDERED claims 1–10, 12, 13, 15–28, 30, 31, 33–36, 55–64, 66, 67,

and 69–72 of the ’668 patent are held unpatentable;

FURTHER ORDERED that Petitioner’s Motion to Strike is

dismissed-as-moot;

FURTHER ORDERED that Patent Owner’s Motion to Strike is

dismissed-as-moot; and

FURTHER ORDERED that because this is a final written decision,

parties to the proceeding seeking judicial review of the decision must

comply with the notice and service requirements of 37 C.F.R. § 90.2.

Appx000050


IPR2016-00309 Patent 7,224,668 B1

51

For PETITIONER:

W. Karl Renner Lauren Degnan Adam Shartzer Steven Katz FISH & RICHARDSON P.C. [email protected] [email protected] [email protected] [email protected]

For PATENT OWNER:

Lori A. Gordon Robert G. Sterne Jon E. Wright Daniel Block STERNE, KESSLER, GOLDSTEIN & FOX P.L.L.C. [email protected] [email protected] [email protected] [email protected]

Appx000051


Appx000052

c12) United States Patent Smethurst et al.

(54) CONTROL PLANE SECURITY AND TRAFFIC FLOW MANAGEMENT

(75) Inventors: Adrian C. Smetburst, Groton, MA (US): Michael F. Keohane, Shrewsbury, MA (US): R. Wayne Ogozaly, Holl is, NH (US)

(73) Assignee: Cisco Technology, Inc., San Jose, CA (US)

( *) Notice: Subject to any disclaimer, the tenn of this patent is extended or adjusted under 35 U.S.C. I 54(b) by JOOO days.

(2]) Appl. No.: J 0/307,154

(22) FiJed: Nov. 27, 2002

(5 I) lnt. Cl. G06F 11/00 (2006.01) H04L 12/50 (2006.01) ll04L 12128 (2006.01)

(52) U.S. Cl. ...................... 370/229; 370/352: 370/360; 370/401; 370/402

(58) Field of Classification Search ............ .... 370/229, 370/360, 387, 352, 357, 401,402: 379/88.22,

379/207.02, 221 .08: 709/224, 238 See application file for complete search history.

(56) References Cited

U.S. PATENT DOCUMENTS

6.304,568 Bl 2001/00266 12 Al 2002/0097672 A I

10/2001 Kim 10/200 l Duspiva et al. 7/2002 Barbas et al.

OTHER PUBLICATIONS

Park, K. and Lee, H., "On the Elfect iveness of Route-Based Packet Filtering !'or Distributed DoS Attack Prevention in Power-Law Intcrnets," SIGCOMM' Of: 1-12 (200 1).

I IIIII IIIIIIII Ill lllll lllll lllll lllll lllll lllll lllll lllll 111111111111111111 US007224668B 1

(JO) Patent No.: US 7,224,668 Bl May 29, 2007 (45) Date of Patent:

Re: [RPSEC) Draft Status, Crom a protocol developer's angle. [online], Jul. 26, 2002 [retrieved on Sep. l8, 2002]. Retieived from the ln1erne1 <URL:hllps://wwwl .ietf.org/mai lman-archive/working-groups/rpsec/currcnt/msgOO 167 .hbnl>.

Dmham. D .. ct al. , ''Elimination of Distributed Denial of Service Attacks using Programmable Network Processors," Imel Research and Development: 1-4 (2002).

Flexible Firewalls for Network Processors. [online] [retrieved on Sep. 18. 2002). Retrieved from the Internet <URL:mhlml:file:// C:\ tibnet\dad\clienls\cisco\utexas.mhl>.

Primary Examiner- Afsar Qureshi (74) Allorne;; Agent, or Fir111- Hamihon, Brook, Smith & Reynolds. P.C.

(57) ABSTRACT

An internetworking device that provides improved immunity to Denial of Service attacks. and in general, improved Quality of Service (QoS). An interuetworking element or otJ1er route processor is composed of two main parts, including a data forwardi ng plane and a control plane; tJ1e control plane runs routing, s ignaling and control protocols that are responsible for determining the packet forwarding behavior by tJ1e data plane. Independent control plane processes may be provided; however, they are considered to be a single network entity that is a uniquely addressable port. Packets thus intended for the control plane always pass through a designated point. As a resuh, a set of port services w1iquc 10

the control plane may be applied to the control plane port. These control plane port services thus can be utilized 10

courrol all packet twfl:'ic enrnring and exi ting the control p lane processes as a whole.

72 Claims, 6 Drawing Sheets

F-ORWAROING INTAl<ES .!§Q .ACCESS CO.'fTROI. LISTS )j1 PER flOW OOS, ele. ill

12' AGGRl:GATECP SERVICES lli

ROUTE PROCESSOR

DATA PLAKE

135

All PACKETS

110

120

AU. PACKETS

UNECARil


2

Appx000053

100

CO

NTR

OL

CP

PLAN

E PR

OC

ESSO

R

150

155

CP

14

0--

'! I

PA

CKE

TS

12

5--

-J

AGG

REG

ATE

CP

SER

VIC

ES 1

45

'ALL

I

PAC

KETS

,...

, C

EN

TR

An

SW

ITC

H

ENG

INE

130

I

v]

DATA

J

if PA

~~~T

S PL

ANE

135

110..

..,_

I LI

NEC

ARD

I 11

0~

LI

NEC

ARD

I

120

._/

V

V120

._

/ V

12

0 ._

/ V

V1

20 .

_/

V

FIG

. 1

I FORWAA

DIN

G IN

TAKE

S 16

0 .A

CC

ESS

CO

NTR

OL

LIST

S 16

2 PE

R F

LOW

QoS

, etc

. .1fil

n RO

UTE

PR

OC

ESSO

R

ALL

A

PAC

KETS

11

ou

LI

NEC

ARD

...

I

I

120 ._

/ V

v1

20 _

,/

v I

e • 00

. ~

~ ~

('D

=

~

~

::,,:i

'<

N

~'C

N

c::,

c::,

-.l

(J)

c:::r ~

(t, ~ .... 0 .....

0\ d r.n

-l

... N

N .,.. ... 0\

0\

QO

~

I-"


3

Appx000054

ALL

PAC

KETS

""

~-v

LEG

ACY

LIN

ECAR

D

110

CO

NTR

OL

PLAN

E V

--1

50

L, ~

CP P

ACKE

TS

~1

40

AGG

REG

ATE

CP

SER

VIC

ES 1

45

CEN

TRAL

SW

ITC

H

ENG

INE

130

CP

~

PACK

ETS

z), CP

PA

CKE

TS

DIS

TRIB

UTE

D C

P SE

RVI

CES

14§

DIS

TRIB

UTE

D H

-131

SWIT

CH

ENG

INE

\__1

11

FIG

. 2

DIS

TRIB

UTE

D C

P SE

RVI

CES

146

DIS

TRIB

UTE

D

l.+

--1

31

SW

ITC

H

ENG

INE

'"'-

111

110

~

• V'l

• "'t, ~

f""t-~ =

f""t-- s:: ~ '<

N

,..\CJ

N

0 0 ....:i

(J)

::r

('D

('D .. N

0 -.

0\ d 00

--

l 'N

N

,i;:

,...

0\

0-.

Q

C =

~


4

Appx000055

U.S. Patent

CD

lo:: 0 CL

May 29, 2007

LO

~ 0 0..

N

~ 0 CL

0 w (/) I- LU iE 0.. <..) -u> 0:: a::: I- w (/) (/)

0

Sheet 3 of 6 US 7,224,668 Bl

,:f

l-0:: 0 0..

<.9 LL


5

Appx000056

U.S. Patent May 29, 2007 Sheet 4 of 6 US 7,224,668 Bl

LINE CARD RECEIVES THE PACKET AND DELIVERS IT TO CENTRAL SWITCH ENGINE ~ 400

THE CENTRAL SWITCH ENGINE PERFORMS ~ NORMAL INPUT PORT SERVICES AND QOS 402

CENTRAL SWITCH ENGINE PERFORMS L2/L3 SWITCHING OR ROUTING DECISION AND· ~

DETERMINES IF THE PACKET IS DESTINED TO THE CP 403

FOR CP PACKETS, THE CENTRAL SWITCH ENGINE PERFORMS AGGREGATE CP SERVICES (TREATED

~ AS OUTPUT SERVICES FOR THE CP 405 DESTINATION PORT)

BASED ON THE RESULT OF AGGREGATE CP SERVICES, DROP THE PACKET, MARK THE PACKET AND

POTENTIALLY DELIVER THE PACKET TO ~ 406 THE CP FOR FINAL PROCESSING

FIG. 4


6

Appx000057

CO

NFI

GU

RA

TIO

N

500 ~

cla

ss:

teln

et-

cla

ss

ma

tch

acce

ss-g

rou

p 1

40

so2

~ p

olicy:

co

ntr

ol-

pla

ne

-po

licy

503,

_,__

_ cl

ass

te

lne

t-c

lass

po

lice

80

00

0 8

00

co

nfo

rm t

ran

sm

it e

xce

ed

dro

p

505

'""'

-co

ntr

ol-

pla

ne

se

rvic

e-p

olicy

co

ntr

ol-

pla

ne

-po

licy

506

......

_ a

cce

ss-l

ist

14

0 d

en

y t

cp

ho

st

3.3

.3.3

an

y e

q t

eln

et

507-

----

acce

ss-l

ist

14

0 d

en

y t

cp

ho

st

4.4

.4.4

an

y e

q t

eln

et

51

0-"

-acce

ss-l

ist

14

0 p

erm

it tcp

an

y a

ny e

q t

eln

et

FIG

. 5

CO

MM

EN

T

Te

lne

t cla

ss d

efi

ne

d in

te

lne

t-a

cl

A p

olicy m

ap

na

me

d c

on

tro

l-p

lan

e-p

olicy

wh

ich

pro

vid

es a

rate

lim

it o

f 8

0,0

00

b

ps o

f te

lne

t tr

aff

ic:

exce

ed

ing

th

e lim

it

ca

ll b

e d

rop

pe

d

Att

ach

th

e c

on

tro

l p

olicy to

th

e

co

ntr

ol

pla

ne

po

rt

Allo

w 3

.3.3

.3 t

ruste

d h

ost tr

aff

ic

Allo

w 4

.4.4

.4 t

ruste

d h

ost tr

aff

ic

Ra

te lim

it a

ll o

the

r te

lne

t tr

aff

ic

~

• V).

• ~

~

f"'t~ =

f"'t- ~

~

'<

N

\Ci

~ N

0 0 .....

..

00

:r

(D

(D

- Ul 0 _,

0\ d '(J)

-....J

1-..> N ~ °' 0-. Q

O

ed """


7

Appx000058

U.S. Patent May 29, 2007 Sheet 6 of 6 US 7,224,668 Bl

DISTRIBUTED LINECARD RECEIVES THE PACKET ~ AND DELIVERS IT TO THE DISTRIBUTED SWITCH ENGINE 600

THE DISTRIBUTED SWITCH ENGINE PERFORMS ~ NORMAL INPUT PORT SERVICES AND QOS 602

•

DISTRIBUTED SWITCH ENGINE PERFORMS l2/L3 SWITCHING OR ROUTING DECISION AND

DETERMINES IF THE PACKET IS DESTINED 0-- 604

TO THE CP

,

FOR CP PACKETS, THE DISTRIBUTED SWITCH ENGINE PERFORMS DISTRIBUTED CP SERVICES (TREATED ~

AS OUTPUT SERVICES FOR THE CP DESTINATION PORT) 606

BASED ON THE RESULT OF DISTRIBUTED CP SERVICES: DROP THE PACKET, MARK THE PACKET, AND POTENTIALLY ~ DELIVER THE PACKET TO THE CENTRAL SWITCH ENGINE 608

FOR AGGREGATE PROCESSING

THE CENTRAL SWITCH ENGINE PERFORMS AGGREGATE CP SERVICRES AND POTENTIALLY DELIVERS THE

PACKET TO THE CP ~ 610

FIG·. 6


8

Appx000059

US 7,224,668 Bl 1

CONTROL PLANE SECURITY AND TRAFFIC FLOW ~AGEMENT

2 execution of such processes is critical to the operation of the route processor, when such attacks are directed at such functions, they can be devastating.

BACKGROUND OF THE INVENTION DoS attacks that target infrastmc111re devices they may 5 cause a munber of problems. includi11g:

Computer networks, and in part icular the web servers, routers, switches, firewalls and end hosts which make up the Internet as well as private intranets have become critical to the operation of many organizations. Recently there have been a number of highly publicized attacks on network 10 equipment belonging to commercial enterprises, government i11Stitutioos and major internet service providers. This can clearly affect the abi lity of these ins titutions to access information, or even 10 conduct business as usual. Given the widespread adoption of the Internet, in the not to distant t5 future it is foreseeable that such an attack might ac111ally dismpt the conduct of society in general.

It has been estimated that even a three hour outage of the popular Yahoo servers could cause a loss or commerce and advertising revenue of about $500,000.

Tests have determined that over twelve thousand attacks on five thousand distinct Internet hosts belonging to more than two thousand distinct organi2.a1ions occurred during a three week period early in 2002.

20

And, during one week in October 2002, a powerful 25

coordinated electron ic attack was directed to the central thirteen servers that manage global Internet traffic. While the attack only lasted for one hour, it caused seven of the thirteen servers to fail to respond.

loss of line protocol keep alive fonctions, which causes a network connection to drop, leading to route flaps and major network transitions;

loss of routing protocol updates which can also lead route flaps and network transitions;

causing the control plane to utilize more central processing resources than plaru1ed;

causing route processors to lock up, or preventing them from completing higher priority tasks;

reduced response time at user command line prompts, preventing a human administra tor from taking corrective action lo respond to an a1tack;

consumption of route processor resources such as memory, buffers, data structures, causing negative side effects in being able to process other traffic;

back-up of packet q ueues leading to indiscriminanl drops; ttltimately, crashing of the device. Attempts to solve such problems in the past have included

such approaches as Reverse Pass Forwarding (RPF) verification and Selective Packet Discard (SPD). Selectively based distributed packet filtering techniques apply filters to packets arriving from specific known mischievous Internet Protocol (IP) addresses. More sophisticated 1ech1:i.iques can detect forged source IP addresses by detennining the routes from which such dismptive packets originate.

A second technique is to apply an access ljst configured on an inplll interface to explicitly deny or limit specific problematic packet types. Ilardware based rate limits can then be implemented as a throttling mechanism for the specific packet types so identified. For example, packets of the type SYN can be specifically rate limited on a particular port or olher hardware, ar least preventing the rate at which such packets are sent to the control plane. A hardware based rate

·n1ese anacks, often ta.king the form of so-called Denial of 30

Service (DoS) anacks. impede the efficient fi.mctioning and provisioning of services by network infrastructure elements according to their intended purpose. The impact of such auacks is more pronouuced thau network congestion itself, due to the concentrated and targeted ability of such attacks 35 to not only deplete specific resources but also clog traffic. In the extreme case, when such attacks are coordinated and distributed over many internetworking devices, they may result in multiple compromised Internet hosts that can dismpt the operation of the Internet itself.

Susceptibility to DoS attacks is an intrinsic problem for any service provisioning system where the occurrence of a potentially valid event (such as the request to make a connection. e.g., a Transmission Central Protocol (TCP SYN packet)) must first be processed to ascertain its validity. This 45

is true even though the processing resources needed to handle a single event may be negligible. While such attacks cau take on many fom1s, they typically generate traffic streams at very high data rates. The devices attempt to service even the simplest of commands being thrown at it an 50 extraordinary rate can therefore cause the device to fail.

40 limit may be applied to RPF failures, Internet Control Message Protocol (ICMP) unreachables, Time To Live (TTL) failures, Maximum Transmission Unit (MTV) failures, Internet Protocol Version 4 (1Pv4) option bit packets, or similar packers.

More particularly an intemetworking device such as a router typically separates its fllilctionality into control p lane functions and data plane functions. ·n1e data plane is principally responsible for accepting transi t packets at input 55 ports and routing or switching them to output ports. On the other hand, the control plane is responsible for higher layer functions of the device, such as establishing routing tables and entering quality service policies. DoS a11acks are thus conunonly directed at control plane service fi.mctions that 60 reside on route processors such as routers , switches. firewalls and the like, since they are the most likely 10 cause widespread dismption when they fail. These control plane service functions may include the execution of certain protocols such as a Border Gateway Protocol (BGP), Simple 65 Network Management Protocol (SNMP). route table management. memory management and the like. Because the

Wl:i.ile these methods all provide some level of control plane protection. specific features and implementations vary from platform to platform. There also remain packet types and scenarios in which a stated fea11.1re sets do not provide adequate control plane protection.

For example, based on current day capabilities, a system administrator could constnict class maps and policy maps that are specific for control p lane packets of known type. Once created, however, these policies would need lo be included in the access policy for every interface in a network. Since there may typically be hundreds, if not thousands of ports in even a modest network, it is not typically feasible for network administrators to deploy and maintain such features everywhere.

Also, when control plane policies arc defined within input port features, a significant performance impact typically results for transit (that is nou-control plaue) traffic. Because add.itional control plane classes and policies that need to be executed for transit packets as well as control plane destined packets. overall transit traffic performance is markedly reduced. An interface which previously had no configuration, would be forced 10 execute control plane policies for every packet it receives. This performance impact, rather


9

Appx000060

US 7,224,668 Bl 3

than help, could thus actually hinder proper operation of currently deployed infrastructure.

For certain packet types lhat are destined for both lhe transit and control planes (i.e. special broadcasts. 1Pv4 option bits. etc.) it is also not possible to set different yet 5

compatible service policies for packets within such a s ingle class. There is for example nothing inherent in such a packet to help understand whether it is destined to the control plane or should be foiwarded as a transit packet.

Thus, it is also not typically possible in all cases to 10 configure specific classes to identify all control plane destined packet types, since these packet types canuot be readily identified, and current interface policies cannot be configured to control them efficiently.

15 SUMMARY OF THE INVENTION

4 Embodiments of the invention provide lhe ability for a

network administrator to prevent denial of service attacks and provide quality of service for control plane packets. A class of packets to be controlled are defined (such as Telnet SYN) and policies are attached to such class. For example. 011e policy may be to rate li1nit Telnet SYN packets lo a specific rate that is a tolerable rate determined through a specific hardware configuration. The administrator can then apply this limit to the single control plane port, which would limit packets from all ports in the device. A limit command could be applied to the single control plane port rather lhan modifying the configuration on all pons.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other objects, features and advantages of the invention will be apparent from the following more particular description of preferred embocliments of the invention, as illustrated in the accompanying drawings in

The present ilwention is a technique for improved immunity to denial of service attacks. and in general. to provide improved Quali ty of Service (QoS) for network infrastructure equipment.

In one embodiment, an internetworking device or other route processor is composed of two main parts. These include a forwarding path that operates as a data forwarding plane responsible for per packet processing (e.g., forwarding) . . Above the data plane is a network operating system that is responsible for operations in a control plane. ln the case

20 which like reference characters refer 10 tbe same pans throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention.

of a device such as a router or switch, the control plane nins routing, signaling and control protocols that are responsible for detennining the packet forwarcling behavior by the data plane. The control plane in a router. for example, executes routing or switching protocols, manipulates foiwarding tables, per flow quality of service tables, access control lists, and the like.

FIG. 1 is a block diagram overview of an internetworking 25 device having an aggregate control plane services function.

FIG. 2 is a block diagram of a distributed control plane services implementation.

FIG. 3 is a diagram illustrating how distributed control plane services may affect specific ports, and an aggregate

30 control plane services function may provide top level control.

FIG. 4 is a sequence of steps that may be perfonned in routing control plane packets from the data plane to the control plane in one environment.

FIG. 5 is an example of a set of rules that may be used to configure aggregate control plane services to rate limit Telnet traffic.

FIG. 6 is a Bow chart of the process in a distributed switch

In embodiments of the invention, based upon information 35

acquired through its control plane processes, packet forwarding behavior of the data plane elements is thus dictated. Data planes thus typically otherwise include a plurality of ports that define physical collllection points to the network. Port services are then typically applied to operate on packets entering into or exiting from each individual pbysical port.

40 engine environment.

DETAILED DESCRIPTION OF THE INVENTION

In accordance with embodiments oft:he present invention, the control plane processes are implemented as independently executing processes. However. the control place processes are collectively arranged as a single addressable 45

entity, lo provide the ability to belier manage control plane traffic.

A description of preferred embodiments of the invention follows.

FIG. 1 is a block diagram of a typical internetworking device J 00 such as a router, bridge, switch, server or the like in which the invention may be implemented. Such an

More specifically, in embodiments of the invention. a collection of control plane processes are considered to be a single entity that is a uniquely addressable device port. Packets, wbich are destined to specific control plane processes, are now destined through that specific comrol plane port, such that such packets intended for the control plane always pass through this designated port. As a result, a set of port services unique to the control plane may be applied to the aggregate control plane port. These control plane port services thus can be ensured to operate on packets entering and exiting each of the control plane processes.

In one embodiment, packets destined to lhe control plane port can be identified in a munber of ways, such as by using information implicit to specific packets (i.e., the recognition

50 internetworking device 100 consists of a number of functional entities. 111ese include line cards 110 that are responsible for physically attaching to network connections such as ports 120. Each of the line cards 110, typically provide a number of ports 120, such as through Network lnterface

55 Adaptors. Packets received from the ports 120 are fed to a route processor 125. In the case where the device 100 is a router or switch, the processor 125 includes a central switch engine 130. A control plane 150 associated with the device 100 is defined as a collection of processes, typically numing

60 on the route processor 125. These control plane 150 processes collectively provide high level control for most router/switch Input/Output Services (lOS) functions. These control plane 150 processes could be implemented as soft-

of a control plane process address), the result of a routing or switching decision, or by considering other control or configuration information. This a llows a route processor to identify candidate packets destined to the control plane port 65

enabling those packets to be processed by the aggregate control plane port services.

ware at any level of a system, or as hardware. As will be understood shortly, the invention herein con

cerns a control plane port 140. defined as a single access path between the switch engine 130 and the control plane 150.


10

Appx000061

US 7,224,668 Bl 5

The control plane port 140 may or may not be a single physical port. For example. it may be a virtual address through which packets travel or are routed from lhe data plane 135 lo the control plane 150.

6 traclitional hardware port. As a result, a full range of traditional port control features can be applied to help protect the control plane 150 from a DoS attack, or lo provide other QoS. Such control features can, for example, be imple-

More specifically. the line cards llO and central switch engine 130 operate lo accept packets received on a given port 120 and route them through to another output port 120. These forwarding or data plane 135 components are thus responsible for forwarding network transit packets.

5 mented as a set of progranuned mies that determine whether or not packets arriving a t the control plane port 140 qualify for delivery to the control plane and at what level of QoS.

While this will be described in a detailed specific example below. assume as one example that a system administrator

The control plane 150 on the other band. fluictions largely independently of the data plane 135. The control plane 150 is responsible for processing routing, signaling and control protocols that dictate the packet forwarding behavior of the data plane 135. Such protocols typically manipulate forwarding tables 160. per flow Quality of Service (QoS) tables 161, access control lists 162, and lhe like are utilized by the device 100 to make packet forwarding decisions. For example, the control plane 150 might manipulate the forwarding lable 160 in the switch engine 130 or change the state of ooe of the port interfaces 120 in a line card 110 to effect a route change. The control plane 150 is typically not a single process or processor but rather a collection of processes.

10 wouJd like to limit packets of type TCP/SYN that are destined to the control plane 150 to a maximum rate of one megabit per second. With ibe control plane 150 beiJ1g treated as an addressable single port 140, rules can be established to enforce tllis rate lim it, after port input services are applied lo

15 the port 120, and after a switching decision is made in the data plane 130. The mies are applied if and ouJy if a packet has been first determined to have a destination of the control plane 150. The specific control plane feature (i.e .. rate limit with access !isl) can then be applied by the control plane

20 services 145 or 146, thus preventing even correctly addressed packets from progressing up lo any of the control plane processes 155 if the specific rate limit has been exceeded.

TI1e primary goal of Denial of Service (DoS) protection, or otherwise maintaining a specific Qual ity of Service (QoS) 25 at the control plane 150 is to maintain packet forwarding and protocol states while the device 100 is either under attack or experiencing normal to heavy traffic load. Under these conditions. device 100 should continue to process important packets destined to control plane 150 functions, including 30

protocol co11trol packets, Layer 2 (L2) or Layer 3 (L3) keep alive packets. and the like while at the same time maintaining critical Input/O utput Service (]OS) functions.

-n1e central switch engine 130 typically performs high speed Input and Output Services (JOS) for port interfaces 35

such as the line cards 110. An important aspect of the central switch engine 130 is that all packets destined to the control plane 150 musl pass through the central switch engine 130 prior to being routed to the f1u1ctions 155 in the control plane 150. In this instance the central switch engine 130 can be 40

utilized lo implement aggregate control plane protection, for all such processes 155 as will be described below.

An aJternate arrangement shown in FIG. 2, uses a distributed switching engine architecture. This approach provides high speed switching of packets among specialized 45

distributed line cards 111 typically without utilizing any central switch engine 130 resources. ln this architecture, a distributed switch engine 131 may perfon11 input and output services for each respective line card 111 . 1n this instance distributed control plane port services will be utilized to 50

implement the specific aspects of the invention described herein.

Regardless of whether the comrol plane port services are implemented as aggregate port services 145 or as distributed control plane services 146, they perform certain bas ic func- 55 tions. Control plane port services most importantly determine if a given packet is destined to a control plane process 150. Such detemlination can be made through a route look-up mechanism or in other ways. For example, an L2 destination address look-up mechanism may be used for L2 60 port addresses. Alternatively for an L3 port, L3 destination address looJ..."llp functions such as Cisco Express Forwarding (CEF) may be used to identify packets destined to control plane processes 155. Both of the look-up mechanisms are able to identify packets destined for the control plane 150. 65

With processes 155 in the control p lane 150 being treated in this way, the control plane port 140 can be treated as a

In some instances. an administrator nlight employ a more complex set of rules. For example, such niJes might also be put in place to allow only a system administrator to access the router through a trusted host address. 111is allows the administrator to cotmect to the router, even while it is under attack. since the rate limit and access list would permit the session connected from the tnisted host wbiJe rate limiting other connectors.

In a similar fashion. important packets such as routing protocol control packets can be placed in appropriate hierarchical queues based on priority as determined by the user. ll1is potentially can improve routing couvergence rates. ]lrns, the user is atforded significant control over the flow of traffic destined to the control plane 150 just as if the control plane 150 were a hardware interface. Since control plane 150 destined packets will invoke only control plane services, transit traflic and system performance is minimaJly impacted. That is, transit packets will not invoke control plane port services, but will coutinue to invoke normal input and output port services.

FIG. 3 illustrates how the aggregate control plane services 145 and distributed control plane services 146 can be thought of as providing a hierarchical approach (rings of security) to access control. The central, aggregate control plane services 145 provide a level of service (or control) for all packets received from any port 011 the device 100. The distributed control plane services 146 provide a level of service (or control) ouJy for those parts with which they are associated, which may be a single port 120 or mult iple ports 120. A different level of service may therefore result for ports 1 and 2, serviced by distributed services module 146-1, than for a port 5. which is serviced by a different distributed services module 146-2.

ln an implementation such as that shown in FJG. 1, lhc cemral switch engine 130 can provide an aggregate level of control planeservice 145. which is applied to all control plane packets received from all interfaces. Central switch engine 130 executes the input port services for the control plane port 140 making routing decisions for packets designated for the control plane 150.

One example is shown in the flow chart in FIG. 4. In a first state 400, a line card detects a packet and delivers it 10 the central switch engine 130. In a next step 402, the central


11

Appx000062

US 7,224,668 Bl 7

switch engine 130 performs normal input port services and Quality of Service (QoS) processing on the received packet. In a next state 403, the central switch engine 130 performs its normal Layer 2 ru1d Layer 3 switching/routing decision. ln the case of a normal transit packet. the packet would be 5

routed to a destination port 120 on an associated line card 110, using for exrunple. the forwarding table information 160. If, however, the packet is destined for a known control plruie 150 address, or to an address not on a forwarding table 160, the packet is tagged being destined lo as a control plane 10 port. The packet is then routed through the aggregate control plane port 140.

In state 405 the control plane port 140 then perfonns the aggregate control plruie port services on the packet.

In a state 410, based on the results of the aggregate control 15

plane services fonction 145, the control plane port fonclion will either drop the packet. or mark the packet and potentially deliver it to the control plane 150 for processing.

Class maps and policy maps may be used for both DoS protection and packet quality of service. For the single 20 aggregate port 140 these classifications and policies can be applied to in a known fashion. Consider the control plane services pseudo-example described in FIG. 5. Configuration commands are shown on the left hand side with comments on the right hand side. These types of commands are typical 25 rate limit commands fami liar to network administrators. This example is for illustrative purposes only: it should be understood that a whole range of techniques could be used to implement such features.

8 through the distributed control plane services, and thus through the control plru1e port 140.

FIG. 6 is a sequence of steps that may be perfonued to implement the invention in such a distributed control plane environment. In a first state 600 a distributed line card receives a packet delivering it to its associated distributed switch engine. ln a next state 602 the distributed switch engine performs normal input port services aud quality of service processing.

In state 604 the distributed switch engine perfonus a Layer 2 ruid Layer 3 switching routing decision, determining if the packet is destined to the control plane 150. For control plruie packets in state 606, the distributed switch engine then perfonns the distributed control plane services (such as the commands of FJG. 5). In state 608, depending upon the result of those distributed control plane services. the packet is ei ther dropped or marked and potentially delivered to the central switch engine 130.

In a state 610 a central switch engine then performs an aggregate control plane service. for example rate limiting telnet packets and then potentially deliveriug the packet to the control plane should it pass the aggregate control plane services fonctions.

In general, it cru1 be determined through the use of route look-up mechanisms for L3 ports such as a Cisco Express Forwarding CEF decisiou. or a Media Access Coutrol (MAC) layer look-up mechanism for L2 ports, if a given packet or packet strerun has the destination of the control

30 plane. ·n1c particular example limits aggregate control plane services fo r Telnet ty pe traffic. In a first constnaction 500, a class map is defined as "telnet-class". These packets are for example ideutified by matching the telnet access group 140. Telnet access group 140 matches packets with "TCP field" equal to " telnet". In the next definitional statement 502, a 35

policy map is associated with the "control-plane-policy". The next instructions 503 define the policy assigned to the "telnet-class" as allowing 80,000 bits per second of traffic, with excess traffic being dropped. l bis rate limit definition is then attached to the control plaue port by the fo llowiug statement 505, which assigns the service policy of"controlplruie-policy" to the control plane port. Statement SOS represents a control plane port which could be either aggregate 145 or distributed 146. All other commands specified are common and fa miliar to system administrators.

Additional attributes of the port services may be defined

However, candidate packets for control planes services 145 may involve a variety of control packet types that are destined to the control plane 150 even if they do not specifically address the control plane. Most of tbese control plane destined packets fit into one of three categories. These include:

40 L2 control: 111cse packets include keep :tlive and control packets for protocols such ns HDLC. PPP. FRL\"11. 1\TM control ILMJ. x.25 and ISDN call set-up and SOP bpdu.

L3 control: Miscellaneous:

45

May include routing protocol control packets. May include packets destfocd to an Internet Protocol (JP) address local to a specific processor 100 or miscellruteous packets such ns IP options. or special multi-cast brondcast packets. ICMP packets. unroutable packets and so fortb.

as access control lists. For example. in statement 506 a trusted address 3.3.3.3 is considered and a llowed to have any amotmt of Telnet traffic. Similarly. in statement 507 another address of 4.4.4.4 is defined as trusted. However all other 50

Telnet traffic is rate limited by the final access list command 510.

Given that determination, a set of nales is then programmed by a system administrator to determine which packets actually qualify for delivery to the control plane 150 and at what rates. With the invention the control plane 150 now considered as a uniquely addressable destination port 145, and being forced to be so. Tbe system administrator can

The above configuration allows trnsted host with source addresses 3.3.3.3 or 4.4.4.4 to forward teluet packets lo the control plane wi thout rate lim it constraints, and all remaining Telnet packets will be policed to the specified rate.

Specifically, only these packets that match the access control list (ACL) are policed. The last ACL statement 512 includes a match for any packet equal lo Telnet. The deny ACL statements allow those packet types to skip the policer and therefore would always be forwarded.

ln an alternate scenario, a distributed switch engine is used to provide a distributed level of service as per FIG. 2. The distributed switch engine is such that portions may execute on line cards 111, and other portions may execute in a central location lo make the routing decision. But all control plane 150 traffic from all ports 120 still passes

55 now access a full range of traditional port based features. These may include access control lists and quali ty of service features.

The full range of traditional port based featmes applied to the control plane thus replace specialized control plane

60 protection mechanisms. Examples of such supplanted protection mechanisms include SPD or RPF traditional port services. and other specialized control functions. The control plane can now also utilize the same features to not only maintain security but also guarantee quality of service.

65 Although they have been described herein in connection with L2 and L3 packet processing, these fea tures can span the entire lSO seven layer model.


12

Appx000063

US 7,224,668 Bl 9 10

10. A device as in claim 1 wherein the control p lane port services are implemented as distributed control plane port services, and wherein the distributed control plane port services are applied only to the packets received from the

With the control plane being treated as a traditional port, mies can be established using the method according to the invention lhat is enforced after port input services and the switching decision has been made. These rnles are supplied if and only if tl1e packet has been first detennined to have a dest ination of a control plane. As a resull transit packet throughput performance is minimally affected because control plane port services are applied if and only if a packet is first determined to have a comrol plane destination.

5 specific, pre-detennined physical ports.

While this invention has been particularly shown and 10 described wi th references to preferred embodiments thereof, it wiJI be understood by those skiJled in tbe art that various changes in form and details may be made therein without departing from the scope of the invention encompassed by the appended claims.

What is claimed is: l. Au internetwork.ing device comprisi11g:

15

11. A device as in claim 10 wherein the distribu ted control plane port services provide additional levels of port services beyond those provided by an aggregate port services function.

12. A device as in claim 10 wherein one or more distributed switch engines provide the distributed control plane port services.

13. A device as in claim 10 wherein one or more distributed switch engines deliver packets to tl1e control plane port.

14. A device as in claim 10 where multiple levels of service are provided through a combination of aggregate and distributed control plane port services, for packets destined to lhe control plane port. a. a plurality of physical network interface ports, each for

providing a physical connection point to a network for the iJ1ternetworking device, the ports being configurable by control plane processes:

15. A device as in claim 1 wherein a central switch engine 20

delivers control plane packets to the control plane port. 16. A device as in claim l wherein a central switch engine

provides the control plane port services. 17. A device as in claim I wherein tl1e services applied to

b. port services, for operating on packets entering and exiting the physical network interface ports, the port services providing an abi lity to control and monitor packet flows, as defined by control plane configurations;

c. a comrol plane, comprising a plurality of in temetworking control plane processes, the control plane processes for providing high-level control and configuration of

25 the control plane port are selected from U1e group consisting of Q uality of Service (QoS) functions, packet classification, packet marking, packet queuing, packet rate-limiting flow, control, or oilier access policies for packets destined to the control plane port.

the ports and the port services: 30

ct. wherein: i. a control plane port entity provides access to the

coJJection of control plane processes, so that a set of control plane port services can be applied thereto;

35 and

ii. the control plane port services operate on packets received from specific. predetennined physical ports and destined to the collection of control plane processes in a way that is independent of tl1e physical

40 port interfaces and services applied thereto.

2. A device as in claim 1 wherein the control plane processes are accessible tl1rough a control plane port on the internetworking device, such that cont rol plane packets originating a t a plurality of physical ports and destined to 45 one of a plurality of control plane processes are first processed through the control plane port , rather than to individual control plane processes.

3. A device as in claim 2 wherein packets destined to the control plane port are identified using information implicit to 50 the packets, or infonnation specified in configuration of the internetworking device.

4. A device as in claim 3 wherein the control plane port services are applied after a transi t packet forwarding decision is made.

5. A device as in claim 3 wherein Layer 2 control packets are identified and forwarded to the control plane port.

6. A device as in claim 3 wherein Layer 3 control packets arc idemified and forwarded to the co111 rol plane port.

55

7. A device as in claim 1 wherein the control plane 60 processes are distributed across multiple processors.

8. A device as in claim l wllerein the control plane port services are implemented as an aggregate control plane function applied to packets received from multiple physical ports on the interuetworking device.

9. A device as in claim 8 wherein a centr.:11 switch engine performs the aggregate control plane port services.

65

18. A device as in claim 1 where in control plane port services are contro lled and configured as unique entity, separate from physical port services.

19. A method for processing packets in an intemetworking device comprising the steps of:

a. configuring a plurality of physical network interface ports, each port for providing a physical connection point into a network, and tlle ports being configurable by control p lane processes;

b. executing port services on packets entering and exiting the physical network i111erface ports, the port services for controlling and monitoring packet flows as defiaed by control plane co1lfigurations;

c. executing a plurality of control plane processes. the control plane processes providing high level control and configuration of the ports and port services, and additionally comprising U1e steps of: i. accessing the collection of control plane processes as

a control plane port entity. so that a set of control plane port services are applied thereto as a set; and

ii . operating o n packets received fro m specific, predetermined physical ports and destined to the collection of control plane processes in a way that is independent of the ind.ividual physical port interface con-figuration and port services applied thereto.

20. A method as in claim 19 wherein the control plane port processes packets originating at a plurality of physical ports. and additionally comprising the step of:

passing packets thro ugh the control plane port. rather than directly from the physical ports to individual control plane processes.

21. A method as in claim 20 additionally comprising the step of:

identifying packets destined to the control plane port using information implicit to the packet or using information specified in configuration of U1e inlemctworking device.


13

Appx000064

US 7,224,668 Bl 11

22. A method as in claim 21 addjtionally comprising the step of:

applying control plane ports services after a transit packet forwarding decision is made.

23. A method as in claim 19 wherein the control plane 5

processes execute as rustributed processing across multiple processors.

24. A method as in claim 19 wherein the control plane port services execute as an aggregate control plane fi.u1ction applied to packets received from multiple physical ports.

25. A method as in claim 24 wherein a central switch engine provides aggregate control plane port services.

LO

12 control and configuration of the ports and port services. and adrutionally comprising: i. means for accessing the collection of control plane

processes as a control plane port entity, so that a set of control plane port services are applied thereto as a set; and

ii. means for operating 011 packets received from spe-cific, predetermjned physical ports and destined to the collection of control plane processes in a way that is independent of the individual physical port interface configuration and port services applied tbereto.

26. A method as in claim 25 wherein Layer 2 control packets are identified and forwarded to the control plane port.

27. A metl1od as in claim 25 wherein Layer 3 control packets a re identified and forwarded to the control plane port.

38. A device as in claim 37 wherein tl1e control plane port additionally comprises means for processing packets origi

t5 nating at a plurality of physical ports, said means further comprising:

28. A method as in claim 19 additionally comprising the step of applying distributed control plane port services only 20 to the packets received from the specific, pre-determined physical ports.

29. A method as in claim 28 addit ionally comprising lhe step of:

providu1g additional levels of port services beyond those 25

provided by an aggregate port services function. 30. A method as in claim 28 wherein one or more

distributed switch engines provide the distributed control plane port services.

31. A method as in claim 28 wherein one or more 30

distributed switch engines de liver packets to the control plane port.

32. A method as in claim 28 additionally comprising the step ol:

providing multiple levels of service through a combina- 35

tion of aggregate and distributed control plane port services.

33. A method as in claim 19 wherein a central switch engine delivers control plane packets to the control plane port.

34. A method as in claim 19 additionally comprising the step of:

40

means for passing packets through the control plane port, rather than directly from the physical ports to individual control plane processes.

39. A device as in claim 37 additionally cornprisiug: identifying packets destined to the control plane port

using information implicit to the packet or using information specified in configuration of tl1e intemetworking device.

40. A device as in claim 39 additionally comprising the step of:

applying control plane ports services after a transit packet forwarding decision is made.

41. A device as in claim 37 wherein the control plane processes execute as distributed processing across multiple processor means.

42. A device as in claim 37 wherein the control plane port services execute as an aggregate control plaDe means applied to packets received from multiple physical ports.

43. A device as in claim 37 additjonally comprising: means for applying dfatrjbuted control plane port services

only to the packets received from the specific. predetermined physical ports.

44. A device as in claim 43 additionally comprising: means for providing additional levels of port services

beyond those provided by an aggregate port services function.

45. A device as in claim 43 wherein a central switch providing control plane port services in a central switch engine.

35. A method as in claim 19 wherein the step of applying port services to the control plane port additionally comprises a step of applying services selected from a group consisting

engine means provides aggregate control plane port ser-45 vices.

of Quality of Service functions, packet classification, packet marking, packet queuing, packet rate limjting, flow control, and other access policies for packets destined to the control plane port.

36. A method as in claim 19 addit ionally comprising lhe step of:

configuring the control plane port services as an entity separate Crom physical port services.

37. A device for processing packets in an internetworking device comprising:

46. A device as in claim 45 wherein Layer 2 control packets are identified aDd forwarded to tl1e control plane port.

47. A device as in claim 45 wherein Layer 3 control so packets are iden6fied and forwarded to the control plane

port.

55

48. A device as in claim 43 wherein one or more distributed switch engines provide the distributed control plane port services.

a. means for configuring a plurality of physical network interface ports, each po11 for providing a physical connection point into a network, and the pons being 60 configmable by control plane processes:

49. A device as ill claim 43 wherein one or more distributed switch engines deliver packets to the control plane port.

50. A device as in claim 43 additjonally comprising: means for providing multiple levels of service through a

combination of aggregate and rust ributed control plane port services.

51. A device as in claim 37 wherein a central switch engine means delivers coutrol plaue packets to the control plane port.

b. means for executing port services on packets entering and exiting the physical network interface ports, the port services for controlling and monitoring packet flows as defined by control plane configurations;

c. means for executing a plurality of control plane processes, the control plane processes providing high level

52. A device as in claim 37 additionally comprising the 65 step of:

providing control plane port services in a central switch engine.


14

Appx000065

US 7,224,668 Bl 13

53. A device as in claim 37 wherein the means for applying port services to the control plane port additionally comprises means for applying services selected from a group consisting of Quality of Service fonctions, packet classification, packet marking, packet queuing, packet rate 5

limiting, flow controJ, and other access policies for packets destined to the control plane port.

54. A device as in claim 37 additionally comprising: means for configtu·ing the contro l plane port services as an

entity separate from physical port services. 55. A computer readable storage medium containiHg

instructions readable by a computer lo configure ihe computer to perfonu a method for processing packets in an internetworking device comprising:

10

a. configuring a plurality of physical network interface 15

ports, each port for providing a physical connection point into a network, and the ports being configurable by control plane processes;

b. executing port services on packets entering and exiting the physical network iJ1tc.rface ports. the port services 20 for controlling and monitoring packet flows as defined by control plane configurations;

c. executing a plurality of control plane processes, the control plane processes providing high level control and configllfation of the ports and port services, and 25

additionally comprising tl1e steps of: i. accessing the colJection of control plane processes as

a control plane port entity, so that a set of control plane port services are applied thereto as a set; and

ii. operating on packets received from specific, prede- 30

termined physical ports and destined to the collection

14 60. A medium as in claim 55 wherein the control plane

port services execute as an aggregate coutrol plane ftu1ction applied to packets received from multiple physical ports.

61. A medium as in claim 60 wherein a central switch engine provides aggregate control plane port services.

62. A medium as in claim 61 wherein Layer 2 control packets are identified and forwarded to the control plane port.

63. A medium as in c laim 61 wherein Layer 3 control packets are identified and forwarded to the control plane port.

64. A medium as in claim 55 additionally comprising:

applying distributed control plane port services only to the packets received from the specific, pre-determined physical ports.

65. A meditun as in claim 64 additionally comprising:

providing additional levels of port services beyond those provided by an aggregate port services function.

66. A medium as in claim 64 wherein o ne or more d istributed switch engines provide the dist ributed control plane port services.

67. A medium as in claim 64 wherein one or more dis tribu ted switch engines deliver packets to the control plane port.

68 . A mediwn as in claim 64 addi tionally comprising:

providing mult iple levels of service through a combination of aggregate and distributed control plane port services.

69. A medium as in claim 55 wherein a central switch of control plane processes in a way that is independent of the individual physical port interface configuration and port services applied thereto.

56. A medium as in claim 55 wherein the control plane port processes packets originating at a plurality of physical ports. the method additional ly comprising:

t:ngim: ddivt:rs control plant: packt:ts lo Ult: conLrul plant: 35 port.

passing packets through the control plane port. rather thru1 direct ly from the physical ports to individual control p lane processes.

57. A medium as in claim 56 addit ionally comprisiug: identifying packets destined to the control plane port

using information implicit to the packet or using information specified in configuration of the internetworking device.

58. A mediwn as in claim 57 additionally comprising: applying control plane ports services after a transit packet

forwarding decision is made.


providing control plane port services in a central switch engine.

71. A medium as in c laim 55 wherein the step of applying 40 port services to the control plane port additionally comprises

applying services selected from a group consisting of Quality of Service fi.mctions, packet classification, packet marking, packet queuing, packet rate limiting, flow control. and other access policies for packets destined to the control

45 plane po11.

59. A medium as in claim 55 wherein the control plane processes execute as distributed processing across multiple 50


configuri11g Lbe coutrol plane pol1 services as an entity separate from physical port services.

processors. * * * * *


CERTIFICATE OF SERVICE

I hereby certify that on the 25th day of September, 2017, a true and

correct copy of the foregoing document was filed with the clerk of court

using the CM/ECF system, which will send notice of electronic filing to

all CM/ECF participants, resulting in service upon all counsel of record.

/s/ Jason M. Wilcox Jason M. Wilcox


CERTIFICATE OF COMPLIANCE WITH TYPE-VOLUME LIMITATION

Pursuant to Fed. R. App. P. 32(g), the undersigned hereby certifies that this

brief complies with the type-volume limitation of Fed. Cir. R. 32(a).

1. Exclusive of the exempted portions of the brief, as provided in Fed. R.

App. P. 32(a)(7)(B)(iii), the brief contains 11,880 words.

2. The brief has been prepared in proportionally spaced typeface using

Microsoft Word 2016 in 14 point Century Schoolbook font. As permitted by Fed.

R. App. P. 32(g), the undersigned has relied upon the word count feature of this word

processing system in preparing this certificate.

Dated: September 25, 2017 /s/ John C. O’Quinn

John C. O’Quinn


Documents

United States Court of Appeals for the Federal Circuit brief.pdf · Cisco and Arista both appealed certain aspects of the Commission’s decision. Cisco Systems, Inc. v. ITC (Fed