`
`
`
`April 3, 2008
`
`April 24, 2012
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`8,165,024
`
`
`PATENT:
`
`INVENTORS: Andrew Dolganow
`
`
`
`Keith Allen
`
`
`
`Colin Leon Kahn
`
`FILED:
`
`ISSUED:
`
`USE OF DPI TO EXTRACT AND FORWARD
`
`TITLE:
`APPLICATION CHARACTERISTICS
`____________________________________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________________________________________
`
`VMware, Inc. and Dell Technologies Inc.
`Co-Petitioners
`
`v.
`
`Proven Networks, LLC
`Patent Owner
`___________________________________________
`
`Case IPR 2021-00194
`____________________________________________
`
`DECLARATION OF RICCARDO BETTATI, PH.D.
`U.S. PATENT NO. 8,165,024
`CHALLENGING CLAIMS 1-4, 7-19, and 22-25
`
`
`
`
`
`VMWARE 1003
`
`

`

`TABLE OF CONTENTS
`INTRODUCTION ........................................................................................... 1
`I.
`QUALIFICATIONS AND PROFESSIONAL EXPERIENCE ...................... 1
`II.
`III. MATERIALS CONSIDERED ........................................................................ 3
`IV. LEGAL PRINCIPLES ..................................................................................... 4
`A.
`Claim Construction ............................................................................... 4
`B.
`Obviousness ........................................................................................... 5
`LEVEL OF ORDINARY SKILL IN THE ART ............................................. 7
`V.
`VI. OVERVIEW OF THE ’024 PATENT ............................................................ 9
`A.
`The Purported Invention of the ’024 Patent .......................................... 9
`B.
`Relevant Prosecution History .............................................................. 16
`VII. CLAIM CONSTRUCTION .......................................................................... 18
`VIII. GROUNDS FOR CHALLENGE .................................................................. 18
`A. Overview of Prior Art ......................................................................... 18
`B.
`Ground I: Claims 1-4, 7-19, and 22-25 are anticipated by
`Packeteer ’406 Ground II: Claims 1-4, 7-19, and 22-25 are
`obvious in view of Packeteer ’406 ...................................................... 25
`1.
`Packeteer ’406’s Disclosures .................................................... 25
`2.
`Claim 1 ...................................................................................... 34
`3.
`Claim 2: The method of claim 1, wherein the packet is an
`IP packet, and further comprising: placing the
`information identifying the classification in a header
`extension of the IP packet. ........................................................ 60
`Claim 3: The method of claim 1, further comprising:
`formatting the packet according to a proprietary protocol;
`and placing the information identifying the classification
`in a proprietary protocol extension of the packet. .................... 61
`Claim 4: The method of claim 1, wherein the packet is a
`Generic Routing Encapsulation (GRE) packet. ........................ 61
`Claim 7: The method of claim 1, wherein the step of
`determining the classification for the packet further
`comprises: considering at least one of an effect of the
`
`4.
`
`5.
`
`6.
`
`
`
`i
`
`

`

`8.
`
`9.
`
`7.
`
`packet on a user experience and an importance of the
`packet to the identified application. .......................................... 62
`Claim 8: The method of claim 1, wherein the step of
`performing processing on the packet at the downstream
`device further comprises: performing a traffic
`management function on the packet. ........................................ 63
`Claim 9: The method of claim 8, wherein the traffic
`management function further comprises: dropping the
`packet. ....................................................................................... 64
`Claim 10: The method of claim 8, wherein the traffic
`management function further comprises: modifying a
`quality of service associated with the packet. ........................... 65
`10. Claim 11: The method of claim 1, further comprising:
`selecting the application associated with the active flow
`from the group consisting of an audio application and a
`video application. ...................................................................... 67
`11. Claim 12: the method of claim 1, wherein the at least one
`other packet belongs to the active flow. ................................... 68
`12. Claim 13: The method of claim 1, wherein the at least
`one other packet belongs to a flow other than the active
`flow. .......................................................................................... 68
`13. Claim 14: The method of claim 1, wherein the step of
`performing DPI to identify an application comprises at
`least one of the following: signature matching, pattern
`matching, stateful monitoring, behavioral analysis, and
`statistical analysis. ..................................................................... 69
`14. Claim 15: The method of claim 1, wherein, in performing
`DPI to identify an application, the processor is
`configured to perform at least one of the following:
`signature matching, pattern matching, stateful
`monitoring, behavioral analysis, and statistical analysis. ......... 71
`15. Claim 16 .................................................................................... 71
`16. Claim 17: The device of claim 16, wherein the packet is
`an IP packet and the information identifying the
`classification is placed in a header extension of the IP
`packet. ....................................................................................... 73
`ii
`
`
`
`

