UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`Juniper Networks, Inc. & Palo Alto Networks, Inc.
`Petitioners,
`
`v.
`
`Packet Intelligence LLC,
`Patent Owner.
`
`Regarding Inter Partes Review of:
`U.S. Patent Nos. 6,665,725 (IPR2020-00336); 6,771,646 (IPR2020-00337);
`6,839,751 (IPR2020-00338); and 6,954,789 (IPR2020-00339, -00486)
`
`DECLARATION OF CATHLEEN T. QUIGLEY
`
`Packet Intelligence LLC Exh 2061
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 1 of 54
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`Juniper Networks, Inc. & Palo Alto Networks, Inc.
`Petitioners,
`
`v.
`
`Packet Intelligence LLC,
`Patent Owner.
`
`Regarding Inter Partes Review of:
`U.S. Patent Nos. 6,665,725 (IPR2020-00336); 6,771,646 (IPR2020-00337);
`6,839,751 (IPR2020-00338); and 6,954,789 (IPR2020-00339, -00486)
`
`DECLARATION OF CATHLEEN T. QUIGLEY
`
`Packet Intelligence LLC Exh 2061
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 1 of 54
`
`
`
`I, Cathleen T. Quigley, make the following declaration pursuant to 28 U.S.C. §1746:
`
`1. My name is Cathleen T. Quigley. I am over the age of twenty-one years, of
`
`sound mind, and capable of making the statements set forth in this Declaration. I am
`
`competent to testify about the matters set forth herein. All the facts and statements
`
`contained herein are within my personal knowledge and/or within my field of
`
`expertise, and they are true and correct to the best of my knowledge.
`
`2.
`
`I have been asked by Heim, Payne & Chorush, LLP to form and offer opinions
`
`regarding validity of U.S. Patent Nos. 6,665,725 (the “’725 Patent”); 6,771,646 (the
`
`“’646 Patent”); 6,839,751 (the “’751 Patent”); and 6,954,789 (the “’789 Patent”)
`
`(collectively the “Challenged Patents”).1 This Declaration contains a summary of
`
`and the supporting explanations for my opinions concerning the validity of the
`
`Challenged Patents.
`
`3.
`
`I have been advised that Heim, Payne & Chorush, LLP represents Packet
`
`Intelligence LLC (“PI”), the owner of the Challenged Patents, and that Juniper
`
`Networks, Inc. & Palo Alto Networks, Inc. (the “Petitioners”) have challenged the
`
`validity of the Challenged Patents. I have no personal or financial stake or interest
`
`in PI, the Petitioners, or the Challenged Patents.
`
`
`
`1 I also refer to U.S. Patent No. 6,651,099 (the “’099 Patent”) during my analysis,
`
`which I understand is incorporated by reference by each of the Challenged Patents.
`
`2
`
`Packet Intelligence LLC Exh 2061
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 2 of 54
`
`
`
`I. Education and Experience
`
`4. A Curriculum Vitae of my educational background and professional
`
`experience is attached as Exhibit 2062. I provide a summary of certain experience
`
`that I have relevant to the technical field of the Challenged Patents.
`
`5.
`
`I earned a Bachelor’s degree in Electrical Engineering from the Georgia
`
`Institute of Technology in 1984. I was inducted into the Institute’s Council of
`
`Outstanding Young Engineering Alumni in 2001, and its Academy of Distinguished
`
`Engineering Alumni in 2014.
`
`6.
`
`I am currently working as an independent consultant for Swiftwater
`
`Consulting, LLC in the field of data communications, semiconductors, and cable
`
`system architecture. My work includes lower level networking protocols such as
`
`Ethernet, Bluetooth, Wifi, and MoCA as well as higher level IP protocol related
`
`topics. I also perform work related to the Data Over Cable Service Interface
`
`Specification (DOCSIS) and mobile video, communications, and mesh computing.
`
`I began working in this consultant role in 2009.
`
`7. Prior to consulting, I worked at Broadcom Corporation in Irvine, California
`
`from 1996 to 2008. I joined Broadcom in 1996 as Director of the Residential
`
`Broadband Group, where I directed the residential broadband efforts. My work
`
`involved extensive development of cable modem (CM) technologies, as well as
`
`cable modem termination systems (CMTS) technologies. I spearheaded the efforts
`
`3
`
`Packet Intelligence LLC Exh 2061
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 3 of 54
`
`
`
`to take Broadcom’s residential broadband products from infancy to its position as an
`
`industry leader in the cable modem space.
`
`8. From 2001 to 2008, I was a Broadcom Fellow and Senior Director for
`
`Advanced Broadband Architectures in the Office of the Chief Technical Officer
`
`(CTO). I was the architect of Broadcom’s broadband strategy and product
`
`definitions, including DOCSIS 2.0, 3.0, streaming video, and DOCSIS voice
`
`products. I was a key contributor and industry speaker on DOCSIS 3.0 issues and
`
`solutions and often travelled and spoke extensively worldwide building industry
`
`consensus. I continue to give talks and presentations regarding technology
`
`developments in the cable industry to this day.
`
`9.
`
`I played a major role in the design and development of the world’s first
`
`Multimedia Cable Network System Partners (MCNS)/DOCSIS cable modem and
`
`headend integrated circuits and reference system designs. I also led the efforts
`
`developing other state-of-the-art analog/digital full custom CMOS integrated
`
`circuits including MAC, PHY, CPU, and peripherals for integrated system-on-chip
`
`products. My contributions included several technologies implemented in
`
`Broadcom’s products, including key developments in the Quality of Service (“QoS”)
`
`extensions to DOCSIS 1.1 and 2.0 such as transparent packet fragmentation and
`
`4
`
`Packet Intelligence LLC Exh 2061
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 4 of 54
`
`
`
`concatenation at the MAC layer.2 These efforts resulted in multiple patents for me
`
`and my team.
`
`10. DOCSIS 1.1 was released in March of 1999. A key architectural feature I
`
`drove in the creation of the DOCSIS 1.1 QoS feature set was the use of a Service
`
`Flow and ID associated with individual IP flows to and from a modem. These
`
`Service Flow IDs could be used to assign a different QoS level to flows for specific
`
`protocols (such as HTTP sessions, SMTP, and FTP). The relevant Service ID for a
`
`protocol was identified based on inspection of IPv4 and IPv6 header fields and
`
`Ethernet LLC header fields. This was particularly useful for bandwidth allocation,
`
`management, tiering, and other QoS mechanisms, and it allowed for dynamic QoS
`
`adjustments as traffic ebbed and flowed.
`
`11. In developing the QoS and fragmentation/concatenation mechanisms for
`
`DOCSIS 1.1, I led a team performing detailed protocol analysis and simulation using
`
`OPNET. We built MAC layer models of the baseline protocol and proposed
`
`extensions, developed detailed scenarios of traffic patterns and usage models, and
`
`evaluated the different options in simulation. Statistical analysis of the performance
`
`of these extensions were included in multiple papers and presentations to the
`
`
`
`2 U.S. Patent No. 7,103,065 Data Packet Fragmentation in a Cable Modem System.
`
`5
`
`Packet Intelligence LLC Exh 2061
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 5 of 54
`
`
`
`industry. I was inducted into the Cable TV Pioneer class of 2019 by my peers in the
`
`SCTE for contributions to the DOCSIS standard.
`
`12. I was the architect of Broadcom’s chipset for implementing the Cable Modem
`
`Termination System (CMTS) at the headend. The CMTS is the gateway between
`
`the Wide Area Network (WAN) and cable modems via the Hybrid Fiber Coax (HFC)
`
`plant. CMTS devices are fast packet switching machines that are implemented as a
`
`bridge or a router. Packets are forwarded to the appropriate downstream modulator
`
`or bonded group of modulators according to the QoS level. The CMTS contains a
`
`scheduler that processes requests for upstream bandwidth from the many thousands
`
`of cable modems it services and allocates bandwidth over dozens of groups of
`
`bonded upstream channels. The bandwidth allocation messages are transmitted
`
`downstream to all the modems and effectively schedule all upstream packet
`
`forwarding. Some implementations of the chipsets support up to 64,000 cable
`
`modems and forward 10 million packets per second per CMTS scheduling unit.
`
`13. Some of my other key contributions at Broadcom included: (1) architect of
`
`Broadcom’s cable modem and headend products, (2) Broadcom representative for
`
`vendor-author of the MCNS and DOCSIS 1.0, 1.1, and Baseline Privacy
`
`specifications, (3) chairing the MAC and PHY Working Group of the SCTE Data
`
`Standard sub-committee, and (4) presenting at IEEE 802.14. I worked in this role
`
`until 2001 when I transitioned into the office of the Chief Technical Officer. I was
`
`6
`
`Packet Intelligence LLC Exh 2061
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 6 of 54
`
`
`
`named a Distinguished Engineer in 2000 and a Broadcom Fellow in 2005, the
`
`highest technical honor Broadcom bestows, as the first non-PhD recipient.
`
`14. My career started at Digital Communications Associates (DCA) in Alpharetta,
`
`Georgia, designing network protocol emulators in 1983. My first project was
`
`designing and implementing the hardware, microcode, and software for a network
`
`protocol analyzer for the IBM 5250 System 34/36/38 mini-computer network. I then
`
`used the analyzer to reverse engineer the protocol and build a protocol emulator add-
`
`in card for the IBM PC and a stand-alone printer emulator product line called
`
`SmartAlec with a small team of engineers. I also applied similar techniques to the
`
`IBM 3270 network analysis needs of the team and the IRMA product line of
`
`emulators and add-in cards. My involvement was building the hardware, designing
`
`and implementing FPGAs, writing microcode to process high speed data packets,
`
`and writing C language software to parse, analyze, trace, and display the semantics
`
`of the protocol exchanges. I then was involved building the add-in card hardware,
`
`standalone computer hardware and ASICs to implement the protocol emulator and
`
`wrote assembler drivers to facilitate higher level software access.
`
`15. During the development process of the Smart Alec product line, I created a
`
`portable protocol analyzer for the IBM 5250 network protocol and traveled to
`
`multiple sites around the country capturing trace data of the protocol functioning
`
`with different peripherals and in different use scenarios. I refined the protocol
`
`7
`
`Packet Intelligence LLC Exh 2061
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 7 of 54
`
`
`
`analyzer software and the hardware parsing and filtering mechanisms based on these
`
`experiential data. When the team believed we had a complete model of the protocol
`
`operation from my analysis using the tool, we finalized the hardware implementation
`
`of a custom MAC chip to implement it. This custom transceiver IC did real-time
`
`acquisition, framing, parsing, filtering, and analysis of the 5250 serial protocol
`
`stream and presented the appropriate packets to the higher layers of the protocol to
`
`process.
`
`16. In 1987 I was recruited by National Semiconductor. At National, I was asked
`
`to bring my protocol emulation and analysis skills and techniques to bear on the
`
`Biphase Communications Processer,
`
`the BCP8344
`
`family of CMOS
`
`communications integrated circuits. I wrote extensive application notes on 3270 and
`
`5250 terminal protocol emulation, wrote software and firmware to implement
`
`working multi-protocol emulators, and drove the simulation of the hardware and
`
`software system around the integrated circuit to verify functionality.
`
`17. Next at National I joined the Ethernet group and worked on the DP8390 802.3
`
`ethernet chip set, including designing the PCMCIA version. I then led a team
`
`designing a 10/100BaseX Ethernet MAC/PHY PCI bus chip and software drivers
`
`and oversaw the development of the first 10/100BaseX repeater, switch, and ISA
`
`silicon and their respective Netware and Windows drivers. I was a voting member
`
`of the IEEE 802.3u working group and contributed sections and presented session
`
`8
`
`Packet Intelligence LLC Exh 2061
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 8 of 54
`
`
`
`papers toward the Media Independent Interface adopted as part of the 802.3u
`
`standard.
`
`18. From 1995 to 1996, I worked as Vice President of Development at Arris
`
`Interactive/ESP in Suwanee, Georgia. There I built a team to develop combined
`
`data, voice, and video over cable products (Total Access) based originally on the
`
`ethernet CSMA/CD protocol.
`
`19. I am a named inventor on 96 U.S. Patents, most of which relate to networking
`
`technologies. I have authored numerous papers and industry standards on the
`
`subjects of DOCSIS, broadband data communications, mesh networking, system
`
`simulation, and related technological developments. I have also contributed to a
`
`textbook in the field entitled “Cable Modems: Current Technologies and
`
`Applications Advances in the Information Industry Series.”3 An abbreviated list of
`
`papers and patents are listed in my Curriculum Vitae.
`
`II. Compensation
`
`20. My firm is being compensated at my standard consulting rate of $400/hr for
`
`my time working on this case and reimbursed for reasonable expenses incurred in
`
`
`
`3 “Cable Modems: Current Technologies and Applications Advances in the
`
`Information Industry Series,” International Engineering Consortium, 1999 (ISBN
`
`0780353951, 9780780353954)
`
`9
`
`Packet Intelligence LLC Exh 2061
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 9 of 54
`
`
`
`providing my services in this case. My compensation is not dependent upon my
`
`testimony or the outcome of the case.
`
`III. Materials Considered
`
`21. In forming the opinions expressed below, I considered the Challenged Patents
`
`and their file histories, including the file histories of patents within the same patent
`
`families, as well as the references and related documentation discussed herein. I also
`
`considered the Petition and the exhibits filed by the Petitioners in these proceedings,
`
`including the art supporting the grounds asserted in the Petition. I have also relied
`
`upon my education, background, and experience.
`
`IV. Summary of Opinions
`
`22. In my opinion, none of the prior art asserted in these proceedings, either alone
`
`or in combination, teaches the claimed conversational flow—a key differentiator
`
`from prior art monitoring systems. For the same reason, the asserted prior art does
`
`not teach the claim limitations related to storing conversational flows, such as a flow-
`
`entry database.
`
`23. Additionally, it is my opinion that the Yu (Ex. 1011) claim which the
`
`Petitioners attempted to support with the Yu Provisional (Exs. 1012, 1048), recites
`
`several limitations containing a generic term (“module”) typically used when
`
`describing parts of a device, system, or architecture in functional terms, and that an
`
`inventor would need to disclose the specific structures that perform the functions
`
`10
`
`Packet Intelligence LLC Exh 2061
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 10 of 54
`
`
`
`related to each generic term to demonstrate to a POSITA that the inventor was in
`
`possession of that invention.
`
`24. Furthermore, it is my opinion that a POSITA would not understand the use of
`
`an associative cache to be obvious based on the art and argument cited by Dr.
`
`Weissman in his declaration.
`
`V. Legal Standards
`
`25. I am not an attorney. I have been advised of the following general principles
`
`of patent law to be used in formulating my opinions presented in this Declaration.
`
`26. I understand that determining whether a patent claim is valid requires a two-
`
`step analysis. First, the claim must be construed. Second, the properly construed
`
`claim must be compared to the prior art.
`
`27. I have been informed and understand that the question of patent validity and
`
`infringement is determined from the perspective of a person having ordinary skill in
`
`the art (“POSITA”). I have been informed and understand that the POSITA is not a
`
`real person, but rather a legal construct—a hypothetical person. This person is
`
`presumed to have known the relevant art at the time of the invention. I have been
`
`informed by counsel that relevant factors in determining the level of ordinary skill
`
`include (1) the educational level of the inventor, (2) the type of problems
`
`encountered in the art, (3) prior art solutions to those problems, (4) the rapidity with
`
`which innovations are made, (5) sophistication of the technology, and (6) the
`
`11
`
`Packet Intelligence LLC Exh 2061
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 11 of 54
`
`
`
`educational level of active workers in the field. I further understand that the person
`
`of “ordinary skill” is not a person of extraordinary skill in the art. In other words,
`
`this person of ordinary skill is not necessarily an expert in the field.
`
`28. I understand that a patent claim is presumed to be valid. I understand that
`
`within inter partes review proceedings, to overcome that presumption, the
`
`challenger must show that the claim is invalid by a preponderance of the evidence. I
`
`understand the preponderance of the evidence requires the greater weight of
`
`evidence in favor of the challenger.
`
`29. I understand that, although not expressly disclosed, subject matter may be
`
`inherently disclosed in a prior art reference where that subject matter is necessarily
`
`present in the subject matter disclosed and would be understood to be so by those of
`
`ordinary skill in the art. I understand that the fact that a certain result or characteristic
`
`may occur or be present in the prior art is not sufficient to establish the inherency of
`
`that result or characteristic.
`
`30. I understand that a claim is invalid if each and every element of the claim is
`
`disclosed in a single prior art reference with the elements arranged as specified in
`
`the claim, either expressly or inherently. I understand that invalidity based on the
`
`disclosure of a single prior art reference in this manner is called anticipation.
`
`31. I understand that a claim would have been obvious under 35 U.S.C. § 103 if,
`
`for example, one or more prior art references disclose, expressly or inherently, every
`
`12
`
`Packet Intelligence LLC Exh 2061
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 12 of 54
`
`
`
`claim limitation in such a way so as to render the claim, as a whole, obvious to a
`
`person of ordinary skill in the art at the time the purported invention was made. The
`
`relevant standard for obviousness is as follows:
`
`A patent may not be obtained though the invention is not identically
`disclosed or described as set forth in section 102, if 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
`to which said subject matter pertains. Patentability shall not be
`negatived by the manner in which the invention was made.
`
`35 U.S.C. § 103 (pre-AIA).
`
`32. In determining whether or not a patented invention would have been obvious,
`
`the following factors should be considered: (a) the scope and content of the prior art;
`
`(b) the differences between the prior art and the claims at issue; (c) the level of
`
`ordinary skill in the art; and (d) whatever “secondary considerations” may be
`
`present.
`
`33. I understand that certain “secondary considerations” may be relevant in
`
`determining whether or not an invention would have been obvious, and that these
`
`secondary considerations may include commercial success of a product using the
`
`invention, if that commercial success is due to the invention; long-felt need for the
`
`invention; evidence of copying of the claimed invention; industry acceptance; initial
`
`skepticism; failure of others; praise of the invention; the taking of licenses under the
`
`13
`
`Packet Intelligence LLC Exh 2061
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 13 of 54
`
`
`
`patents by others; and simultaneous invention by others. I understand that
`
`simultaneous invention by others may be an indication that the claimed invention
`
`was the result of ordinary skill in the art.
`
`34. I understand that a patent composed of several elements is not proved obvious
`
`merely by demonstrating that each of its elements was, independently, known in the
`
`prior art. While multiple prior art references or elements may, in some
`
`circumstances, be combined to render a patent claim obvious, I understand that I
`
`should consider whether there is an apparent reason to combine the prior art
`
`references or elements in the way the patent claims. To determine whether such an
`
`apparent reason exists to combine the prior art references or elements in the way a
`
`patent claims, it will often be necessary to look to the interrelated teaching of
`
`multiple patents, to the effects of demands known to the design community or
`
`present in the marketplace, and to the background knowledge possessed by a person
`
`having ordinary skill in the art.
`
`35. I also understand that when the prior art teaches away from combining prior
`
`art references or certain known elements, discovery of a successful means of
`
`combining them is more likely to be non-obvious. A prior art reference may be said
`
`to teach away from a patent when a person of ordinary skill, upon reading the
`
`reference, would be discouraged from following the path set out in the patent or
`
`would be led in a direction divergent from the path that was taken by the patent.
`
`14
`
`Packet Intelligence LLC Exh 2061
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 14 of 54
`
`
`
`36. I also understand that it is not permissible to use hindsight in assessing
`
`whether a claimed invention is obvious. Rather, I understand that, to assess
`
`obviousness, you must place yourself in the shoes of a person having ordinary skill
`
`in the relevant field of technology at the time the inventions were made who is trying
`
`to address the issues or solve the problems faced by the inventor and ignore the
`
`knowledge you currently now have of the inventions.
`
`37. I also understand that there are numerous ways in which to articulate the legal
`
`standard for obviousness, including: (1) combining prior art elements according to
`
`known methods to yield predictable results, (2) simple substitution of one known
`
`element for another to obtain predictable results, (3) use of a known technique to
`
`improve similar devices (methods, or products) in the same way, (4) applying a
`
`known technique to a known device, method, or product ready for improvement to
`
`yield predictable results, (5) choosing from a finite number of identified, predictable
`
`solutions with a reasonable expectation of success, (6) 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 predictable
`
`to one of ordinary skill in the art, and (7) 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 reference teachings to arrive at the claimed
`
`invention.
`
`15
`
`Packet Intelligence LLC Exh 2061
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 15 of 54
`
`
`
`38. I understand that in order for a patent to claim priority to a prior application,
`
`the prior application must describe the claimed invention in sufficient detail that one
`
`skilled in the art can clearly conclude that the inventor invented the claimed
`
`invention as of the filing date sought. However, it is not necessary to use the exact
`
`same terms in the prior application as the applicant uses in the claims—an equivalent
`
`description in the prior application is sufficient. I understand that the written
`
`description requirement includes an inquiry into whether the specification describes
`
`the claimed invention in sufficient detail that one skilled in the art can reasonably
`
`conclude that the inventor had possession of the claimed invention at the time of
`
`filing.
`
`39. I further understand that if a petitioner claims priority to a provisional
`
`application for an invalidity reference, then that petitioner must (a) demonstrate
`
`support for at least one reference patent claim in the provisional application, and (b)
`
`demonstrate that the portions of the reference relied upon for invalidity are also
`
`supported by the provisional application.
`
`VI. The Person of Ordinary Skill in the Art
`
`40. I understand the Board preliminarily adopted the following description for a
`
`POSITA: “one of ordinary skill in the art at the time of the invention of the
`
`[Challenged Patents] would have ‘had a bachelor’s degree in electrical engineering,
`
`computer engineering, computer science, or a related field (or its equivalent), and
`
`16
`
`Packet Intelligence LLC Exh 2061
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 16 of 54
`
`
`
`one to two years of experience working in networking environments, including at
`
`least some experience with network traffic monitors and/or analyzers.’” IPR2020-
`
`00336 Decision at 27. Based on my own review of the patents and based upon my
`
`knowledge and experience in the relevant fields, I generally agree with the Board’s
`
`conclusion, and have applied that definition in forming my opinions. As discussed
`
`above, my education and professional experience in late 1999 exceeded the standard
`
`for a person of ordinary skill in the art by the date of the earliest filed application for
`
`the patents in question.
`
`VII. The Challenged Patents
`
`A. Overview
`
`41. The patents at issue teach a method for examining packets passing through a
`
`computer network for the purpose of monitoring or managing the network. A key
`
`concept that makes them different from prior art is the idea of conversational flows.
`
`A POSITA reading the specification would observe that the specification defines a
`
`conversational flow as “the sequence of packets that are exchanged in any direction
`
`as a result of an activity—for instance, the running of an application on a server as
`
`requested by a client. It is desirable to be able to identify and classify conversational
`
`flows rather than only connection flows. The reason for this is that some
`
`conversational flows involve more than one connection, and some even involve
`
`more than one exchange of packets between a client and server.” Ex. 1001 at 2:34-
`
`17
`
`Packet Intelligence LLC Exh 2061
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 17 of 54
`
`
`
`49, 5:18-34. I understand that the Patent Trial and Appeals Board construed the term
`
`as “the sequence of packets that are exchanged in any direction as a result of an
`
`activity.” This construction, applied in a manner consistent with the teachings of the
`
`specification, does not change my opinion that Riddle, Yu, and the other prior art
`
`identified by Petitioners fails to disclose or teach the claimed “conversational flows.”
`
`42. Prior monitoring solutions classified packets exchanged between network
`
`addresses through methods such as examining fields in the protocol headers for a
`
`packet. However, just examining the packets involved in a single connection (or
`
`“connection flow”) often fails to provide the full picture of the activity causing the
`
`network transmission—many applications utilize multiple separate connections, and
`
`examining any individual connection flow may be insufficient to provide accurate
`
`monitoring.4
`
`43. The Challenged Patents teach how to recognize conversational flows, which
`
`are comprised of one or more related connection flows. This technique uses novel
`
`methods including inspecting and tracking connection flows and identifying whether
`
`connection flows are related based on an underlying activity involving particular
`
`network devices (users, clients, or servers). Information about these flows are
`
`
`
`4 As discussed in the ’099 Patent, “[t]he term ‘connection flow’ is commonly used
`
`to describe all the packets involved with a single connection.” Ex. 1001 at 2:35-37.
`
`18
`
`Packet Intelligence LLC Exh 2061
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 18 of 54
`
`
`
`maintained in a flow-entry database. The claimed monitor can use the set of related
`
`flows to recognize the activity that caused the flows to occur (such as launching an
`
`application which contacts one or more services) to be identified. In other words, the
`
`invention looks at the traffic passing through a connection point in the network and
`
`examines one or more (potentially disjointed) packet exchanges passing through that
`
`point. It uses that information to recognize related flows and to identify and classify
`
`the specific applications and activities that generated the packet exchanges.
`
`B.
`
`The Invention
`
`44. As noted by the specification, a conversational flow “is the sequence of
`
`packets that are exchanged in any direction as a result of an activity—for instance,
`
`the running of an application on a server as requested by a client. It is desirable to
`
`be able to identify and classify conversational flows rather than only connection
`
`flows. The reason for this is that some conversational flows involve more than one
`
`connection, and some even involve more than one exchange of packets between a
`
`client and server.” Ex. 1001 at 2:37-45. For example, a client may run an application
`
`which contacts a server in the cloud and that activity, the running of the application,
`
`may cause a sequence of packets to be exchanged between the client and the server
`
`resource involving multiple protocols, ports, URIs, etcetera. The different flows that
`
`are identified as related and associated with the underlying activity represent a
`
`conversational flow.
`
`19
`
`Packet Intelligence LLC Exh 2061
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 19 of 54
`
`
`
`45. This is different than prior art that classifies each packet as a unique event that
`
`is examined by itself. This single packet classification method allows counting all
`
`packets of a certain service (often based off of identifying a known port) but cannot
`
`always recognize individual service sessions or instances.
`
`46. Monitoring packets of an individual connection flow between a client and
`
`server, such as those exchanged in TCP/IP connections, is useful. These connection
`
`flows are frequently identified by the values in the packet header 5-tuple (consisting
`
`of source and destination address, source and destination port, and transport protocol
`
`type). However, understanding the activity that caused an individual connection to
`
`be created and tracking the state of the flows the activity created allows the present
`
`invention to recognize other connections (if any) related to that activity and to
`
`classify them together as a conversational flow. By identifying and monitoring
`
`exchanges from an application or service via the packet exchanges, the beginning,
`
`middle, and end of a conversational flow can be determined, allowing all elements
`
`of the activity which caused the conversational flow to be monitored or controlled.
`
`47. One thing that distinguishes conversational flows from other monitoring
`
`methods is that they do not represent a single event in time such as a single packet,
`
`but may consist of multiple sequences of packets from multiple different connections
`
`caused by an activity, such as the launching of an application by a client on a server.
`
`Launching an application can result in one or more connections and exchanges of
`
`20
`
`Packet Intelligence LLC Exh 2061
`Juniper Networks, Inc., et al v. Packet Intelligence LLC
`IPR2020-00337
`Page 20 of 54
`
`
`
`packets and potentially involves multiple protocols, ports, and addresses or URIs.
`
`This sequence of connections has a causal event, progresses through time, and has
`
`an end. This causal relationship and sequence of events contrasts with prior art
`
`techniques involving single packet or single connection flow evaluation.
`
`48. As I noted above, prior art monitoring methods frequently relied on “well
`
`known” ports used in IP connections to “guess” at the application that created the
`
`packet. As one skilled in the art can appreciate, relying on commonly used port
`
`numbers is useful for a limited set of the most common, well behaved, applications.
`
`This approach fails when a non-standard port is used. Further, this approach fails
`
`often when “guessing” which ephemeral port5 is associated with one of several
`
`applications on the client or server. The invention in the Challenged Patents tracks
`
`mul
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
