UNITED STATES PATENT AND TRADEMARK OFFICE
`
`PATENT:
`
`8,165,024
`
`INVENTORS: Andrew Dolganow
`Keith Allen
`Colin Leon Kahn
`
`FILED:
`
`ISSUED:
`
`TITLE:
`
`April 3, 2008
`
`April 24, 2012
`
`USE OF DPI TO EXTRACT AND FORWARD
`APPLICATION CHARACTERISTICS
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`Microsoft Corp.
`Petitioner
`v.
`Proven Networks, LLC
`Patent Owner
`
`Case IPR 2021-00887
`
`PETITION FOR INTER PARTES REVIEW OF
`U.S. PATENT NO. 8,165,024
`CHALLENGING CLAIMS 1-4, 7-19, AND 22-25
`
`

`

`U.S. Patent No. 8,165,024
`IPR2021-00887
`
`TABLE OF CONTENTS
`INTRODUCTION ........................................................................................... 1
`I.
`II. MANDATORY NOTICES ............................................................................. 2
`A.
`Real Party-in-Interest ............................................................................ 2
`B.
`Related Matters ...................................................................................... 2
`C.
`Counsel .................................................................................................. 3
`III. CERTIFICATION OF GROUNDS FOR STANDING .................................. 4
`IV. OVERVIEW OF CHALLENGE AND RELIEF REQUESTED .................... 4
`A.
`Prior Art Patents and Printed Publications ............................................ 5
`B.
`Relief Requested .................................................................................... 5
`C.
`Discretionary Denial is Not Appropriate .............................................. 5
`LEVEL OF ORDINARY SKILL IN THE ART ............................................. 8
`V.
`VI. OVERVIEW OF THE ’024 PATENT ............................................................ 8
`A.
`The Purported Invention of the ’024 Patent .......................................... 8
`B.
`Relevant Prosecution History .............................................................. 14
`VII. CLAIM CONSTRUCTION .......................................................................... 16
`VIII. GROUNDS FOR CHALLENGE .................................................................. 18
`A.
`Overview of Prior Art.......................................................................... 19
`B.
`Ground I: Claims 1-4, 7-19, and 22-25 are anticipated by
`Packeteer ’406 ..................................................................................... 23
`1.
`Packeteer ’406 ............................................................................ 23
`2.
`Claim 1 ....................................................................................... 32
`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. ......................................................................................... 54
`Claim 3: The method of claim 1, further comprising:
`formatting the packet according to a proprietary protocol;
`
`4.
`
`i
`
`

`

`6.
`
`7.
`
`5.
`
`U.S. Patent No. 8,165,024
`IPR2021-00887
`and placing the information identifying the classification in a
`proprietary protocol extension of the packet. ............................. 55
`Claim 4: The method of claim 1, wherein the packet is a
`Generic Routing Encapsulation (GRE) packet. ......................... 56
`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. ................................................................. 56
`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. ............................................................... 57
`Claim 9: The method of claim 8, wherein the traffic
`management function further comprises: dropping the
`packet. ......................................................................................... 58
`Claim 10: The method of claim 8, wherein the traffic
`management function further comprises: modifying a quality
`of service associated with the packet. ........................................ 59
`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. ................................................................................. 60
`11. Claim 12: the method of claim 1, wherein the at least one
`other packet belongs to the active flow. ..................................... 60
`12. Claim 13: The method of claim 1, wherein the at least one
`other packet belongs to a flow other than the active flow. ........ 61
`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. ...................................................................................... 61
`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,
`
`8.
`
`9.
`
`ii
`
`

`

`U.S. Patent No. 8,165,024
`IPR2021-00887
`pattern matching, stateful monitoring, behavioral analysis,
`and statistical analysis. ............................................................... 63
`15. Claim 16 ..................................................................................... 63
`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. ........................... 65
`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. ............................. 65
`18. Claim 19: The device of claim 16, wherein the packet is a
`Generic Routing Encapsulation (GRE) packet. ......................... 66
`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. ......... 66
`20. Claim 23: The device of claim 16, wherein the downstream
`device performs a traffic management function on the
`packet. ......................................................................................... 66
`21. Claim 24: The device of claim 16, wherein the at least one
`other packet belongs to the active flow. ..................................... 66
`22. Claim 25: The device of claim 16, wherein the at least one
`other packet belongs to a flow other than the active flow. ........ 66
`Ground III: Claims 7, 11, and 22 are obvious over Packeteer ’406
`in view of NBAR ................................................................................. 67
`1.
`Overview of NBAR .................................................................... 67
`2.
`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 .................................................................. 67
`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. ................................................................................. 71
`iii
`
`3.
`
`C.
`
`

`