`

`17. Claim 18: The device of claim 16, wherein the packet is
`formatted according to a proprietary protocol and the
`information identifying the classification is placed in a
`proprietary protocol extension of the packet. ........................... 73
`18. Claim 19: The device of claim 16, wherein the packet is a
`Generic Routing Encapsulation (GRE) packet. ........................ 74
`19. Claim 22: The device of claim 16, wherein the processor
`determines a classification for the packet by considering
`at least one of an effect of the packet on a user
`experience and an importance of the packet to the
`identified application. ............................................................... 74
`20. Claim 23: The device of claim 16, wherein the
`downstream device performs a traffic management
`function on the packet. .............................................................. 74
`21. Claim 24: The device of claim 16, wherein the at least
`one other packet belongs to the active flow. ............................. 74
`22. Claim 25: The device of claim 16, wherein the at least
`one other packet belongs to a flow other than the active
`flow. .......................................................................................... 74
`Ground III: Claims 7, 11, and 22 are obvious over
`Packeteer ’406 in view of NBAR ........................................................ 75
`1.
`Claim 7: The method of Claim 1, wherein the step of
`determining the classification for the packet further
`comprises: considering at least one of an effect of the
`packet on a user experience and an importance of the
`packet to the identified application ........................................... 75
`Claim 11: The method of claim 1, further comprising:
`selecting the application associated with the active flow
`from the group consisting of an audio application and a
`video application. ...................................................................... 81
`Claim 22: The device of claim 16, wherein the processor
`determines a classification for the packet by considering
`at least one of an effect of the packet on a user
`experience and an importance of the packet to the
`identified application. ............................................................... 84
`IX. AVAILABILITY FOR CROSS EXAMINATION ....................................... 84
`iii
`
`C.
`
`2.
`
`3.
`
`
`
`

`

`RIGHT TO SUPPLEMENT .......................................................................... 85
`JURAT ........................................................................................................... 85
`
`X.
`XI.
`
`
`
`
`iv
`
`

`

`I.
`
`INTRODUCTION
`1. My name is Riccardo Bettati. I am a Professor of Computer Science
`
`& Engineering at Texas A&M University.
`
`2.
`
`I have been retained as an expert in this proceeding by counsel for
`
`VMware, Inc. and Dell Technologies Inc. I have been asked for my expert
`
`conclusions regarding the validity of claims 1-4, 7-19, and 22-25 of U.S. Patent
`
`No. 8,165,024 (the “‘024 patent”) (Ex. 1001). For the reasons set forth below, it is
`
`my conclusion that claims 1-4, 7-19, and 22-25 of the ’024 patent are invalid.
`
`II. QUALIFICATIONS AND PROFESSIONAL EXPERIENCE
`3. My qualifications are stated more fully in my curriculum vitae, which
`
`is attached as Exhibit 1004. Below is a summary of my education, work
`
`experience, and other qualifications.
`
`4.
`
` Since the early nineties I have done research (first at the University of
`
`California at Berkeley, then at Texas A&M University) on network-level support
`
`for distributed applications. Such applications range from distributed multimedia
`
`(video-on-demand, teleconferencing, etc.) to high-performance applications
`
`(networks-of-workstations) to secure computation. As part of the HydraNet1
`
`
`
` 1
`
` For example: H. Chawla, G. Dillon, R. Bettati, "HydraNet: Network Support for
`Scaling of Large-Scale Services." Proceedings of the ICCCN 1998. Lafayette, LA,
`October 1998. (Ex. 1013)
`
`
`
`1
`
`

