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
`____________________
`
`
`PATENT OWNER RESPONSE
`
`
`
`
`
`Mail Stop PATENT BOARD
`Patent Trial and Appeal Board
`U.S. Patent & Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`
`
`
`
`
`
`
`
`
`

`
`
`
`I.
`
`II.
`
`
`
`IPR2016-00309
`U.S. Patent No. 7,224,668
`
`
`Table of Contents
`
`Introduction. ..................................................................................................... 1
`
`The ’668 patent introduced a novel internetworking device that provides
`improved security and Quality of Service (QoS). ........................................... 4
`
`A. Denial of Service (DoS) attacks caused significant problems for
`networks. ............................................................................................... 4
`
`B.
`
`Existing approaches to addressing DoS attacks had serious limitations.
` ............................................................................................................... 6
`
`C.
`
`The ’668 patent presents the novel solution to handling DoS attacks. . 7
`
`III. Claim construction. ........................................................................................11
`
`IV. Ground 1: Petitioner fails to show that claims 1–6, 8, 9, 15–22, 24–27, 33–
`40, 42, 51–58, 60–63, and 69–72 are obvious over Amara and CoreBuilder.
` .......................................................................................................................11
`
`A. Overview of Amara’s packet-forwarding device. ...............................12
`
`B.
`
`C.
`
`Overview of CoreBuilder’s administration console. ...........................13
`
`Petitioner fails to show that the combination of Amara and
`CoreBuilder teaches or suggests all of the elements of the challenged
`independent claims. .............................................................................15
`
`1.
`
`2.
`
`Petitioner fails to show that the combination teaches or suggests
`that “the control plane port services operate on packets … in a
`way that is independent of the physical port interfaces and
`services applied thereto” (elements 1.5/19.5/55.5). ..................15
`
`Petitioner fails to show that the combination of Amara and
`CoreBuilder disclose “the port services providing the ability to
`control and monitor packet flows, as defined by control plane
`configurations” (elements 1.2/19.2/55.2). ................................29
`
`D.
`
`Petitioner has not established that CoreBuilder is a prior art printed
`publication under § 102. ......................................................................30
`- i -
`
`
`
`
`
`

`
`
`
`
`
`IPR2016-00309
`U.S. Patent No. 7,224,668
`
`
`V. Ground 2: Petitioner fails to show that claims 7, 23, 41, and 59 are obvious
`in view of Amara, CoreBuilder, and Moberg under 35 U.S.C. § 103. ..........32
`
`A.
`
`The invention of Moberg. ....................................................................33
`
`B. Moberg cannot be used to demonstrate unpatentability of the ʼ668
`patent. ..................................................................................................34
`
`C.
`
`The inventors of the ʼ668 patent conceived of the invention prior to
`October 1, 2002. ..................................................................................35
`
`D. Mr. Ogozaly and the prosecuting attorney exercised reasonable
`diligence to reduce to practice the invention claimed in the ’668
`patent. ..................................................................................................37
`
`E. Moberg cannot preclude patentability of the ʼ668 patent under 35
`U.S.C. § 103(c). ...................................................................................42
`
`F.
`
`The combination of Amara, CoreBuilder, and Moberg does not teach
`or suggest distributing control plane processes across multiple
`processors. ...........................................................................................43
`
`VI. Ground 4: Petitioner fails to show that claims 10, 12, 13, 28, 30, 31, 64, 66,
`and 67 are obvious in view of Amara, CoreBuilder, and Hendel under 35
`U.S.C. § 103. ..................................................................................................47
`
`A. Hendel’s distributed network elements. ..............................................48
`
`B.
`
`Petitioner fails to show a POSITA would have been motivated to
`combine Amara, CoreBuilder, and Hendel. ........................................50
`
`VII. Objective indicia confirm patentability and have nexus to the claims. .........55
`
`A.
`
`B.
`
`C.
`
`D.
`
`The objective evidence has nexus to the claims as a whole................57
`
`Long-felt need. ....................................................................................58
`
`Failure of others. ..................................................................................59
`
`Copying. ..............................................................................................61
`
`
`
`
`- ii -
`
`
`
`

`
`
`
`IPR2016-00309
`U.S. Patent No. 7,224,668
`
`VIII. Conclusion. ....................................................................................................67
`
`
`
`- iii -
`
`
`
`
`
`
`
`
`
`
`

`
`
`
`
`
`IPR2016-00309
`U.S. Patent No. 7,224,668
`
`
`Table of Authorities
`
`
`Cases
`
`Arista Networks, Inc. v. Cisco Systems, Inc.,
`IPR2015-00974, Paper 7 (PTAB Feb. 16, 2016) ..................................................... 29
`
`Bey v. Kollonitsch,
`806 F.2d 1024 (Fed. Cir. 1986)................................................................................ 38
`
`CAE Screenplates v. Heinrich Fiedler GmbH,
`224 F. 3d 1308 (Fed. Cir. 2000)............................................................................... 28
`
`Emery v. Ronden,
`188 U.S.P.Q. 264 (Bd. Pat. Inter. 1974) .................................................................. 41
`
`In re Enhanced Security Research, LLC,
`739 F.3d 1347 (Fed. Cir. 2013)................................................................................ 41
`
`Kridl v. McCormick,
`105 F.3d 1446 (Fed. Cir. 1997)................................................................................ 35
`
`KSR Int’l Co. v. Teleflex, Inc.,
`550 U.S. 398 (2007) ................................................................................................. 50
`
`Mahurkar v. C.R. Bard, Inc.,
`79 F.3d 1572 (Fed. Cir. 1996) .................................................................................. 34
`
`Maxlinear, Inc. v. Cresta Tech. Corp., et al,
`IPR2015-00594, Paper 90 (PTAB Aug. 15, 2016) .................................................. 43
`
`Medichem S.A. v. Rolabo, S.L.,
`437 F.3d 1157 (Fed. Cir. 2006)................................................................................ 37
`
`Mintz v. Dietz & Watson,
`679 F.3d 1372 (Fed. Cir, 2012).......................................................................... 54, 55
`
`Monsanto Co. v. Mycogen Plant Sci., Inc.,
`261 F.3d 1356 (Fed. Cir. 2001)................................................................................ 41
`
`
`
`
`- iv -
`
`
`
`

`
`
`
`
`
`IPR2016-00309
`U.S. Patent No. 7,224,668
`
`
`
`Riverwood Int’l Corp. v. R.A. Jones & Co.,
`324 F.3d 1346 (Fed. Cir. 2003)................................................................................ 42
`
`Singh v. Brake,
`317 F.3d 1334 (Fed. Cir. 2003)................................................................................ 35
`
`Vivid Techs. v. Amer. Science,
`200 F.3d 795 (Fed. Cir. 2000) .................................................................................. 11
`
`Volterra Semiconductor Corp. v. Primarion, Inc.,
`796 F. Supp. 2d 1025 (N.D. Cal. 2011) ................................................................... 43
`
`
`
`Statutes
`
`35 U.S.C. § 102(a) ............................................................................................. 34, 42
`35 U.S.C. § 102(e) ............................................................................................. 34, 42
`35 U.S.C. § 103(c) ............................................................................. 2, 33, 35, 42, 43
`
`Regulations
`
`37 CFR §42.65(a) ............................................................................................... 47, 51
`
`
`
`
`
`
`- v -
`
`
`
`

`
`
`
`Exhibit No.
`2001
`2002
`
`2003
`2004
`
`2005
`2006
`2007
`2008
`2009
`
`2010
`2011
`
`2012
`2013
`
`2014
`
`2015
`2016
`
`2017
`
`2018
`
`
`
`
`
`
`Exhibit List
`
`IPR2016-00309
`U.S. Patent No. 7,224,668
`
`
`Description
`April 16, 2015 Edelin Letter, 337-TA-944 and 945
`ANI-ITC-994_945-1824690, CoreBuilder Command Reference
`Guide, 337-TA-944 and 945
`May 12, 2015 Edelin Letter, 337-TA-944 and 945
`ANI-ITC-944_945-3444425, CoreBuilder 9000 Implementation
`Guide, 337-TA-944 and 945
`
`Deposition Transcript of Bill Lin, August 23, 2016
`Declaration of Dr. Kevin Almeroth
`Dr. Kevin Almeroth Curriculum Vitae
`Declaration of R. Wayne Ogozaly (Protective Order Material)
`Control Plane Security and Quality of Service Functional
`Specification, Cisco Systems, July 19, 2002 (Protective Order
`Material)
`Declaration of Laurie Wall (Protective Order Material)
`Cisco E-bill Records of the Hamilton Brook Invoice for ’668 Patent
`Application (Protective Order Material)
`Declaration of David J. Thibodeau, Jr. (Protective Order Material)
`Assignment of U.S. Patent Appl. No. 09/205,577, Reel/Frame No.
`009749/0391
`Assignment of U.S. Patent Appl. No. 10/307,154, Reel/Frame No.
`013540/0810
`’668 Patent Copying Claim Chart
`Control Plane Policing Implementation Best Practices, Cisco
`Systems, November 11, 2014
`Cisco Nexus 7000 Series NX-OS Security Config. Guide, Release
`6.x, Cisco Systems, First Published July 27, 2012, Last Modified
`April 16, 2014
`Cisco IOS Software Configuration Guide, Release 12.2(33)SXH,
`Cisco Systems
`
`- vi -
`
`
`
`