`4.
`
`U.S. Patent No. 8,165,024
`IPR2021-00887
`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
`IX. CONCLUSION .............................................................................................. 74
`
`iv
`
`

`

`U.S. Patent No. 8,165,024
`IPR2021-00887
`Petitioner Microsoft Corp. (“Microsoft” or “Petitioner”) respectfully
`
`requests Inter Partes Review of claims 1-4, 7-19, and 22-25 of U.S. Patent No.
`
`8,165,024 (“’024 patent”) (Ex. 1001) pursuant to 35 U.S.C. §§ 311-19 and 37
`
`C.F.R. § 42.1 et seq. This Petition is a substantively identical “copy” of IPR2021-
`
`00194 by VMWare, Inc. and Dell Technologies Inc. (“Dell IPR”), and is filed
`
`concurrently with a motion for joinder. This petition differs only in that it
`
`addresses, without relying on any additional references, certain district court claim
`
`constructions promulgated after the Dell IPR was filed, and non-substantive
`
`modifications to meet word count and address discretionary denial issues.
`
`I.
`
`INTRODUCTION
`The ’024 patent concerns a method for classifying network packets using
`
`deep packet inspection (“DPI”) and modifying the packets to convey classification
`
`information to downstream devices that receive the packets. See Ex. 1001, Title,
`
`Abstract. To address perceived shortcomings with the then-admitted state of the
`
`art, the ’024 applicants (“Applicants”) proposed using a network device to (1) use
`
`DPI to identify an application associated with a flow of data packets passing
`
`through the network, (2) classify a packet based on characteristics of the
`
`application, and (3) insert that classification information into the packet so that
`
`another, downstream device receiving the packet could use the classification
`
`1
`
`

`

`U.S. Patent No. 8,165,024
`IPR2021-00887
`information to process the packet without having to perform DPI itself. See, e.g.,
`
`Ex. 1001, 1:12-2:37.
`
`These ideas were not new. Industry pioneer Packeteer had already described
`
`the same DPI-based techniques, in more detail and sophistication than the ’024
`
`patent, in U.S. Patent No. 7,742,406 (“Packeteer ’406”). Similarly, Cisco disclosed
`
`a Network Based Application Recognition engine (“NBAR”) that, like the ’024
`
`patent, used DPI-based techniques to classify application packets within flows
`
`through a network.
`
`Petitioner accordingly requests that the Board find the challenged ’024
`
`claims unpatentable.
`
`II. MANDATORY NOTICES
`A.
`Real Party-in-Interest
`Petitioner Microsoft Corp. (“Microsoft” or “Petitioner”) is the real party-in-
`
`interest.
`
`Related Matters
`B.
`Proven Networks, LLC (the “Patent Owner”) is the owner of the ’024 patent.
`
`Proven Networks has asserted the ’024 patent against Microsoft in Proven
`
`Networks, LLC v. Microsoft Corporation, 6-21-cv-00022 (W.D. Tex. Jan. 11,
`
`2021). Patent Owner has also asserted the ’024 patent in: Proven Networks, LLC v.
`
`Palo Alto Networks, Inc., 6-21-cv-00369 (W.D. Tex.); Proven Networks, LLC v.
`
`2
`
`