`

`project at Texas A&M, I published early papers that used (an early form of) Deep-
`
`Packet-Inspection (DPI), where we demonstrated that Internet router functionality
`
`can be extended to inspect TCP header information to support load balancing,
`
`consolidation, and fault tolerance at Internet servers. This later became known as
`
`“transport-level routing.” Since then I have regularly published on enabling
`
`technologies that can be integrated into DPI systems to identify flows in network
`
`links. My attention has been primarily on cases where users apply encryption and
`
`other sophisticated means in an attempt to avoid that their traffic is detected and
`
`identified. This makes any form of DPI impossible that is based on data in
`
`packets. Instead, behavioral and statistical techniques must be applied.2 For cases
`
`where even advanced statistical techniques fail to identify such traffic, we have
`
`developed techniques that allow to separate large groups of traffic flows into
`
`smaller ones, where traffic identification then can be attempted.3
`
`
`
` 2
`
` For example: Y. Zhu, X. Fu, B. Graham, R. Bettati, and W. Zhao, “Correlation-
`Based Traffic Analysis Attacks on Anonymity Networks”, IEEE Transactions on
`Parallel and Distributed Systems, Vol. 21, No. 7, July 2010, pp 954 -- 967. (Ex.
`1014)
`3 For example: Ye Zhu and R. Bettati, “Compromising Anonymous
`Communication Systems Using Blind Source Separation”, ACM Transactions on
`Information and System Security (TISSEC), Vol. 13, No. 1, Article 8, October
`2009, pp. 8:1 - 8.31. (Ex. 1015)
`
`
`
`2
`
`

`

`5.
`
`I am being compensated for my time at my ordinary hourly rate of
`
`$300. My compensation is not dependent on the outcome of these proceedings or
`
`the content of my opinions. To the best of my knowledge, I have no financial
`
`interest in either party or in the outcome of this proceeding.
`
`III. MATERIALS CONSIDERED
`In preparing this declaration, I have reviewed the claims,
`
`6.
`
`specification, and file history of the ’024 patent. I understand that the ’024 patent
`
`issued on April 24, 2012, from U.S. Patent Application No. 12/078,701 (filed April
`
`3, 2008).
`
`7.
`
`I have reviewed and understand the references and exhibits cited in
`
`this Declaration, including the following:
`
`Exhibit
`
`Description
`
`1001
`1002
`1004
`1005
`1006
`1007
`1008
`1009
`
`1010
`
`U.S. Patent No. 8,165,024
`File History for U.S. Patent No. 8,165,024
`Curriculum Vitae of Dr. Riccardo Bettati
`U.S. Pat. No. 7,742,406 (“Packeteer ’406”)
`U.S. Pat. No. 6,591,299 (“Packeteer ’299”)
`U.S. Pat. App. No. 10/720,329 (“Packeteer ’048”)
`Classifying Network Traffic Using NBAR
`“End-to-End QoS Network Design: Quality of Service in LANs,
`WANs, and VPNs” by Tim Szigeti (“Szigeti”)
`U.S. Pat. No. 8,948,206 (“Pelletier”)
`
`
`
`3
`
`

`

`1011
`
`1013
`
`1014
`
`1015
`
`1016
`
`1017
`
`1018
`
`1020
`1021
`
`“Inside Network Perimeter Security, 2nd Edition” by Northcutt,
`Zeltser, Winters, Kent & Ritchey, ©2005, Sams Publishing,
`768 pp (“Northcutt”)
`Hamesh Chawla, HydraNet: Network Support for Scaling of Large-
`Scale Services, Proceedings of the ICCCN 1998, Lafayette,
`LA (October 1998).
`Ye Zhu, et al., Correlation-Based Traffic Analysis Attacks on
`Anonymity Networks, 21(7) IEEE Transactions on Parallel
`and Distributed Systems 954-967 (July 2010)
`Ye Zhu, et al., Compromising Anonymous Communication Systems
`Using Blind Source Separation, 13(1) ACM Transactions on
`Information and System Security (TISSEC) 1-31 (October
`2009)
`Steven McCanne & Van Jacobson, The BSD Packet Filter: A New
`Architecture for User-level Packet Capture , 46 USENIX
`winter (1993)
`Erik Giesa, Apps switches boost availability, 20(9) Network World
`35 (2003) (“Giesa”)
`Martin Roesch, Snort - Lightweight Intrusion Detection for
`Networks, 99(1) Lisa 229-238 (Nov. 7 1999) (“Roesch”)
`U.S. Patent No. 8,514,871
`U.S. Patent No. 8,843,634 (“Packeteer ’634”)
`
`IV. LEGAL PRINCIPLES
`8.
`I am not an attorney. For the purposes of this declaration, I have been
`
`informed about certain aspects of the law that are relevant to my opinions. My
`
`understanding of the law is as follows:
`
`A. Claim Construction
`9.
`I have been informed that claim construction is a matter of law and
`
`that the final claim construction will ultimately be determined by the Board. For
`
`
`
`4
`
`

`

`the purposes of my analysis in this proceeding and with respect to the prior art, I
`
`have been informed that IPRs are currently reviewed under “the Phillips standard.”
`
`10.
`
`I have been informed that under the Phillips standard, claim terms are
`
`given their plain and ordinary meaning as understood by a person of ordinary skill
`
`in the art at the time of the invention in light of the claim language and the patent
`
`specification.
`
`11.
`
`I have been informed that embodiments described in the specification
`
`are encompassed by the claim terms.
`
`B. Obviousness
`12.
`I have been informed and understand that a patent claim can be
`
`considered to have been obvious to a person of ordinary skill in the art at the time
`
`the application was filed. This means that, even if all of the requirements of a
`
`claim are not found in a single prior art reference, the claim is not patentable if the
`
`differences between the subject matter in the prior art and the subject matter in the
`
`claim would have been obvious to a person of ordinary skill in the art at the time
`
`the application was filed.
`
`13.
`
`I have been informed and understand that a determination of whether
`
`a claim would have been obvious should be based upon several factors, including,
`
`among others:
`
`
`
`5
`
`

`

`• the level of ordinary skill in the art at the time the application was
`
`filed;
`
`• the scope and content of the prior art; and
`
`• what differences, if any, existed between the claimed invention and
`
`the prior art.
`
`14.
`
`I have been informed and understand that the teachings of two or
`
`more references may be combined in the same way as disclosed in the claims, if
`
`such a combination would have been obvious to one having ordinary skill in the
`
`art. In determining whether a combination based on either a single reference or
`
`multiple references would have been obvious, it is appropriate to consider, among
`
`other factors:
`
`• whether the teachings of the prior art references disclose known
`
`concepts combined in familiar ways, which, when combined, would
`
`yield predictable results;
`
`• whether a person of ordinary skill in the art could implement a
`
`predictable variation, and would see the benefit of doing so;
`
`• whether the claimed elements represent one of a limited number of
`
`known design choices, and would have a reasonable expectation of
`
`success by those skilled in the art;
`
`
`
`6
`
`

`

`• whether a person of ordinary skill would have recognized a reason to
`
`combine known elements in the manner described in the claim;
`
`• whether there is some teaching or suggestion in the prior art to make
`
`the modification or combination of elements claimed in the patent;
`
`and
`
`• whether the claim applies a known technique that had been used to
`
`improve a similar device or method in a similar way.
`
`15.
`
`I understand that one of ordinary skill in the art has ordinary creativity
`
`and is not an automaton.
`
`16.
`
`I understand that in considering obviousness, it is important not to
`
`determine obviousness using the benefit of hindsight derived from the patent being
`
`considered.
`
`V. LEVEL OF ORDINARY SKILL IN THE ART
`17. A person of ordinary skill in the art (“POSITA”) at the time of the
`
`alleged invention of the ’024 patent would have had at least the equivalent of a
`
`Bachelor’s degree in computer engineering and computer science and four or more
`
`years of experience in networking devices and traffic management design. Less
`
`work experience may be compensated by a higher level of education, such as a
`
`Master’s degree, and vice versa.
`
`
`
`7
`
`

`

`18.
`
`It is my opinion that such a person would have been engaged in
`
`research, learning through study, and practice in the field and possibly through
`
`formal instruction the bibliographic resources relevant to his or her research. By
`
`not later than 2008 such a person would have had access to a vast array of long-
`
`established print resources in the field, as well as to a rich set of online resources
`
`providing indexing information, abstracts, and full text services for publications
`
`relevant to the field of this dispute. Such a person also would have access to
`
`published engineering standards such as the request for comments (RFCs) of the
`
`Internet Engineering Task Force (IETF, www.ietf.org), which by 2008 had
`
`published over 5,000 RFCs defining most technical aspects and protocols that
`
`govern the Internet. Such a person also would have had access to print and online
`
`resources shared with the public for commercial purposes, such as corporate
`
`websites, technical datasheets and other product documentation. Such a person
`
`also would consult libraries and the internet, including consulting websites for
`
`significant companies in the relevant industry, like Cisco, and for companies that
`
`are known to publish on their own website, like Cisco.
`
`
`
`8
`
`

`

`VI. OVERVIEW OF THE ’024 PATENT
`A. The Purported Invention of the ’024 Patent
`19. The ’024 patent is generally directed to the use of DPI to classify
`
`packets based on characteristics of an application associated with the packets. See
`
`Ex. 1001, Title.
`
`20. The term Deep Packet Inspection (or DPI) is used to describe when a
`
`device that performs a function at a given protocol level (in the Internet this is
`
`typically an IP router, which is a Network-level or Level-3 device) uses
`
`information that belongs to a higher-level protocol. For example, a standard IP
`
`router only looks at the destination IP address to forward the packet. A router may
`
`want to route (i.e., send on a different path) WEB traffic differently than, say email
`
`traffic. To do that, it must look at information beyond the destination IP address of
`
`the packet; it has to look “deeper” into the packet.
`
`21. For example, a router may want to do (what is known as ) “transport-
`
`level routing,” in which case it makes the routing decision based on destination IP
`
`address and destination port number. The source and destination port numbers are
`
`located in the bytes directly after the network header. Hence, this is sometimes
`
`called “shallow packet inspection.” In some other cases, the router may have to
`
`look very deep, for example when a router in a large enterprise is situated in front
`
`of a collection of specialized web servers, each of them dealing with a different
`
`
`
`9
`
`

`

`part of a big web site. This router directs incoming WEB requests to the
`
`appropriate server, based on which information the client is requesting. From the
`
`very beginning, operators and their suppliers began to develop increasingly
`
`sophisticated techniques to look into the packets transmitted over their network in
`
`order to collect information about the traffic. These techniques eventually became
`
`known as Deep Packet Inspection.
`
`22. The idea to look increasingly “deeper” into packets was there from the
`
`early nineties. One early system to do this was the BSD Packet Filter (BPF),
`
`which allowed the filtering of packets based on user-specified rules that could
`
`address the entire packet.4 The question was (and still is) how to perform the deep-
`
`packet inspection fast enough (i.e., at line speed) to not delay the traffic. As we
`
`have been developing increasingly faster techniques for packet inspection, we have
`
`been able to “reach deeper” into the packets and take into consideration behavioral
`
`and statistical approaches as well.
`
`23.
`
`In the context of network and computer security, DPI has become
`
`very popular in the early 2000’s. Just as in the networking examples describe
`
`
`
` 4
`
` McCanne, Steven, and Van Jacobson. “The BSD Packet Filter: A New
`Architecture for User-level Packet Capture.” USENIX winter. Vol. 46. 1993. Ex.
`1016.
`
`
`
`10
`
`

`

`above, DPI in the security field has its origins at least as far back as the mid-
`
`nineties. As the Northcutt 2005 textbook points out, “[t]he term Deep Packet
`
`Inspection is actually a marketing buzzword that was recently coined for
`
`technology that has been around for some time; content examination is not
`
`something new. Antivirus software has been doing it at the host and mail server
`
`level, and network IDSs have been doing it on the wire for years.” Ex. 1011, p. 67.
`
`24. The ’024 patent’s background section acknowledges that, by the time
`
`of the ’024 patent, mobile network operators frequently utilized packet marking to
`
`prioritize and forward packets, so that, for example, voice packets might be marked
`
`as higher priority than data packets, to ensure the quality of calls placed over a
`
`mobile network. Ex. 1001, 1:49-57.
`
`25. However, according to the patent, these approaches purportedly
`
`suffered because they relied on end-user equipment to do the marking, reducing the
`
`flexibility of operators to define new applications and markings. Id., 1:58-66.
`
`Moreover, according to the applicants, prior DPI systems “treat[ed] all data packets
`
`associated with an application in the same manner” and, for example, “fail[ed] to
`
`consider that some packets associated with an application flow are more important
`
`than others and therefore fail[ed] to most efficiently utilize bandwidth in the
`
`network.” Id., 2:3-10.
`
`
`
`11
`
`

`

`26. The applicants accordingly claimed that there was a need for a device
`
`that would operate in the network, to characterize packets and convey information
`
`about the packets to downstream components:
`
`“Accordingly, there is a need for an in-line device that
`identifies characteristics of applications associated with
`data packets and conveys this information for downstream
`processing. There is also a need for associating application
`characteristic information with data packets without
`requiring the packet to be marked at end-user equipment.
`In addition, there is a need for packet marking in a mobile
`network that utilizes a packet marking scheme such that a
`large
`number
`of
`applications
`and
`application
`characteristics may be identified at any location in the
`network, without requiring Deep Packet Inspection (DPI)
`processing to be performed at each location. Furthermore,
`there
`is a need for
`identifying characteristics of
`applications to allow downstream processing of packets
`based on the importance of the packets to the application
`flow.” (Id., 2:11-24)
`
`27. To this end, the ’024 inventors proposed a DPI device 150 that would
`
`reside in the network as a standalone device, as shown in Figure 1, or as a
`
`component that could be integrated into a router. See id., 5:39-41.
`
`
`
`12
`
`
`
`

`

`28. This DPI device would identify an application associated with a flow
`
`of packets passing through that device, and classify a packet based on
`
`characteristics of the application. See id., 2:62-3:8. The classification information
`
`could then be inserted into the packet so that another device downstream in the
`
`network could extract the classification information and use it to process that
`
`packet accordingly. See id.
`
`29. Figure 6 shows the basic method of the claimed invention. The DPI
`
`device receives a packet (620) and uses information in the packet’s header to
`
`associate it with a “flow,” which a POSITA would have understood to be a
`
`sequence of related packets typically having, e.g., at least the same source and
`
`destination addresses and port numbers. See id., 8:43-48 (“DPI device 150
`
`intercepts, sniffs, or otherwise receives a packet transmitted from a source node to
`
`a destination node [and] identifies a flow associated with the packet using header
`
`information from the packet”). The DPI device then performs DPI processing
`
`(630) on the packet and identifies an application associated with that packet’s flow.
`
`Id., 8:50-56 (“DPI device 150 examines any combination of information in OSI
`
`layers 3 through 7 of one or more packets to identify an application associated with
`
`the flow. DPI device 150 may determine, for example, whether the flow relates to
`
`
`
`13
`
`

`

`email, streaming video, web browsing, peer-to-peer transfer, Voice over IP (VoIP),
`
`or any other application of interest to the service provider” (emphasis added)5).
`
`30. Once the flow’s application is identified, the DPI device further
`
`classifies (640) the packet based on some underlying characteristic of the
`
`
`
`
`
` All emphasis added unless noted otherwise.
`
`14
`
` 5
`
`
`
`

`

`application. This application characteristic is broad. For example, it may be based
`
`on the “importance of the packet to the user experience” or “the needs of the
`
`application.” Id., 8:62-9:2. Or it may be a “compression scheme” or “data
`
`structure” (id., 5:31-35), or “importance” or “priority” (id., 6:46-50), or “frame[]
`
`type[] used for an encoding scheme” (id., 7:50-54). Indeed, the patent explains
`
`that the further classification can be of “any characteristic of the underlying
`
`application.” Id., 8:6-9; see also id., 8:66-67 (“some other criterion”), 5:34-35
`
`(“any other application characteristic”).
`
`31. Once the packet is classified, the DPI device inserts application
`
`and/or classification information into the packet (650), for example, by adding
`
`“an alphanumeric value identifying the classification of the packet.” Id., 9:8-10.
`
`32. The thus-marked packet is forwarded onto the network (660) and
`
`subsequently received by a downstream device, which can then process (670) the
`
`packet using the inserted classification information, without the need to perform
`
`DPI on that packet itself. For example, “the downstream device may determine
`
`how to treat the packet, including whether to allow the packet to proceed or
`
`whether the packet should instead be dropped.” See Id., 9:45-50.
`
`33. Original claim 1 recited a method directed to performing DPI to
`
`identify an application and classifying packets based on characteristics of that
`
`application:
`
`
`
`15
`
`

`

`1. A method of processing packets sent from a
`source node to a destination node, the method comprising:
`receiving a packet sent from the source node to the
`destination node;
`associating the packet with an active flow by
`accessing information in the packet;
`performing deep packet inspection (DPI) to identify
`an application associated with the active flow;
`determining a classification for the packet based on
`characteristics of the identified application;
`associating, with
`the
`packet,
`identifying the classification;
`forwarding the packet including the information
`identifying the classification towards the destination node;
`and
`
`information
`
`the packet at a
`performing processing on
`downstream device by extracting the classification from
`the packet.
`
`
`Ex. 1002, at 25.
`
`B. Relevant Prosecution History
`34. The ’024 patent application was filed on April 3, 2008. The
`
`applicants at no point submitted any prior art.
`
`35. The examiner initially rejected all claims based on Luft (U.S. Patent
`
`No. 7,606,147) and Wybenga (U.S. Patent No. 7,362,763), finding that they taught
`
`or rendered obvious the network DPI device and method, as recited in the original
`
`claims. See id., at 56 (Non-Final Rejection dated 5/12/2010). The applicants did
`
`not dispute those findings and instead amended the claims to specifically require
`
`
`
`16
`
`

`

`inserting the classification information into the packets before forwarding them.
`
`See id., at 72 (Amendment dated 6/11/2010).
`
`36. The examiner rejected the amended claims based on Olsson (U.S. Pre-
`
`grant Publication No. 2007/0162289) and Taaghol (U.S. Pre-grant Publication No.
`
`2008/0214189) finding that they taught or rendered obvious the network DPI
`
`device and method, including inserting classification information into the packets.
`
`See id., at 199-202 (Non-final Rejection dated 6/7/2011). Applicants did not
`
`dispute those findings and instead amended the claims to require that the DPI step
`
`to identify an application do so “by analyzing at least one other packet.” See id., at
`
`221 (Amendment dated 8/4/2011).
`
`37. The examiner, apparently unaware that this too was known, allowed
`
`the amended claims, noting that “[t]he prior art of record fails to teach the step of
`
`performing DPI to identify an application associated with the active flow by
`
`analyzing at least one other packet in specific combination as recited.” Id., at 271
`
`(Notice of Allowance dated 12/21/2011).
`
`38. The final version of claim 1 is presented below with deletions and
`
`additions made during prosecution indicated with underline and strikethrough,
`
`respectively:
`
`1. A method of processing packets sent from a
`source node to a destination node, the method comprising:
`
`
`
`17
`
`

`

`receiving a packet sent from the source node to the
`destination node;
`associating the packet with an active flow by
`accessing information in the packet;
`performing deep packet inspection (DPI) to identify
`an application associated with the active flow by analyzing
`at least one other packet;
`determining a classification for the packet based on
`characteristics of the identified application;
`associating, with the packet inserting information
`identifying the classification into the packet;
`forwarding the packet, including the information
`identifying the classification, towards the destination
`node; and performing such that a downstream device is
`enabled to perform processing of the packet by extracting
`the classification from the packet.
`
`
`Ex. 1001, cl. 1.
`
`
`VII. CLAIM CONSTRUCTION
`39.
`In my opinion, a POSITA would have understood all of the terms in
`
`the challenged claims consistent with their plain and ordinary meaning.
`
`VIII. GROUNDS FOR CHALLENGE
`A. Overview of Prior Art
`40. The basic ideas claimed in the patent were well known in the art. By
`
`the time of the patent, there was nothing new about a network device performing
`
`DPI to identify an application and classifying packets based on characteristics of
`
`that application. Likewise there also was nothing new about identifying an
`
`application “by analyzing at least one other packet.”
`
`
`
`18
`
`

`

`41. The technique of “analyzing at least one other packet” was in fact
`
`common in so-called stateful firewalls. In his textbook titled “Inside Network
`
`Perimeter Security,” Northcutt says the following about stateful firewalls:
`
`“The stateful firewall spends most of its cycles examining
`packet information in Layer 4 (transport) and lower.
`However, it also offers more advanced inspection
`capabilities by targeting vital packets for Layer 7
`(application) examination, such as the packet that
`initializes a connection. If the inspected packet matches
`an existing firewall rule that permits it, the packet