`
`In re inter partes review of:
`
`U.S. Patent 7,224,668 to Smethurst Atty. Docket: 3674.001IPR2
`
`Filed: November 27, 2002
`
`For: Control plane security and traffic
`flow management
`
`IPR2016-00309
`
`
`Declaration of Dr. Kevin C. Almeroth in Support of
`Patent Owner Response
`
`Mail Stop PATENT BOARD
`
`Attn: Patent Trial and Appeal Board
`Commissioner for Patents
`PO Box 1450
`Alexandria, VA 22313-1450
`
`Commissioner:
`
`
`
`I, Dr. Kevin Almeroth, declare as follows:
`
`1.
`
`I have been retained on behalf of Patent Owner, Cisco Systems, Inc.
`
`(“Cisco”), for the above-captioned Patent Owner Response. I understand that this
`
`proceeding involves U.S. Patent No. 7,224,668 (hereinafter referred to as “the ’668
`
`patent” or “Ex. 1001”) titled “Control plane security and traffic flow management”
`
`by Adrian Smethurst et al. and that the ’668 patent is currently assigned to Cisco
`
`Systems, Inc.
`
`
`
`
`
`
`
`Exhibit 2003
`IPR2016-00309
`Page 1
`
`
`
`2.
`
`In forming my opinions expressed in this declaration, I have
`
`considered and relied upon my education, background, and experience. I have also
`
`reviewed and relied upon the following list of materials in preparation of this
`
`declaration, and any other cited reference in this declaration:
`
`1. Petition for Inter Partes Review of claims 1–10, 12, 13, 15–28, 30, 31,
`33–43, 48, 49, 51–64, 66, 67, and 69–72 of the ’668 patent;
`
`2. Declaration of Dr. Bill Lin (Exhibit 1002)
`
`3. U.S. Patent No. 6,674,743 (“Amara”) (Exhibit 1004)
`
`4. U.S. Patent No. 6,460,146 (“Moberg”) (Exhibit 1005)
`
`5. U.S. Patent No. 6,970,943 (“Subramanian”) (Exhibit 1006)
`
`6. U.S. Patent No. 6,115,378 (“Hendel”) (Exhibit 1007)
`
`7.
`
`IETF RFC 2661, “Layer Two Tunneling Protocol ‘L2TP’” (“IETF
`RFC 2661”) (Exhibit 1008)
`
`8. File History of U.S. Patent No. 7,224,668 (Exhibit 1011)
`
`9. April 16, 2015 Edelin Letter, 337-TA-944 and 945 (Exhibit 2001)
`
`10. ANI-ITC-994_945-1824690, CoreBuilder Command Reference Guide,
`337-TA-944 and 945 (Exhibit 2002)
`
`11. May 12, 2015 Edelin Letter, 337-TA-944 and 945 (Exhibit 2003)
`
`12. ANI-ITC-944_945-3444425, CoreBuilder 9000 Implementation Guide,
`337-TA-944 and 945 (Exhibit 2004)
`
`13. Deposition Transcript of Bill Lin, August 23, 2016 (Exhibit 2005)
`
`14. Control Plane Security and Quality of Service Functional
`Specification, Cisco Systems, July 19, 2002 (Protective Order
`Material) (Exhibit 2009)
`
`
`
`Exhibit 2003
`IPR2016-00309
`Page 2
`
`
`
`
`
`
`
`15. Assignment of U.S. Patent Appl. No. 09/205,577, Reel/Frame No.
`009749/0391 (Exhibit 2013)
`
`16. Assignment of U.S. Patent Appl. No. 10/307,154, Reel/Frame No.
`013540/0810 (Exhibit 2014)
`
`17. ’668 Patent Copying Claim Chart (Exhibit 2015)
`
`18. Control Plane Policing Implementation Best Practices, Cisco Systems,
`November 11, 2014 (Exhibit 2016)
`
`19. Cisco Nexus 7000 Series NX-OS Security Config. Guide, Release 6.x,
`Cisco Systems, First Published July 27, 2012, Last Modified April 16,
`2014 (Exhibit 2017)
`
`20. Cisco IOS Software Configuration Guide, Release 12.2(33)SXH, Cisco
`Systems (Exhibit 2018)
`
`21. Infrastructure Protection on Cisco IOS Software-Based Platforms,
`Cisco Systems, 2006 (Exhibit 2019)
`
`22. Cisco Nexus 7000 Series NX-OS Quality of Service Configuration
`Guide, Cisco Systems, April 2014 (Exhibit 2020)
`
`23. Cisco IOS Quality of Service Solutions Configuration Guide, Release
`12.2 (Exhibit 2021)
`
`24. Deploying Control Plane Policing, Cisco Systems, 2005 (Exhibit 2022)
`
`25. CoPP on Nexus 7000 Series Switches, Viral Bhutta, Cisco TAC
`Engineer, September 4, 2014 (Exhibit 2023)
`
`26. Arista Configuration Guide v. 4.14.3F - Rev. 2, Arista Networks,
`October 2, 2014 (Exhibit 2024)
`
`at
`accessed
`Image,
`7508E
`27. Arista
`http://www.arista.com/assets/images/product/7508-specifications.png
`on September 16, 2014 (Exhibit 2025)
`
`28. Arista White Paper, Arista 7500 Switch Architecture, March 2014
`(Exhibit 2026)
`
`
`
`Exhibit 2003
`IPR2016-00309
`Page 3
`
`
`
`
`
`
`
`29. Gary A. Donahue, Arista Warrior, O’Reilly, 2013 (Exhibit 2027)
`
`30. Cisco Nexus 5000 Series NX-OS Security Configuration Guide, Cisco
`Systems, First Published December 5, 2011, Last Modified December
`28, 2011 (Exhibit 2028)
`
`31. Security Configuration Guide: Securing the Control Plane, Cisco IOS
`Release 15.1M&T, Cisco Systems, 2010 (Exhibit 2029)
`
`32. Configuring Control Plane Policing, Cisco Nexus 5000, Cisco Systems
`(Exhibit 2030)
`
`33. Arista EOS 4.15.3F User Manual, Arista Networks, November 20,
`2015 (Exhibit 2031)
`
`34. Examples of Arista’s Copying of Cisco’s Command Expressions
`(Exhibit 2032)
`
`35. Cisco’s Motion for Partial Summary Judgment, Cisco v. Arista, Case
`No. 5:14-cv-5344-BLF (PSG) (Exhibit 2033)
`
`36. An Ex-Cisco Exec Reflects, Adam Lashinsky, Fortune, March 20,
`2014 (Exhibit 2034)
`
`37. How Arista Networks Got Out in Front of the SDN Craze, John
`Gallant, NetworkWorld, February 22, 2013 (Exhibit 2035)
`
`38. Linux as a Switch Operating System: Five Lessons Learned, Kenneth
`Duda, Arista Networks (Exhibit 2036)
`
`39. EOS – Industry Standard CLI (Exhibit 2037)
`
`40. 3Com Switch 4500 Quick Reference Guide (Exhibit 2038)
`
`41. Avaya Ethernet Routing Switch 3500 Series, 2015 (Exhibit 2039)
`
`42. ArubaOS_6.1 Command Line Interface, Aruba Networks, 2011
`(Exhibit 2040)
`
`43. SANS Institute Report, The Changing Face of Distributed Denial of
`Service Mitigation, 2001 (Exhibit 2041)
`
`
`
`Exhibit 2003
`IPR2016-00309
`Page 4
`
`
`
`
`
`
`
`44. Trends in Denial of Service Attack Technology, CERT® Coordination
`Center, 2001 (Exhibit 2042)
`
`45. Arista - Management Team, Arista Networks, 2016 (Exhibit 2043)
`
`46. Cisco Sues Arista, a Rival Run by Former Cisco Employees, Julie
`Bort, Business Insider, December 6, 2014 (Exhibit 2044)
`
`47. Complaint for Copyright and Patent Infringement, Cisco v. Arista,
`Case No. 5-14-cv-05344 (Exhibit 2045)
`
`48. Exemplary Prior Conception Claim Chart (Protective Order Material)
`(Exhibit 2047)
`
`
`3.
`
`I have been asked to provide my technical review, analysis, insights,
`
`and opinions regarding the ’668 patent and the above-noted references.
`
`I.
`
`Qualifications
`
`4.
`
`I hold three degrees from the Georgia Institute of Technology: (1) a
`
`Bachelor of Science degree in Information and Computer Science (with minors in
`
`Economics, Technical Communication, American Literature) earned in June, 1992;
`
`(2) a Master of Science degree in Computer Science (with specialization in
`
`Networking and Systems) earned in June, 1994; and (3) a Doctor of Philosophy
`
`(Ph.D.) degree in Computer Science (Dissertation Title: Networking and System
`
`Support for the Efficient, Scalable Delivery of Services in Interactive Multimedia
`
`System, minor in Telecommunications Public Policy) earned in June, 1997.
`
`
`
`
`
`
`
`Exhibit 2003
`IPR2016-00309
`Page 5
`
`
`
`5.
`
`One of the major themes of my research has been the delivery of
`
`multimedia content and data between computing devices and users. In my research
`
`I have looked at large-scale content delivery systems and the use of servers located
`
`in a variety of geographic locations to provide scalable delivery to hundreds, even
`
`thousands, of users simultaneously. I have also looked at smaller-scale content
`
`delivery systems in which content, including interactive communication like voice
`
`and video data, is exchanged between computers and portable computing devices.
`
`As a broad theme, my work has examined how to exchange content more
`
`efficiently across computer networks, including the devices that switch and route
`
`data traffic. More specific topics include the scalable delivery of content to many
`
`users, mobile computing, satellite networking, delivering content to mobile
`
`devices, and network support for data delivery in wireless network.
`
`6.
`
`Beginning in 1992, when I started graduate school, the first focus of
`
`my research was on the provision of interactive functions (VCR-style functions
`
`like pause, rewind, and fast-forward) for near video-on-demand systems in cable
`
`systems, in particular, how to aggregate requests for movies at a cable head-end
`
`and then how to satisfy a multitude of requests using one audio/video stream
`
`broadcast to multiple receivers simultaneously. Continued evolution of this
`
`research has resulted in the development of new techniques to scalably deliver on-
`
`
`
`
`
`
`
`Exhibit 2003
`IPR2016-00309
`Page 6
`
`
`
`demand content, including audio, video, web documents, and other types of data,
`
`through the Internet and over other types of networks, including over cable
`
`systems, broadband telephone lines, and satellite links.
`
`7.
`
`An important component of my research from the very beginning has
`
`been investigating the challenges of communicating multimedia content between
`
`computers and across networks. Although the early Internet was designed mostly
`
`for text-based non-real time applications, the interest in sharing multimedia content
`
`quickly developed. Multimedia-based applications ranged from downloading
`
`content to a device to streaming multimedia content to be instantly used. One of
`
`the challenges was that multimedia content is typically larger than text-only
`
`content but there are also opportunities to use different delivery techniques since
`
`multimedia content is more resilient to errors. I have worked on a variety of
`
`research problems and used a number of systems that were developed to deliver
`
`multimedia content to users.
`
`8.
`
`In 1994, I began to research issues associated with the development
`
`and deployment of a one-to-many communication facility (called “multicast”) in
`
`the Internet (first deployed as the Multicast Backbone, a virtual overlay network
`
`supporting one-to-many communication). Some of my more recent research
`
`
`
`
`
`
`
`Exhibit 2003
`IPR2016-00309
`Page 7
`
`
`
`endeavors have looked at how to use the scalability offered by multicast to provide
`
`streaming media support for complex applications like distance learning,
`
`distributed
`
`collaboration, distributed games,
`
`and
`
`large-scale wireless
`
`communication. Multicast has also been used as the delivery mechanism in
`
`systems that perform local filtering (i.e., sending the same content to a large
`
`number of users and allowing them to filter locally content in which they are not
`
`interested).
`
`9.
`
`Starting in 1997, I worked on a project to integrate the streaming
`
`media capabilities of the Internet together with the interactivity of the web. I
`
`developed a project called the Interactive Multimedia Jukebox (IMJ). Users would
`
`visit a web page and select content to view. The content would then be scheduled
`
`on one of a number of channels, including delivery to students in Georgia Tech
`
`dorms delivered via the campus cable plant. The content of each channel was
`
`delivered using multicast communication.
`
`10.
`
`In the IMJ, the number of channels varied depending on the
`
`capabilities of the server including the available bandwidth of its connection to the
`
`Internet. If one of the channels was idle, the requesting user would be able to watch
`
`their selection immediately. If all channels were streaming previously selected
`
`
`
`
`
`
`
`Exhibit 2003
`IPR2016-00309
`Page 8
`
`
`
`content, the user's selection would be queued on the channel with the shortest wait
`
`time. In the meantime, the user would see what content was currently playing on
`
`other channels, and because of the use of multicast, would be able to join one of
`
`the existing channels and watch the content at the point it was currently being
`
`transmitted.
`
`11. The IMJ service combined the interactivity of the web with the
`
`streaming capabilities of the Internet to create a jukebox-like service. It supported
`
`true Video-on-Demand when capacity allowed, but scaled to any number of users
`
`based on queuing requested programs. As part of the project, we obtained
`
`permission from Turner Broadcasting to transmit cartoons and other short-subject
`
`content. We also attempted to connect the IMJ into the Georgia Tech campus cable
`
`television network so that students in their dorms could use the web to request
`
`content and then view that content on one of the campus’s public access channels.
`
`12. More recently, I have also studied issues concerning how users choose
`
`content, especially when considering the price of that content. My research has
`
`examined how dynamic content pricing can be used to control system load. By
`
`raising prices when systems start to become overloaded (i.e., when all available
`
`resources are fully utilized) and reducing prices when system capacity is readily
`
`
`
`
`
`
`
`Exhibit 2003
`IPR2016-00309
`Page 9
`
`
`
`available, users’ capacity to pay as well as their willingness can be used as factors
`
`in stabilizing the response time of a system. This capability is particularly useful in
`
`systems where content is downloaded or streamed to user’s on-demand.
`
`13. As a parallel research theme, starting in 1997, I began researching
`
`issues related to wireless devices. In particular, I was interested in showing how to
`
`provide greater communication capability to “lightweight devices,” i.e., small
`
`form-factor, resource-constrained (e.g., CPU, memory, networking, and power)
`
`devices.
`
`14. Starting in 1998, I published several papers on my work to develop a
`
`flexible, lightweight, battery-aware network protocol stack. The lightweight
`
`protocols we envisioned were similar in nature to protocols like Universal Plug and
`
`Play (UPnP) and Digital Living Network Alliance (DLNA).
`
`15. From this initial work, I have made wireless networking—including
`
`ad hoc and mesh networks and wireless devices—one of the major themes of my
`
`research. One topic includes developing applications for mobile devices, for
`
`example, virally exchanging and tracking “coupons” through “opportunistic
`
`contact” (i.e., communication with other devices coming into communication
`
`range with a user). Other topics include building network communication among a
`
`
`
`
`
`
`
`Exhibit 2003
`IPR2016-00309
`Page 10
`
`
`
`set of mobile devices unaided by any other kind of network infrastructure. Yet
`
`another theme is monitoring wireless networks, in particular different variants of
`
`IEEE 802.11 compliant networks, to (1) understand the operation of the various
`
`protocols used in real-world deployments, (2) use these measurements to
`
`characterize use of the networks and identify protocol limitations and weaknesses,
`
`and (3) propose and evaluate solutions to these problems.
`
`16. As an important component of my research program, I have been
`
`involved in the development of academic research into available technology in the
`
`market place. One aspect of this work is my involvement in the Internet
`
`Engineering Task Force (IETF) including many content delivery-related working
`
`groups like the Audio Video Transport (AVT) group, the MBone Deployment
`
`(MBONED) group, Source Specific Multicast (SSM) group, the Inter- Domain
`
`Multicast Routing (IDMR) group, the Reliable Multicast Transport (RMT) group,
`
`the Protocol Independent Multicast (PIM) group, etc. I have also served as a
`
`member of
`
`the Multicast Directorate (MADDOGS), which oversaw
`
`the
`
`standardization of all things related to multicast in the IETF. Finally, I was the
`
`Chair of the Internet2 Multicast Working Group for seven years.
`
`
`
`
`
`
`
`Exhibit 2003
`IPR2016-00309
`Page 11
`
`
`
`17.
`
`I am an author or co-author of nearly 200 technical papers, published
`
`software systems, IETF Internet Drafts and IETF Request for Comments (RFCs).
`
`18. My involvement in the research community extends to leadership
`
`positions for several journals and conferences. I am the co-chair of the Steering
`
`Committee for the ACM Network and System Support for Digital Audio and
`
`Video (NOSSDAV) workshop and on
`
`the Steering Committees for
`
`the
`
`International Conference on Network Protocols (ICNP), ACM Sigcomm
`
`Workshop on Challenged Networks (CHANTS), and IEEE Global Internet (GI)
`
`Symposium. I have served or am serving on the editorial boards of IEEE/ACM
`
`Transactions on Networking, IEEE Transactions on Mobile Computing, IEEE
`
`Transactions on Networks and System Management, IEEE Network, ACM
`
`Computers in Entertainment, AACE Journal of Interactive Learning Research
`
`(JILR), and ACM Computer Communications Review.
`
`19.
`
`I have co-chaired a number of conferences and workshops including
`
`the IEEE International Conference on Network Protocols (ICNP), ACM
`
`International Conference on Next Generation Communication (CoNext), IEEE
`
`Conference on Sensor, Mesh and Ad Hoc Communications and Networks
`
`(SECON), International Conference on Communication Systems and Networks
`
`
`
`
`
`
`
`Exhibit 2003
`IPR2016-00309
`Page 12
`
`
`
`(COMSNETS),
`
`IFIP/IEEE
`
`International Conference on Management of
`
`Multimedia Networks and Services (MMNS), the International Workshop On
`
`Wireless Network Measurement (WiNMee), ACM Sigcomm Workshop on
`
`Challenged Networks (CHANTS), the Network Group Communication (NGC)
`
`workshop, and the Global Internet Symposium; and I have been on the program
`
`committee of numerous conferences.
`
`20. Furthermore, in the courses I teach, the class spends significant time
`
`covering all aspects of the Internet including each of the layers of the Open System
`
`Interconnect (OSI) protocol stack commonly used in the Internet. These layers
`
`include the physical and data link layers and their handling of signal modulation,
`
`error control, and data transmission. I also teach DOCSIS, DSL, and other
`
`standardized protocols for communicating across a variety of physical media
`
`including cable systems, telephone lines, wireless, and high-speed Local Area
`
`Networks (LANs). I teach the configuration and operation of switches, routers, and
`
`gateways including routing and forwarding and the numerous respective protocols
`
`as they are standardized and used throughout the Internet. Topics include a wide
`
`variety of standardized Internet protocols at the Network Layer (Layer 3),
`
`Transport Layer (Layer 4), and above.
`
`
`
`
`
`
`
`Exhibit 2003
`IPR2016-00309
`Page 13
`
`
`
`21.
`
`In addition to having co-founded a technology company myself, I
`
`have worked for, consulted with, and collaborated with companies such as IBM,
`
`Hitachi Telecom, Digital Fountain, RealNetworks, Intel Research, Cisco Systems,
`
`and Lockheed Martin.
`
`22.
`
`I am a Member of the Association of Computing Machinery (ACM)
`
`and a Fellow of the Institute of Electrical and Electronics Engineers (IEEE).
`
`II.
`
`Previous Expert Witness Experience
`
`23. My curriculum vitae attached as Exhibit 2007 to this report contains a
`
`list of cases in which I have testified at trial, hearing, or by deposition within the
`
`preceding four years.
`
`III. Compensation
`I am being compensated for services provided in this case at my usual
`24.
`
`and customary rate of $600/hour. My compensation is not conditioned on the
`
`conclusions I reach as a result of my analysis or on the outcome of this case.
`
`IV. Overview of the Law Used in This Declaration
`A. My Understanding of Claim Construction
`I understand that the claims of a patent are read in light of the
`25.
`
`specification of the patent as understood by a POSITA at the time of the invention.
`
`
`
`
`
`
`
`Exhibit 2003
`IPR2016-00309
`Page 14
`
`
`
`I understand that “the time of the invention” refers to the effective filing date of the
`
`patent in question.
`
`26.
`
`I understand that in this inter partes review the claims must be given
`
`what the Board refers to as the “broadest reasonable interpretation,” but that
`
`interpretation must still be consistent with the specification and the understanding
`
`of a POSITA, and it cannot ignore well-settled legal canons for claim construction.
`
`27. To arrive at the “broadest reasonable construction,” I understand that
`
`claim terms are given their plain and ordinary meaning as would be understood by
`
`a person of ordinary skill in the art, unless the inventor provides a special meaning
`
`for a term.
`
`28.
`
`I understand that evidence that is intrinsic to the patent and
`
`prosecution history is given more weight that extrinsic evidence. For example, if
`
`there are specific statements in the specification that define the invention, those
`
`statements are strong evidence of a definition for a term.
`
`29.
`
`In this declaration, I have used what I believe to be the broadest
`
`reasonable interpretation of the claims and their specific terms. I have also
`
`reviewed and considered, where indicated, the Board’s construction of relevant
`
`terms in this proceeding.
`
`
`
`
`
`
`Exhibit 2003
`IPR2016-00309
`Page 15
`
`
`
`B. My Understanding of Obviousness
`I understand that a patent claim is invalid if the claims would have
`30.
`
`been obvious to a Person of Ordinary Skill in the Art (“POSITA”) at the effective
`
`filing date of the patent. I understand that the obviousness inquiry should not be
`
`done in hindsight, but from the perspective of a POSITA as of the effective filing
`
`date of the patent claim.
`
`31.
`
`I understand that to obtain a patent, the claims must have, as of the
`
`effective filing date, been nonobvious in view of the prior art in the field. I
`
`understand that a claim is obvious when the differences between the subject matter
`
`sought to be patented and the prior art are such that the subject matter as a whole
`
`would have been obvious to a POSITA at the time the invention was made.
`
`32.
`
`I understand that obviousness can be established by combining
`
`multiple prior art references to meet each and every claim element, but I also
`
`understand that a proposed combination of references can be susceptible to
`
`hindsight bias.
`
`33.
`
`I understand that a patent claim is invalid if the claimed invention
`
`would have been obvious to a person of ordinary skill in the field at the time the
`
`application was filed. This means that even if all of the requirements of the claim
`
`
`
`
`
`
`
`Exhibit 2003
`IPR2016-00309
`Page 16
`
`
`
`cannot be found in a single prior art reference that would anticipate the claim, the
`
`claim can still be invalid.
`
`34. As part of this inquiry, I have been asked to consider the level of
`
`ordinary skill in the field that someone would have had at the time the claimed
`
`invention was made. In determining the level of ordinary skill, I considered the
`
`following:
`
`• the levels of education and experience of persons working in the field;
`
`• the types of problems encountered in the field; and
`
`• the sophistication of the technology.
`
`
`35.
`
`I understand that to obtain a patent, a claimed invention must have, as
`
`of the effective filing date, been nonobvious in view of the prior art in the field. I
`
`understand that an invention is obvious when the differences between the subject
`
`matter sought to be patented and the prior art are such that the subject matter as a
`
`whole would have been obvious at the time the invention was made to a person
`
`having ordinary skill in the art.
`
`
`
`
`
`
`
`Exhibit 2003
`IPR2016-00309
`Page 17
`
`
`
`36.
`
`I understand that to prove that prior art or a combination of prior art
`
`renders a patent obvious, it is necessary to (1) identify the particular references
`
`that, individually or in combination, make the patent obvious; (2) specifically
`
`identify which elements of the patent claim appear in each of the asserted
`
`references; and (3) explain how the prior art references could have been combined
`
`or modified to create the invention claimed. I understand that, to support a
`
`conclusion of obviousness, there must be an apparent reason for a skilled artisan to
`
`combine or modify the prior art references as recited in the claims.
`
`37.
`
`I understand that certain secondary considerations can be important
`
`evidence regarding whether a patent is obvious or nonobvious. Such indicia
`
`include: commercial success of products covered by the patent claims; a long-felt
`
`need for the invention; failed attempts by others to make the invention; copying of
`
`the invention by others in the field; unexpected results achieved by the invention as
`
`compared to the closest prior art; praise of the invention by others in the field,
`
`including Petitioner; the taking of licenses under the patent by others; expressions
`
`of surprise by experts and those skilled in the art at the making of the invention;
`
`and the patentee proceeded contrary to the accepted wisdom of the prior art.
`
`
`
`
`
`
`
`Exhibit 2003
`IPR2016-00309
`Page 18
`
`
`
`38.
`
`I understand that exemplary rationales that may support a conclusion
`
`of obviousness include: combining prior art elements according to known methods
`
`to yield predictable results; simple substitutions of one known element for another
`
`to obtain predictable results; using a known technique to improve similar devices
`
`in the same way; applying a known technique to a known device ready for
`
`improvement to yield predicable results; choosing from a finite number of
`
`identified, predicable solutions, with a reasonable expectation of success; known
`
`work in one field of endeavor may prompt variations of it for use in either the same
`
`field or a different one based on design incentives or other market forces if the
`
`variations are predicable to one of ordinary skill in the art; and some teaching,
`
`suggestion, or motivation in the prior art that would have led one of ordinary skill
`
`to modify the prior art reference or to combine prior art teachings to arrive at the
`
`claimed invention.
`
`C. Level of Ordinary Skill in the Art
`I have been asked to consider the level of ordinary skill in the art that
`39.
`
`someone would have had as of September-November, 2002. With nearly 30 total
`
`years of experience in networking, I am well informed with the level of ordinary
`
`skill, which takes into consideration:
`
`
`
`• levels of education and experience of persons working in the field;
`
`Exhibit 2003
`IPR2016-00309
`Page 19
`
`
`
`
`
`• types of problems encountered in the field; and
`
`• sophistication of the technology.
`
`40.
`
`In determining the characteristics of a hypothetical person of ordinary
`
`skill in the art of the ’668 Patent at the time of the claimed invention, I considered
`
`several things, including the various approaches to networking devices employed
`
`in the prior art, the type of problems encountered, and the rapidity with which
`
`innovations were made. I also considered the sophistication of the technology
`
`involved, and the educational background and experience of those actively
`
`working in the field. Finally, I placed myself back in the relevant timeframes and
`
`considered the engineers that I had taught and worked with in the computing and
`
`networking industry. With respect to the ’668 Patent, I came to the conclusion that
`
`the characteristics of 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.
`
`41. Throughout my declaration, even if I discuss my analysis in the
`
`present tense, I am always making my determinations based on what a person of
`
`
`
`
`
`
`
`Exhibit 2003
`IPR2016-00309
`Page 20
`
`
`
`ordinary skill in the art (‟POSITAˮ) would have known at the effective filing date.
`
`Additionally, throughout Sections V-XIV of my declaration, I am referring to a
`
`POSITA’s understanding, even when I discuss something stating ‟I.ˮ
`
`V. Background of the Technology
`A. Denial of Service (DoS) Attacks
`42. A Denial of Service (DoS) attack is a malicious computer program
`
`designed to make a machine or network resource unavailable to its intended users,
`
`causing an interruption or suspension of services. In the typical DoS attack, the
`
`targeted resource is flooded with requests, overloading the system and preventing
`
`legitimate requests from being fulfilled. A distributed denial of service (DDoS)
`
`attack is a DoS attack where the source is numerous and distributed.
`
`43. Networks such as the Internet and intranets are vulnerable to DoS
`
`attacks because even an ordinary request can be used to cause systemic failure.
`
`That is, the disruption is typically caused by the “flooding” or overrunning of the
`
`target with too many requests for it to process. Thus, even though the resources
`
`required to handle one, or even a reasonable number, of the same type of request
`
`may be negligible from a performance standpoint, the DoS attack exploits the
`
`common appearance of this traffic to overwhelm its target and cause it to fail.
`
`
`
`
`
`
`
`Exhibit 2003
`IPR2016-00309
`Page 21
`
`
`
`44. Numerous types and sub-types of DoS attacks have been developed
`
`and deployed over the years, but in the typical case they generate traffic streams
`
`with very high data rates. These traffic streams are generally directed to resources
`
`within the network device that are most likely to fail when subjected to high data
`
`rates. Specifically, many network devices are segmented into two planes of
`
`operation: the data plane and the control plane. The data plane performs the
`
`network functions of a device, and the control plane governs the network functions
`
`of a device. For example, the control plane typically holds the configuration of a
`
`network device, and is responsible for providing the configuration mechanisms of
`
`a device, like a command-line interface. The control plane is often a collection of
`
`processes, typically executed by one or more CPUs. The data plane, for example,
`
`in the case of a router or switch, performs the forwarding of packets according the
`
`configuration specified by the control plane. Because the data plane actually
`
`performs network functions on incoming packets, the data plane is designed to
`
`handle very high amounts of traffic, and thus is less susceptible to DoS attacks.
`
`The speed at which the data plane operates can be referred to as “line speed” or
`
`“fast path.” The control plane, on the other hand is typically only required to
`
`handle small amounts of traffic because a network device is not reconfigured that
`
`often. Thus, the “control plane” is often referred to as the “slow path.”
`
`
`
`
`
`
`
`Exhibit 2003
`IPR2016-00309
`Page 22
`
`
`
`45. Because the control plane is typically not designed to handle large
`
`amounts of traffic, the control plane is more susceptible to DoS attacks. That is, an
`
`attacker who directs traffic to the control plane of a device can overload a device
`
`with relatively less overall traffic than if the traffic were destined to the data plane.
`
`If a device’s control plane is overloaded, the device will typically not be able to
`
`handle any traffic on the data plane either because the overwhelmed main
`
`processor of the network device causes the entire device to halt. Since control
`
`plane based DoS attacked typically use less traffic, many DoS attacks were
`
`directed to the control plane instead of the data plane.
`
`Problems Caused by DoS Attacks
`
`B.
`46. By the late 1990’s, networks such as the Internet had become critical
`
`to many organizations both public and private, commercial and governmental. The
`
`general objective of a typical DoS attack is to deprive access to resources made
`
`available on a network. For example, a successful DoS attack on an e-commerce
`
`website could result in millions of customers being denied access to the site—an e-
`
`commerce website’s only storefront. Consequently, DoS attacks have the potential
`
`to cause significant economic damage, as well as severe aggravation.
`
`47. During the late 1990’s, society was becoming increasingly dependent
`
`on networks and the Internet became part of our national infrastructure. As a result,
`
`
`Exhibit 2003
`IPR2016-00309
`Page 23
`
`
`
`
`
`DoS attacks posed a worsening threat. During the late 1990’s and early 2000’s,
`
`DoS attacks claimed responsibility for numerous disastrous disruptions. In 2000,
`
`search giant Yahoo.com experienced an extended outage after being victimized by
`
`a DDoS attack. Other major sites were similarly victimized, including e-commerce
`
`megalith Amazon.com, Buy.com (attacked an hour after its initial public offering),
`
`ZDNet.com, E-Trade.com, eBay.com, and CNN.com. Sources estimated that these
`
`attacks caused over $1 billion in economic damage, with the attack on Amazon
`
`alone costing between $200,000 and $300,000 per hour. (Ex. 2041 at 1.) That does
`
`not include loss of goodwill, public trust, and corporate reputation.
`
`48. For those on the frontlines trying to prevent or mitigate the impact of
`
`such attac