`

`U.S. Patent No. 8,165,024
`IPR2021-00887
`Barracuda Networks, Inc., 3-21-cv-02185 (N.D. Cal.); Proven Networks, LLC v.
`
`Juniper Networks, Inc., 6-21-cv-00305 (W.D. Tex.); Proven Networks, LLC v.
`
`Broadcom Incorporated, 6-21-cv-00003 (W.D. Tex.); Proven Networks, LLC v.
`
`Cisco Systems, Inc., 6-20-cv-00983 (W.D. Tex.); Proven Networks, LLC v. Hewlett
`
`Packard Enterprise Company et al, 6-20-cv-00632 (W.D. Tex.); Proven Networks,
`
`LLC v. Solarwinds Corp., 1-20-cv-01221 (W.D. Tex.); Proven Networks, LLC v.
`
`Arista Networks, Inc., 6-20-cv-00281 (W.D. Tex.); Proven Networks, LLC v. Dell
`
`Technologies, Inc. et al, 6-20-cv-00976 (W.D. Tex.); Proven Networks, LLC v. F5
`
`Networks, Inc., 5-20-cv-02521 (N.D. Cal.). The ’024 patent is also the subject of
`
`SonicWall Inc. v. Proven Networks, LLC, 6:20-cv-00977-ADA (W.D. Tex.), in
`
`which SonicWall Inc. is seeking declaratory judgments of noninfringement and
`
`invalidity.1
`
`C.
`
`Counsel
`
`Lead Counsel
`James M. Heintz (Reg. No. 41,828)
`Email: jim.heintz@dlapiper.com
`
`Back-Up Counsel
`Robert C. Williams (pro hac vice to
`be requested)
`
`1 Many of the listed cases have been consolidated for pre-trial in the Western
`
`District of Texas as In re Proven Networks Patent Litigation, Case No. 6:20-mc-
`
`02959-ADA. Petitioner Microsoft’s case, however, has not been consolidated in
`
`6:20-mc-02959-ADA.
`
`3
`
`

`

`Lead Counsel
`11911 Freedom Dr., Suite 300
`Reston VA 20190
`Phone: 703.773.4148
`Fax: 703.773.5000
`
`U.S. Patent No. 8,165,024
`IPR2021-00887
`Back-Up Counsel
`Email: robert.williams@dlapiper.com
`401 B Street, Suite 1700
`San Diego, CA 92101
`Phone: 619.699.2820
`Fax: 619.699.2701
`
`Nandan R. Padmanabhan (pro hac
`vice to be requested)
`Email:
`nandan.padmanabhan@dlapiper.com
`2000 Avenue of the Stars, Suite 400
`North Tower
`Los Angeles, CA 90067
`Phone: 310.595.3082
`Fax: 310.595.3482
`
`Please address all correspondence to lead counsel and back-up counsel at the
`
`addresses shown above. Microsoft also consents to electronic service by email at
`
`the email addresses above and at DLA-MicroIPR-Proven@us.dlapiper.com.
`
`III. CERTIFICATION OF GROUNDS FOR STANDING
`Petitioner certifies pursuant to Rule 42.104(a) that the ʼ024 patent is
`
`available for IPR and that Petitioner is not barred or estopped from requesting an
`
`IPR challenging the patent claims on the grounds identified herein.
`
`IV. OVERVIEW OF CHALLENGE AND RELIEF REQUESTED
`Pursuant to Rules 42.22(a)(1) and 42.104(b)(1)-(2), Petitioner challenges
`
`claims 1-4, 7-19, and 22-25 of the ’024 patent (“challenged claims”) and requests
`
`that each be canceled.
`
`4
`
`

`

`Prior Art Patents and Printed Publications
`A.
`Petitioner relies upon the following patents and printed publications:
`
`U.S. Patent No. 8,165,024
`IPR2021-00887
`
`1.
`
`U.S. Patent No. 7,742,406 to Muppala et al., filed by Packeteer, Inc.
`
`(“Packeteer ’406”) (Ex. 1005).
`
`2.
`
`Classifying Network Traffic Using NBAR by Cisco Systems, Inc.
`
`(“NBAR”) (Ex. 1008).
`
`Relief Requested
`B.
`Petitioner requests that the Board cancel the challenged claims because they
`
`are unpatentable under 35 U.S.C. §§ 102 and/or 103.
`
`Discretionary Denial is Not Appropriate
`C.
`The Board should not deny institution due to the pendency of Proven
`
`Networks’ district-court case against Microsoft.
`
`The Board has provided six factors to weigh when considering discretionary
`
`denial:
`
`1. whether the court granted a stay or evidence exists that one may be
`
`granted if a proceeding is instituted;
`
`2. proximity of the court’s trial date to the Board’s projected statutory
`
`deadline for a final written decision;
`
`3. investment in the parallel proceeding by the court and the parties;
`
`5
`
`