`
`
`
`Exhibit No.
`2019
`
`2020
`
`2021
`
`2022
`2023
`
`2024
`
`2025
`
`2026
`2027
`2028
`
`2029
`
`2030
`
`2031
`
`2032
`2033
`
`2034
`
`2035
`
`
`
`
`
`
`IPR2016-00309
`U.S. Patent No. 7,224,668
`
`
`Description
`Infrastructure Protection on Cisco IOS Software-Based Platforms,
`Cisco Systems, 2006
`Cisco Nexus 7000 Series NX-OS Quality of Service Configuration
`Guide, Cisco Systems, April 2014
`Cisco IOS Quality of Service Solutions Configuration Guide,
`Release 12.2
`Deploying Control Plane Policing, Cisco Systems, 2005
`CoPP on Nexus 7000 Series Switches, Viral Bhutta, Cisco TAC
`Engineer, September 4, 2014
`Arista Configuration Guide v. 4.14.3F - Rev. 2, Arista Networks,
`October 2, 2014
`Arista 7508E Image, accessed at
`http://www.arista.com/assets/images/product/7508-
`specifications.png on September 16, 2014
`Arista White Paper, Arista 7500 Switch Architecture, March 2014
`Gary A. Donahue, Arista Warrior, O’Reilly, 2013
`Cisco Nexus 5000 Series NX-OS Security Configuration Guide,
`Cisco Systems, First Published December 5, 2011, Last Modified
`December 28, 2011
`Security Configuration Guide: Securing the Control Plane, Cisco
`IOS Release 15.1M&T, Cisco Systems, 2010
`Configuring Control Plane Policing, Cisco Nexus 5000, Cisco
`Systems
`Arista EOS 4.15.3F User Manual, Arista Networks, November 20,
`2015
`Examples of Arista’s Copying of Cisco’s Command Expressions
`Cisco’s Motion for Partial Summary Judgment, Cisco v. Arista,
`Case No. 5:14-cv-5344-BLF (PSG)
`An Ex-Cisco Exec Reflects, Adam Lashinsky, Fortune, March 20,
`2014
`How Arista Networks Got Out in Front of the SDN Craze, John
`- vii -
`
`
`
`