`

`U.S. Patent No. 8,165,024
`IPR2021-00887
`4. overlap between issues raised in the petition and in the parallel
`
`proceeding;
`
`5. whether petitioner and defendant in the parallel proceeding are the
`
`same party; and
`
`6. other circumstances that impact the Board’s exercise of discretion,
`
`including the merits.
`
`Apple v. Fintiv, Inc., IPR2020-00019, Paper 11, 6-16 (P.T.A.B. Mar. 20,
`
`2020) (precedential). These factors favor institution.
`
`Factor 1 is neutral. The PTAB has declined to speculate on the likelihood of
`
`Judge Albright entering a stay after institution and has found this factor neutral.
`
`See Western Digital Corp. et al. v. Kuster, IPR2020-01391, Paper 10 at 9 (PTAB
`
`Feb. 16, 2021)); Globalfoundries Inc. v. UNM Rainforest Innovations, IPR2020-
`
`00984, Paper 11 at 10-11 (PTAB Dec. 9, 2020). Furthermore, the district court
`
`litigation is in its infancy and the PTAB will likely resolve this petition before a
`
`trial takes place against Microsoft in Texas.
`
`Factors 2 and 3 strongly support institution because the district court case
`
`remains in its infancy; the initial case scheduling conference has yet to occur, and
`
`no Markman hearing date or trial date are set. Petitioner has not engaged in any
`
`discovery nor served invalidity contentions.
`
`6
`
`

`

`U.S. Patent No. 8,165,024
`IPR2021-00887
`Factor 4 strongly favors institution. Microsoft stipulates that, if the Board
`
`institutes this IPR, Microsoft will not pursue in the district court litigation any
`
`ground raised or that could have been reasonably raised in this IPR. This will
`
`mitigate any concerns about duplicative efforts. See Sotera Wireless, Inc. v.
`
`Masimo Corp., IPR2020-01019, Paper 12, 18-19 (Dec. 1, 2020) (precedential as to
`
`§ II.A). Thus, the district court will not have to resolve invalidity challenges to the
`
`challenged claims for any ground Petitioner raised or reasonably could have raised
`
`in the IPR.
`
`Factor 5 supports institution because Petitioner is a party in only one of the
`
`eleven currently co-pending litigations, and is not related to any party in the ten
`
`other co-pending litigations. The other cases should not be considered in the
`
`analysis because it is Patent Owner that decided to file serial cases and delay in
`
`suing Microsoft. Patent Owner should not be able to avoid review of its patents by
`
`choosing to delay suing Microsoft.
`
`Factor 6 strongly favors institution because the grounds herein provide a
`
`strong showing of obviousness. “[I]f the merits of a ground raised in the petition
`
`seem particularly strong on the preliminary record, this fact has favored
`
`institution.” Fintiv, IPR2020-00019, Paper 11, 14-15.
`
`Because the Fintiv factors support institution, discretionary denial is not
`
`appropriate.
`
`7
`
`

`

`V.
`
`LEVEL OF ORDINARY SKILL IN THE ART
`A person of ordinary skill in the art (“POSITA”) at the time of the alleged
`
`U.S. Patent No. 8,165,024
`IPR2021-00887
`
`invention of the ’024 patent would have had at least the equivalent of a Bachelor’s
`
`degree in computer engineering 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. See Ex. 1003, ¶¶ 17-18.
`
`VI. OVERVIEW OF THE ’024 PATENT
`A.
`The Purported Invention of the ’024 Patent
`The ’024 patent is directed to using DPI2 to classify packets based on
`
`characteristics of an application associated with the packets. See Ex. 1001, Title.
`
`The ’024 background section acknowledges that, by the time of the ’024
`
`patent, mobile network operators utilized packet marking to prioritize and forward
`
`packets. For example, voice packets could be marked as higher priority than data
`
`packets to improve the quality of calls placed over a mobile network. Id., 1:49-57.
`
`According to the patent, however, these prior approaches purportedly relied
`
`on end-user equipment to do the packet marking, reducing the flexibility of
`
`2 Generally, DPI concerns inspecting a packet to learn information about the packet
`
`other than its source and destination. Ex. 1003, ¶¶ 20-23.
`
`8
`
`

`

`U.S. Patent No. 8,165,024
`IPR2021-00887
`operators to define new applications and markings. Id., 1:58-66. The applicants
`
`further claimed that 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.
`
`The applicants contended that a device was needed that would operate in the
`
`network to identify characteristics of the applications generating the packets and to
`
`convey that information to downstream components:
`
`[T]here 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.
`
`9
`
`

`

`U.S. Patent No. 8,165,024
`IPR2021-00887
`
`Id., 2:11-21.3
`
`Accordingly, the ’024 applicants 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.
`
`Ex. 1001, Fig.1.
`
`The applicants further proposed a purportedly improved method for
`
`performing DPI using this device. 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, e.g., 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
`
`3 All emphasis added unless noted otherwise.
`
`10
`
`

`

`U.S. Patent No. 8,165,024
`IPR2021-00887
`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. See 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 []
`
`whether the flow relates to email, streaming video, web browsing, peer-to-peer
`
`transfer, Voice over IP (VoIP), or any other application of interest to the service
`
`provider”).
`
`11
`
`

`

`U.S. Patent No. 8,165,024
`IPR2021-00887
`
`Ex. 1001, Fig. 6.
`
`Once the application is identified, the DPI device further classifies the
`
`packet (640) based on some underlying characteristic of the application. This
`
`application characteristic is broad. It may be, for example, a “compression
`
`scheme” or “data structure” (id., 5:31-35; see also id., 6:47-50), or a “frame[]
`
`type[] used for an encoding scheme” (id., 7:50-54). Or it may be based on the
`
`“importance of the packet to the user experience” or “the needs of the application.”
`
`12
`
`

`

`U.S. Patent No. 8,165,024
`IPR2021-00887
`Id., 8:64-67. Indeed, the patent explains that the further classification can be of
`
`“any characteristic of the underlying application.” Id., 8:6-9; see also 8:66-67
`
`(“some other criterion”), 5:34-35 (“any other application characteristic”).
`
`Once the packet is so-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.
`
`The so-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.” Id., 9:45-50.
`
`As filed, claim 1 recited a method directed to performing DPI to identify an
`
`application and classifying packets based on characteristics of that application:
`
`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;
`
`13
`
`

`

`U.S. Patent No. 8,165,024
`IPR2021-00887
`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, information identifying the
`
`classification;
`
`forwarding the packet including the information identifying the
`
`classification towards the destination node; and
`
`performing processing on the packet at a downstream device by
`
`extracting the classification from the packet.
`
`Ex. 1002, at 25.
`
`Relevant Prosecution History
`B.
`The ’024 patent application was filed on April 3, 2008. At no point did
`
`applicants submit any prior art.
`
`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 Ex. 1002, at 56 (Non-Final Rejection, 5/12/10). The applicants did not
`
`dispute those findings and instead amended the claims to specifically require
`
`14
`
`

`

`U.S. Patent No. 8,165,024
`IPR2021-00887
`inserting the classification information into the packets before forwarding them.
`
`See id., at 72 (Amendment, 6/11/10).
`
`The examiner again rejected the so-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, 6/7/11). The applicants also did not
`
`dispute those findings and instead amended the claims to further require that the
`
`DPI step identify an application “by analyzing at least one other packet.” See id.,
`
`at 221 (Amendment, 8/4/11).
`
`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, 12/21/11).
`
`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:
`
`15
`
`

`

`U.S. Patent No. 8,165,024
`IPR2021-00887
`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
`Petitioner does not believe claim construction is necessary in this
`
`proceeding. Only claim terms “in controversy” need be construed in an IPR “and
`
`only to the extent necessary to resolve the controversy.” Nidec Motor Corp. v.
`16
`
`

`

`U.S. Patent No. 8,165,024
`IPR2021-00887
`Zhongshan Broad Ocean Motor Co., 868 F.3d 1013, 1017 (Fed. Cir. 2017).
`
`Because the prior art asserted herein discloses the preferred embodiment within the
`
`indisputable scope of the claims, the Board need not construe the outer bounds of
`
`the claims as part of these proceedings. See, e.g., 83 Fed. Reg. 51340 at 47-48, 55,
`
`65-71.
`
`Certain claim terms were construed in the Proven Networks, LLC v.
`
`Amazon.com, Inc. et al., 6-20-mc-02959 (W.D. Tex.) district court litigation (to
`
`which Microsoft is not a party). Judge Albright issued the following construction:
`
`Exhibit 1023 at 3. The Amazon parties also agreed that the term “analyzing at least
`
`one other packet” in claims 1 and 16 means “analyzing at least one packet other
`
`than the packet.” Exhibit 1024 at 2.
`
`17
`
`

`