`
`
`
`Exhibit No.
`
`2036
`
`2037
`2038
`2039
`2040
`2041
`
`2042
`
`2043
`2044
`
`2045
`
`2046
`
`2047
`
`
`
`IPR2016-00309
`U.S. Patent No. 7,224,668
`
`
`Description
`Gallant, NetworkWorld, February 22, 2013
`Linux as a Switch Operating System: Five Lessons Learned,
`Kenneth Duda, Arista Networks
`EOS – Industry Standard CLI
`3Com Switch 4500 Quick Reference Guide
`Avaya Ethernet Routing Switch 3500 Series, 2015
`ArubaOS_6.1 Command Line Interface, Aruba Networks, 2011
`SANS Institute Report, The Changing Face of Distributed Denial of
`Service Mitigation, 2001
`Trends in Denial of Service Attack Technology, CERT®
`Coordination Center, 2001
`Arista - Management Team, Arista Networks, 2016
`Cisco Sues Arista, a Rival Run by Former Cisco Employees, Julie
`Bort, Business Insider, December 6, 2014
`Complaint for Copyright and Patent Infringement, Cisco v. Arista,
`Case No. 5-14-cv-05344
`Cisco Guidelines for Patent Attorneys, 2002 (Protective Order
`Material)
`Exemplary Prior Conception Claim Chart (Protective Order
`Material)
`
`
`
`
`- viii -
`
`
`
`

`
`
`
`I.
`
`Introduction.
`
`
`
`IPR2016-00309
`U.S. Patent No. 7,224,668
`
`The present proceeding is the third attempt by Petitioner Arista to invalidate
`
`the challenged claims of the ’668 patent. The Board denied the first two challenges
`
`at institution finding that Petitioner failed to establish a reasonable likelihood that
`
`the challenged claims are unpatentable. Although the Board instituted the third
`
`Petition, Patent Owner now has the opportunity to provide evidence to the Board
`
`that demonstrates Petitioner’s newest challenge is also fatally flawed. Indeed, after
`
`Arista’s multiple attempts, Arista still has not found a single anticipatory reference
`
`for the ’668 patent, and in this third Petition must struggle to cobble together prior
`
`art in a failed attempt to recreate the novel solution of the ’668 patent. The Board
`
`should find all remaining challenged claims patentable over three instituted
`
`grounds because none of the asserted references, either alone or in combination,
`
`teach or suggest all of the elements of the challenged claims, and further in light of
`
`compelling evidence of non-obviousness including Arista’s brazen copying of
`
`Cisco’s patented invention.
`
`Petitioner fails to prove that the combination of Amara and CoreBuilder
`
`discloses or renders obvious independent claims 1, 19, and 55. As an initial matter,
`
`Petitioner fails to establish that CoreBuilder qualifies as a prior art printed
`
`publication under § 102. Petitioner also fails to demonstrate that the combination
`
`teaches or suggests at least two elements of challenged independent claims. First,
`
`
`
`
`
`
`- 1 -
`
`
`
`

`
`
`
`
`
`IPR2016-00309
`U.S. Patent No. 7,224,668
`
`
`the combination does not teach or suggest that “the control plane port services
`
`operate on packets … in a way that is independent of the physical port interfaces
`
`and services applied thereto” because Amara’s policy engines 224–228 (i.e., the
`
`alleged port services) apply only to “external” packets, which are not packets
`
`destined for the control plane (control plane packets). Second, the combination
`
`does not teach or suggest “port services providing the ability to control and
`
`monitor packet flows, as defined by control plane configurations” because
`
`CoreBuilder’s packet filters are incapable of being configured to monitor packet
`
`flows.
`
`Petitioner’s arguments for dependent claims 7, 23, 41, and 59 also fail as an
`
`initial matter because, as shown below, the subject matter of the ’668 patent was
`
`invented prior to the publication data of the Moberg reference, which disqualifies
`
`Moberg as prior art under 35 U.S.C. § 103(c). More importantly, Moberg fails to
`
`disclose “distributing control plane processes across multiple processors” because
`
`Moberg at best only distributes data plane processes, not control plane processes.
`
`Petitioner’s arguments for dependent Claims 10, 28, and 64 also fail because
`
`Petitioner did not adequately articulate a motivation to combine Amara,
`
`CoreBuilder, and Hendel. Petitioner’s motivation to distribute Amara’s “policy
`
`engine 232” (the alleged “control plane port services”) over Hendel’s subsystems
`
`relies solely on the unsupported speculation of its expert Dr. Lin. But Dr. Lin’s
`
`
`
`- 2 -
`
`

`
`
`
`
`
`IPR2016-00309
`U.S. Patent No. 7,224,668
`
`
`unsubstantiated conclusions should be given no weight, leaving Petitioner with no
`
`evidence that a motivation to combine the references exists.
`
`Finally, Cisco sets forth compelling evidence of objective indicia of non-
`
`obviousness. Denial of service (DoS) attacks were a serious problem that affected
`
`network devices at the time of the ’668 patent’s invention. Many others tried and
`
`failed to come up with solutions for DoS attacks. But these solutions were all
`
`unworkable because they, for example, lacked the ability to effectively isolate
`
`control plane traffic from transit traffic, were often too difficult to manage, and
`
`reduced device throughput. The ’668 patent provided an effective solution to DoS
`
`attacks, including by eviscerating such an attack—its reliance on directing traffic
`
`to the control plane as an example. Recognizing the efficacy of Cisco’s patented
`
`solution to DoS attacks, Arista brazenly copied Cisco’s patented invention. But
`
`Arista did not stop there—Arista also copied Cisco’s name for the feature—
`
`Control Plane Policing or “CoPP”—and copied Cisco’s configuration commands
`
`for the feature word-for-word. Such strong evidence of Arista’s copying in the face
`
`of the long-felt need for an effective solution to DoS attacks confirms the non-
`
`obviousness of the challenged claims.
`
`
`
`- 3 -
`
`

`
`
`
`
`
`IPR2016-00309
`U.S. Patent No. 7,224,668
`
`
`II. The ’668 patent introduced a novel internetworking device that
`provides improved security and Quality of Service (QoS).
`A. Denial of Service (DoS) attacks caused significant problems for
`networks.
`
`By 2002, private and public data networks, including the Internet, were
`
`critical to the worldwide communications infrastructure. As the networks’
`
`importance grew, their backbone components—routers, switches, firewalls, and
`
`web servers—became popular targets for attackers. (Almeroth Decl., ¶¶ 46–47.)
`
`One common network attack––DoS––sought to overwhelm a network component,
`
`such as a switch, or router, to prevent it from servicing normal network traffic.
`
`(Almeroth Decl., ¶ 42.) DoS attacks exploit the normal traffic processing
`
`operations of network routing components. (Almeroth Decl., ¶¶ 43–44.)
`
`The ’668 patent explains that a networking device “typically separates its
`
`functionality into control plane functions and data plane functions.” (’668 patent,
`
`1:52–54, 1:54–56 (“The data plane is principally responsible for accepting transit
`
`packets at input ports [of the device] and routing or switching them to output ports
`
`[of the device].”); Almeroth Decl., ¶ 44.) The data plane includes a plurality of
`
`physical ports that define physical connection points to the network, and also “port
`
`services” that can be applied to packets entering into or exiting from the ports.
`
`(’668 patent, 3:38–41; Almeroth Decl., ¶ 44.) In order to prevent device
`
`bottlenecks, data plane functionality, such as input port services, must operate as
`
`
`
`- 4 -
`
`

`
`
`
`
`
`IPR2016-00309
`U.S. Patent No. 7,224,668
`
`
`quickly as possible, ideally at what is called “line speed.” (Ex. 2015, Almeroth
`
`Decl., ¶ 44) Thus, the data plane is commonly referred to as the “fast path,”
`
`because packets require no additional processing from the route processors, and
`
`may be forwarded out of the device at near line speed. (Id.)
`
`The control plane of a device, on the other hand, “is responsible for higher
`
`layer functions of the device, such as establishing routing tables and entering
`
`quality service policies.” (’668 patent, 1:56–59.) The control plane “functions
`
`largely independently of the data plane” and “is responsible for processing routing,
`
`signaling and control protocols that dictate the packet forwarding behavior of the
`
`data plane.” The control plane is typically not a single process or processor but
`
`rather a collection of processes (’668 patent, 5:21–23), typically executed by one
`
`or more CPUs. (Almeroth Decl., ¶ 44.) Packets that must traverse the control plane
`
`are on the “slow path.” (Id.) If the control plane fails, the entire device may
`
`malfunction or fail; consequently, attackers may generate malicious traffic and
`
`direct it to the control plane to overwhelm it. (’668 patent, 1:59–2:3; Almeroth
`
`Decl., ¶ 45.)
`
`A coordinated, widespread DoS attack, over many internetworking devices,
`
`can significantly impact the infrastructure: “[i]n the extreme case, ... result[ing] in
`
`multiple compromised Internet hosts that can disrupt the operation of the Internet
`
`itself.” (’668 patent, 1:36–40; Almeroth Decl., ¶ 48.) For example, a large-scale
`
`
`
`- 5 -
`
`

`
`
`
`
`
`IPR2016-00309
`U.S. Patent No. 7,224,668
`
`
`attack in 2002 resulted in the failure of “seven of the thirteen servers” that
`
`managed global Internet traffic, disrupting Internet traffic around the globe. (’668
`
`patent, 1:25–29.)
`
`B.
`
`Existing approaches to addressing DoS attacks had serious
`limitations.
`
`Prior to the ’668 patent, techniques existed to detect, prevent, and mitigate
`
`DoS attacks were largely ineffective. One approach used “Reverse Pass
`
`Forwarding” or “Selective Packet Discard,” which “[s]electively... appl[ied] filters
`
`to packets arriving from specific known mischievous Internet Protocol (IP)
`
`addresses,” or detected packets having forged addresses. (’668 patent, 2:24–31.)
`
`This approach proved ineffective because it required a network administrator to
`
`know, in advance, a list of mischievous IP addresses, and because it required the
`
`application of filters to every packet received by the ports of a device that
`
`adversely affected throughput. (Almeroth Decl., ¶ 49.)
`
`Another approach used an “access list configured on an input interface to
`
`explicitly deny or limit specific problematic packet types.” (’668 patent, 2:32–34.)
`
`This technique also adversely affected device throughput because the device had to
`
`apply additional classes and policies for every packet received over every
`
`interface, regardless whether the packet was destined for the control plane or data
`
`plane. (’668 patent, 2:59–65; Almeroth Decl., ¶ 50.) Moreover, it was not possible
`
`
`
`- 6 -
`
`

`
`
`
`
`
`IPR2016-00309
`U.S. Patent No. 7,224,668
`
`
`to configure specific classes to identify all control plane destined packet types,
`
`since these packets cannot be readily identified, and policies could not be written
`
`to efficiently control such packets. (’668 patent, 3:10–14.)
`
`C. The ’668 patent presents the novel solution to handling DoS
`attacks.
`
`The inventors of the ’668 patent developed a novel interworking device that,
`
`among other things, better managed DoS attacks and greatly improved QoS.
`
`(Almeroth Decl., ¶ 54.) The technology of the ’668 patent protects the control
`
`plane from threats such as DoS attacks by providing a “single entity” for accessing
`
`the control plane––referred to as a “control plane port entity”––together with a set
`
`of “control plane port services” that may be applied to packets destined for the
`
`control plane in a way that is independent of the physical port interfaces and port
`
`services applied thereto. (’668 patent, 3:48–54.)
`
`The ’668 patent describes two exemplary techniques that provide control
`
`plane port services: “aggregate” control plane port services and “distributed”
`
`control plane port services. (Almeroth Decl., ¶ 55.) Figure 1 (reproduced below)
`
`illustrates an exemplary interworking device that uses “aggregate” control plane
`
`port services. In this embodiment, packets are delivered from the physical ports of
`
`the device to the central switch engine 130. The central switch engine then applies
`
`the normal input port services rules and QoS processing to the packet. (’668 patent,
`
`
`
`- 7 -
`
`

`
`
`
`
`
`IPR2016-00309
`U.S. Patent No. 7,224,668
`
`
`6:67–7:2.) Thus, the normal input port services are applied to packets entering or
`
`exiting the physical network interface ports 120. For example, an administrator
`
`may have general rules, such as access control lists, that should be applied to
`
`receive packets.
`
`
`
`After the normal port services are applied, the central switch engine 130
`
`determines whether the packet is destined for the control plane or remains in the
`
`data plane (i.e., a “transit packet”). (’668 patent, 7:3–11; Almeroth Decl., ¶ 56.) If
`
`the central switch engine 130 determines that the packet is destined for the control
`
`plane, it is routed through the “control plane port entity,” and thereafter “aggregate
`
`control plane port services” are applied to the packet. (’668 patent, 7:11–14.) In the
`
`“aggregate” control plane services embodiment, control plane services can be
`
`
`
`- 8 -
`
`

`
`
`
`
`
`IPR2016-00309
`U.S. Patent No. 7,224,668
`
`
`applied to control plane packets “received from any port on the device.” (’668
`
`patent, 6:45–50.)
`
`
`
`
`
`Figure 2 of the ’668 patent, reproduced above, illustrates an exemplary
`
`internetworking device that uses “distributed” control plane port services.
`
`(Almeroth Decl., ¶ 57.) This embodiment may use both a central switch engine 130
`
`and distributed switch engines 131; when a packet is received, port services are
`
`first applied to packets entering the physical network interface ports by the
`
`“distributed switch engine.” (’668 patent, 8:6–8.) If the distributed switch engine
`
`later determines that the packet is a control plane packet, the distributed switch
`
`engine applies “distributed” control plane port services. (’668 patent, 8:13–16.)
`
`
`
`- 9 -
`
`

`
`
`
`
`
`IPR2016-00309
`U.S. Patent No. 7,224,668
`
`
`This embodiment only applies the “distributed control plane port services” to
`
`control plane packets received at ports with which the distributed control plane
`
`port services are associated. (’668 patent, 6:49–54.) Packets not dropped by the
`
`“distributed control plane port services” are delivered to the central switch engine,
`
`where the central switch engine optionally applies “aggregate control plane port
`
`services,” if they are configured to apply to control plane packets received from
`
`any port on the device. (’668 patent, 8:16–19.) Eventually, packets not dropped by
`
`the “aggregate control plane services,” assuming the aggregate control plane port
`
`services are configured, are delivered to the control plane. (’668 patent, 8:20–24.)
`
`The ’668 patent’s novel approach avoids the limitations of the prior
`
`approaches described in Section II.B above, in which, for example, control-plane-
`
`specific rules apply to traffic received on any port of the device regardless of
`
`whether the traffic is destined for the control plane. (Almeroth Decl., ¶ 58.) By
`
`applying normal 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. Because
`
`control-plane-specific policies are applied only to packets destined for the control
`
`plane, “transit packet throughput performance is minimally affected because
`
`
`
`- 10 -
`
`

`
`
`
`
`
`IPR2016-00309
`U.S. Patent No. 7,224,668
`
`
`control plane port services are applied if and only if a packet is first determined to
`
`have a control plane destination.” (’668 patent, 9:6–9.)
`
`III. Claim construction.
`Petitioner proposes a construction for only one term in the ’668 patent––
`
`“specific, predetermined physical ports.” Patent Owner previously explained in its
`
`preliminary patent owner’s response that the Board should reject Petitioner’s
`
`construction for this term because the term is unambiguous and requires no
`
`construction. Moreover, the Board does not need to construe this term because the
`
`term is not “necessary to resolve the controversy” in this proceeding in view of the
`
`Petitioner’s material deficiencies, already highlighted in the Preliminary Response
`
`and again in this Patent Owner Response. Vivid Techs. v. Amer. Science, 200 F.3d
`
`795, 803 (Fed. Cir. 2000).
`
`IV. Ground 1: Petitioner fails to show that claims 1–6, 8, 9, 15–22, 24–27,
`33–40, 42, 51–58, 60–63, and 69–72 are obvious over Amara and
`CoreBuilder.
`
`Ground 1 relies on two references—Amara and CoreBuilder. Patent Owner
`
`first presents an overview of these references (Sub-sections A and B). Next, Patent
`
`Owner demonstrates these references alone or in combination fail to disclose the
`
`elements of the challenged claims (Sub-section C).
`
`
`
`- 11 -
`
`

`
`
`
`
`
`IPR2016-00309
`U.S. Patent No. 7,224,668
`
`
`A. Overview of Amara’s packet-forwarding device.
`Amara discloses “[a] packet-forwarding device for providing policy-based
`
`services.” (Ex. 1004, Amara, Abstract; Almeroth Decl., ¶ 59.) Amara’s packet-
`
`forwarding device processes two different types of received packets: internally-
`
`destined packets and externally destined packets. (Amara, Abstract.) Internal
`
`packets are associated with “internal applications” that run on the packet-
`
`forwarding device. (Amara, 4:40–43.) External packets are packets that are
`
`destined for other interfaces besides the “internal applications.” (Amara, 4:45–48.)
`
`Like transit packets, the external packets are forwarded from one interface to
`
`another. (Almeroth Decl., ¶ 59.) Amara only references the capabilities of its
`
`‟internal applicationˮ describing that the “internal applications” can “control or
`
`configure the device” and can communicate using various protocols, such as PPTP,
`
`L2TP, SNMP, and Telnet.
`
`Figure 3 of Amara (reproduced below) depicts an exemplary device 200.
`
`Device 200 receives packets via interfaces 202–206. (Almeroth Decl., ¶ 60.) All of
`
`the packets, regardless of the specific interface on which they are received, are
`
`initially classified as external or internal “based on the destination address of the
`
`packets.” (Amara, 1:58–59.) Amara’s “policy engines 224–228” process those
`
`specific external packets—and only those packets—by “appl[ying] a set of rules
`
`specifying the manner in which a given packet should be handled.” (Amara, 5:14–
`
`
`
`- 12 -
`
`

`
`
`
`
`
`IPR2016-00309
`U.S. Patent No. 7,224,668
`
`
`16; Almeroth Decl., ¶ 61.) In contrast to external packets, packets that are
`
`classified as “internal” are only processed by “policy engine 232,” and not “policy
`
`engines 224–228.” (Amara:6:9–15; see also Amara, 5–33–5.)
`
`
`
`B. Overview of CoreBuilder’s administration console.
`CoreBuilder is a router handbook, specifically, a 592-page user guide
`
`“intended for the system or network administrator who is responsible for
`
`configuring, using, and managing the CoreBuilder 3500 system.” (Ex. 2004,
`
`CoreBuilder, p. 21; Almeroth Decl., ¶ 62.) Petitioner, however, only relies on a
`
`small portion of CoreBuilder related to the descriptions of its Administration
`
`Console. The Administration Console, as shown below, is a menu-driven user
`
`interface “for performing system administration such as displaying statistics or
`
`changing option settings” on the CoreBuilder 3500 system. (CoreBuilder, p. 35.)
`
`
`
`- 13 -
`
`

`
`
`
`
`
`IPR2016-00309
`U.S. Patent No. 7,224,668
`
`
`
`
`(CoreBuilder, p. 32.) The Administration Console can be used to configure a
`
`variety of settings in the CoreBuilder system, such as settings for Ethernet
`
`interfaces (p. 72), IP addresses (p. 257), etc. The Administration Console can also
`
`be used to configure certain “packet filters.” (CoreBuilder, p. 210.)
`
`Petitioner relies upon CoreBuilder’s “packet filters” to meet the claimed
`
`“port services…defined by control plane configurations” feature of the claims in
`
`combination with Amara. However, unlike the ’668 patent which describes using
`
`“port services” for a variety of different tasks, such as “monitor[ing] packet flows
`
`as defined by control plane configurations,” CoreBuilder’s packet filters, in
`
`
`
`- 14 -
`
`

`
`
`
`
`
`IPR2016-00309
`U.S. Patent No. 7,224,668
`
`
`combination with Amara, do not teach such capabilities. (CoreBuilder, pp. 209–
`
`250; Almeroth, ¶ 63.)
`
`C.
`
`Petitioner fails to show that the combination of Amara and
`CoreBuilder teaches or suggests all of the elements of the
`challenged independent claims.
`
`The Board should find independent claims 1, 19, and 55 patentable for two
`
`independent reasons. First, the combination of Amara and CoreBuilder does not
`
`teach or suggest both “control plane port services” and “port services” operating on
`
`packets destined to the control plane, as required by the claims. Second, the
`
`combination of Amara and CoreBuilder does not teach or suggest “port services”
`
`that provide the ability to “monitor packet flows” as “defined by control plane
`
`configurations,” because