`U.S. Patent No. 8,165,024
`IPR2021-00887
`Although Petitioner does not believe claim construction is necessary for this
`
`proceeding, to the extent the Board adopts the constructions from the Amazon
`
`litigation (which it need not do), the invalidity analyses set forth herein remain the
`
`same. 4
`
`VIII. GROUNDS FOR CHALLENGE
`This Petition, supported by the Declaration of Dr. Riccardo Bettati filed
`
`herewith as Exhibit 1003, demonstrates that there is a reasonable likelihood that
`
`Petitioner will prevail with respect to at least one challenged claim and that each of
`
`the challenged claims is not patentable. See 35 U.S.C. §314(a).
`
`Dr. Bettati is a professor of Computer Science and & Engineering at Texas
`
`A&M University. Dr. Bettati earned his Ph.D. in Computer Science in 1994 from
`
`the University of Illinois Urbana-Champaign. He has published numerous
`
`academic papers on various subjects, including network-level support for
`
`distributed applications such as distributed multimedia and secure computation,
`
`early forms of DPI, and technologies that can be integrated into DPI – such as DPI
`
`counter-measures for secure, encrypted communication. See Ex. 1003, ¶ 4.
`
`4 Petitioner does not contend that the constructions adopted in the Amazon
`
`litigation are complete constructions of these limitations or the claims for any other
`
`purpose, including for any issues raised in the related litigation.
`
`18
`
`

`

`Overview of Prior Art
`A.
`The basic ideas claimed in the ’024 patent were well known in the art. Just
`
`U.S. Patent No. 8,165,024
`IPR2021-00887
`
`as there was nothing new about a network device performing DPI to identify an
`
`application and classifying packets based on characteristics of that application,
`
`there also was nothing new about identifying an application “by analyzing at least
`
`one other packet.”
`
`As a general matter, using DPI to learn something about a packet (other than
`
`its source or destination) dates back decades. As Dr. Bettati explains, the concept
`
`of DPI – whether or not the term “DPI” was used – extends to at least the early
`
`1990s. As the term suggests, DPI techniques were used to extract information from
`
`layers of a packet deeper than its outermost header. For example, DPI techniques
`
`could parse a packet to examine higher level headers and/or payload to identify
`
`information about the packet that could be used in managing network traffic. Using
`
`information obtained from multiple packets in the same flow was also known. This
`
`was often called “stateful” inspection, because the system had to store the
`
`information extracted from previous packets (i.e., the “state”) so that it could be
`
`used in conjunction with information extracted from later packets. See Ex. 1003, ¶¶
`
`40-46.
`
`19
`
`

`

`U.S. Patent No. 8,165,024
`IPR2021-00887
`Using DPI to classify a packet with characteristic information about an
`
`application is likewise old. For example, Cisco’s NBAR5 (Ex. 1008) disclosed a
`
`system that, like the ’024 patent, “recognize[d] and classifie[d] a wide variety of
`
`protocols and applications.” See Ex. 1008, at 1. NBAR, like the ’024 patent, also
`
`operated in a network-based device (e.g., a router) and classified packets moving
`
`through a network from a source to a destination. See id., at 2. In NBAR,
`
`classification was “based on deep packet inspection” of “content within the
`
`payload such as that transaction identifier, message type, or other similar data.” See
`
`id., at 4, 5; see also Szigeti, Ex. 1009, at 74 (“NBAR examines the packet payload
`
`itself and classifies packets on the payload content, such as transaction identifiers,
`
`message types, or other similar data”). See Ex. 1003, ¶ 46.
`
`For example, NBAR’s DPI could further classify Citrix Independent
`
`Computing Architecture (ICA) traffic based on whether it was high, medium, low,
`
`and background priorities (e.g., printing traffic could be classified as low priority
`
`traffic, whereas updates to the user’s display could be classified as higher priority
`
`traffic). See Ex. 1008, at 9. NBAR’s packet inspection and classification was
`
`5 “NBAR” is an acronym for “network-based application recognition,” conveying
`
`that a primary focus of NBAR was to recognize an application associated with
`
`packets it was inspecting. See Ex. 1008, at 1.
`
`20
`
`

`

`U.S. Patent No. 8,165