Petitioner’s Demonstrative Slides
`
`Juniper Networks, Inc. & Palo Alto Networks, Inc. v. Packet Intelligence LLC
`Inter Partes Review of U.S. Pat. Nos. 6,771,646 & 6,665,725
`June 9, 2021
`
`IPR2020-00336, IPR2020-00337
`Patent Trial and Appeal Board
`United States Patent and Trademark Office
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`1
`
`Juniper Exhibit 1113
`Juniper Networks, Inc. v. Packet Intelligence LLC
`Page 00001
`
`

`

`Introduction
`
`Table of Abbreviations
`
`Abbreviation
`
`Description
`
`’725
`
`’646
`
`Ex. 1002, U.S. Patent No. 6,665,725
`
`Ex. 1003, U.S. Patent No. 6,771,646
`
`Weissman
`
`Ex. 1006, Declaration of Dr. Jon B. Weissman [Petitioner’s Expert]
`
`Quigley
`
`Riddle
`
`Yu
`
`Ex. 2061, Declaration of Cathleen T. Quigley [PO’s Expert]
`
`Ex. 1008, U.S. Patent No. 6,412,000
`
`Ex. 1011, U.S. Patent No. 6,625,150
`
`[-00336/-00337] Pet.
`
`IPR2020-00336, Paper 3/IPR2020-00337, Paper 3 (Petition)
`
`[-00336/-00337] POPR
`
`IPR2020-00336, Paper 7/IPR2020-00337, Paper 7 (Patent Owner’s
`Preliminary Response)
`
`[-00336/-00337] DI
`
`IPR2020-00336, Paper 21/IPR2020-00337, Paper 20 (Decision on Institution)
`
`[-00336/-00337] POR
`
`IPR2020-00336, Paper 26/IPR2020-00337, Paper 26 (Patent Owner’s
`Response)
`
`[-00336/-00337] Reply
`
`IPR2020-00336, Paper 29/IPR2020-00337, Paper 30 (Petitioner’s Reply to
`Patent Owner’s Response)
`
`[-00336/-00337] POSR
`
`IPR2020-00336, Paper 32/IPR2020-00337, Paper 32 (Patent Owner’s Sur-
`Reply)
`
`All citations within quotations omitted herein, and emphasis added unless otherwise indicated
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`2
`
`Page 00002
`
`

`

`’725 Claims
`Claims 10, 12, 13, 16, 17
`Claims 10, 12, 13, 16, 17
`Claims 10, 12, 13, 16, 17
`
`-00336 Grounds
`Riddle in view of Baker
`Riddle in view of Baker and Yu
`Riddle in view of Baker and RFC1945
`
`IPR Grounds
`
`-00336 Pet. at 10.
`
`’646 Claims
`Claims 1-3, 7, 16, 18
`Claims 1-3, 7, 16, 18
`Claims 1-3, 7, 16, 18
`
`-00337 Grounds
`Riddle in view of Ferdinand and Wakeman
`Riddle in view of Ferdinand, Wakeman, and Yu
`Riddle in view of Ferdinand, Wakeman, and RFC1945
`
`-00337 Pet. at 7.
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`3
`
`Page 00003
`
`

`

`Introduction
`
`‘725, Exemplary Claims 10 and 17
`[10.pre]/[17.pre] A method of performing protocol specific operations on a packet passing through a
`connection point on a computer network, the method comprising:
`[10.1]/[17.1] (a) receiving the packet;
`[10.2]/[17.2] (b) receiving a set of protocol descriptions for a plurality of protocols that conform to a layered
`model, a protocol description for a particular protocol at a particular layer level including:
`[10.3]/[17.3] (i) if there is at least one child protocol of the protocol at the particular layer level, the one or
`more child protocols of the particular protocol at the particular layer level, the packet including for any
`particular child protocol of the particular protocol at the particular layer level information at one or more
`locations in the packet related to the particular child protocol,
`[10.4]/[17.4] (ii) the one or more locations in the packet where information is stored related to any child
`protocol of the particular protocol, and
`[10.5]/[17.5] (iii) if there is at least one protocol specific operation to be performed on the packet for the
`particular protocol at the particular layer level, the one or more protocol specific operations to be performed
`on the packet for the particular protocol at the particular layer level; and
`[10.6]/[17.6] (c) performing the protocol specific operations on the packet specified by the set of protocol
`descriptions based on the base protocol of the packet and the children of the protocols used in the packet,
`[10.7] wherein the protocol specific operations include one or more parsing and extraction operations on the
`packet to extract selected portions of the packet to form a function of the selected portions for identifying the
`packet as belonging to a conversational flow.
`[17.7] wherein the packet belongs to a conversational flow of packets having a set of one or more states, and
`wherein the protocol specific operations include one or more state processing operations that are a function of the
`state of the conversational flow of the packet, the state of the conversational flow of the packet being indicative
`of the sequence of any previously encountered packets of the same conversational flow as the packet.
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`4
`
`Page 00004
`
`

`

`’646, Exemplary Claims 1 and 3
`
`Introduction
`
`1. A packet monitor for examining packet passing through a connection point on a computer
`network, each packets conforming to one or more protocols, the monitor comprising:
`(a) a packet acquisition device coupled to the connection point and configured to receive
`packets passing through the connection point;
`(b) a memory for storing a database comprising flow-entries for previously encountered
`conversational flows to which a received packet may belong, a conversational flow being
`an exchange of one or more packets in any direction as a result of an activity
`corresponding to the flow;
`(c) a cache subsystem coupled to the flow-entry database memory providing for fast access
`of flow-entries from the flow-entry database;
`(d) a lookup engine coupled to the packet acquisition device and to the cache subsystem
`and configured to lookup whether a received packet belongs to a flow-entry in the flow-entry
`database, to looking up being the cache subsystem; and
`(e) a state processor coupled to the lookup engine and to the flow-entry-database memory,
`the state processor being to perform any state operations specified for the state of the flow
`starting from the last encountered state of the flow in the case that the packet is from an
`existing flow, and to perform any state operations required for the initial state of the new flow
`in the case that the packet is from an existing flow.
`
`3. A packet monitor according to claim 2, wherein the cache subsystem is an associative
`cache subsystem including one or more content addressable memory cells (CAMs).
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`5
`
`Page 00005
`
`

`

`Claim Construction
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`6
`
`Page 00006
`
`

`

`“Conversational Flow” Dispute Overview
`
`Claim Construction
`
`Trial grounds render obvious the challenged claims under the
`Board’s preliminary construction and under PO’s incorrect
`construction.
`
`See generally -00336 Pet.; -00337 Pet.; see also -00336 Reply 8-14, 21-22, 27-29; -00337 Reply 8-14, 21-22, 25-27..
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`7
`
`Page 00007
`
`

`

`Claim Construction
`The Board Adopted the Specification’s Lexicography of the
`Coined Term “Conversational Flow”
`
`’099 Specification: “A conversational flow, on the other hand, 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.”
`
`’099, 2:37-40; ’725, 1:17-21; ’646, 1:16-18.
`see also -00336 DI, 28-31, n. 15; -00337 DI, 26-29, n.15.
`
`Board’s construction: “sequence of packets that are exchanged
`in any direction as a result of an activity”
`
`-00336 DI, 31; -00337 DI, 29.
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`8
`
`Page 00008
`
`

`

`Claim Construction
`PO Proposes Limiting “Conversational Flow” to “Application Activity by a
`Particular User or Client” Based on One Specification Example
`
`PO: “This Board has preliminarily concluded that it can effectively ignore
`everything after ‘for instance’ because it is only exemplary. That language,
`however, makes apparent that ‘conversational flow’ must relate to a
`conversation. It involves an application activity involving the same client.”
`
`-00336 POR 25; -00337 POR 26.
`
`But an “activity” involving just one client is merely exemplary:
`’099 Specification: “A conversational flow, on the other hand, 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.”
`
`’099 2:37-40; ’725, 1:17-21; ’646, 1:16-18.
`see also -00336 DI, 28-31, n. 15; -00337 DI, 26-29, n.15; -00336 Reply 3; -00337 Reply 3.
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`9
`
`Page 00009
`
`

`

`Specification’s Exemplary Language Doesn’t Limit
`“Conversational Flow” Scope
`
`Claim Construction
`
`Federal Circuit explaining exemplary language isn’t limiting: “[T]he term
`‘such as’ means ‘of a kind or character about to be indicated, suggested, or
`exemplified; for instance.’…‘Such as’ introduces an example of a broader
`genus rather than limiting the genus to the exemplary species.”
`
`Catalina Mktg. Int’l v. Coolsavings.com, Inc., 289 F.3d 801, 811 (Fed. Cir. 2002); -00336 Reply, 7; -00337 Reply 7.
`
`In NetScout decision, Federal Circuit didn’t limit activity of “conversational flow” to a
`specific user or client device:
`Federal Circuit: “The specifications explain that it is more useful to identify
`and classify ‘conversational flows,’ defined as ‘the sequence of packets
`that are exchanged in any direction as a result of an activity.’”
`
`Packet Intelligence LLC v. NetScout Sys., 965 F.3d 1299, 1303 (Fed. Cir. 2020) (citing ’789, 2:45-47); -00336 Reply, 8; -00337 Reply 8.
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`10
`
`Page 00010
`
`

`

`PO’s Expert Concedes “Conversational Flow” Isn’t Limited
`to an Activity “by a Particular User or Client Device”
`
`Claim Construction
`
`Ms. Quigley: “By recognizing the context of a sequence of packets, packets
`can be associated with a conversational flow consisting of other
`sequences that may be other connections, other protocols, other client-
`server connections and so forth.”
`
`Quigley ¶51.
`
`Ms. Quigley: “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).”
`
`Quigley ¶43.
`See also -00336 Reply 5; -00337 Reply 5.
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`11
`
`Page 00011
`
`

`

`Limiting “Conversational Flow” to “a Particular User or
`Client Device” Would Exclude Embodiments
`
`Claim Construction
`
`PO’s ’903 Provisional: “Some conversational flows involve more than
`one connection …. For example, SAP (Service Advertising Protocol) is a
`NetWare (Novell Systems, Provo, Utah) protocol used to identify the services
`and addresses of servers attached to a network…. It is desirable for a
`network packet monitor to be able to “virtually concatenate” the first
`exchange that defines SAP #5 as the print service on the server with the
`second exchange that uses the print service. The two packet exchanges
`would then be correctly identified as being part of the same flow if the
`clients were the same. They would even be recognized if the clients
`were not the same. One feature of the invention is to correctly identify the
`second exchange as being associated with a print service on the server.
`
`Other protocols that are similar in that they may lead to disjointed
`conversational flows include ….”
`
`Ex. 1016 (’903 Provisional), 3:9-4:2; -00336 Reply 4; -00337 Reply 4.
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`12
`
`Page 00012
`
`

`

`PO’s Attempt to Redefine “Activity” to Require a Specific
`Client/User Contravenes the Law
`
`Claim Construction
`
`PO doesn’t establish any clear disclaimer or lexicography that would be
`required to redefine “activity”:
`Federal Circuit: “The patentee's lexicography must, of
`course, appear ‘with reasonable clarity, deliberateness, and
`precision’ before it can affect the claim.”
`
`Renishaw PLC v. Marposs Societa’ per Azioni, 158 F.3d 1243, 1249 (Fed. Cir. 1998).
`
`Specification uses activity in its ordinary sense of any network activity,
`not just a particular user or client activity:
`PO’s ’903 Provisional: “Any network activity … will produce an exchange of
`a sequence of packets, called a conversational flow….”
`
`Ex. 1016 (’903 Provisional), 14:9-12; -00336 Reply 6; -00337 Reply 6.
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`13
`
`Page 00013
`
`

`

`Prior Art Discloses Conversational
`Flows (All Challenged Claims)
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`14
`
`Page 00014
`
`

`

`“Conversational Flow” Dispute Overview
`
`Claim Construction
`
`PO failed to address the trial grounds under the Board’s preliminary construction, waiving
`arguments that the art doesn’t disclose “conversational flow” under that construction:
`
`Scheduling Order: “Patent Owner may file … [a]
`response to the petition (37 C.F.R. § 42.120). … Patent
`Owner is cautioned that any arguments for patentability
`not raised in the response may be deemed waived.”
`
`IPR2020-00336, Paper 22, 8; IPR2020-00337, Paper 21, 8.
`See also, -00336 Reply 2, 10-11; -00337 Reply 2, 10-11.
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`15
`
`Page 00015
`
`

`

`Prior Art Discloses Conversational
`Flows (All Challenged Claims) –
`Riddle (Ground 1)
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`16
`
`Page 00016
`
`

`

`Riddle Overview
`Riddle Discloses a System for Classifying Packet Flows According to a
`Selectable List of Characteristics
`
`Riddle: “The method comprises applying individual instances
`of traffic classification paradigms to packet network flows
`based on selectable information obtained from a plurality
`of layers of a multi-layered communication protocol in order
`to define a characteristic class, then mapping the flow to the
`defined traffic class.”
`
`Riddle, 4:10-15; -00337 Pet. 18, 31-32, 35-37, 61-62; -00337 Pet. 39, 70-73;
`See also Weissman ¶¶114-115, 287, 486-488, 732-733.
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`17
`
`Page 00017
`
`

`

`Riddle Overview
`Riddle Teaches Defining a Traffic Class for a Specific Client-Server Pair
`Running a Specific Application
`
`Riddle: “Table 2 depicts components from which Traffic classes
`may be built.”
`
`Riddle, 9:64-65.
`See also Weissman ¶¶487-488, 732-733; -00336 Pet. 19-20, 36; -00337 Pet. 18-19, 71-72..
`
`Specific Client
`
`Specific
`Application
`
`Specific Server
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`18
`
`Page 00018
`
`

`

`Riddle Overview
`Riddle Classifies Disjointed Flows Resulting from the Same
`Activity into a “Service Aggregate”
`
`Riddle: “A service aggregate is provided for certain applications that use more than
`one connection in a particular conversation between a client and a server.
`
`Riddle, 11:10-13.
`
`Riddle’s Provisional: “[T]he concept of ‘service aggregates’ (service groups) [is] different
`traffic types that are associated together (ex. FTP has one stream that it uses to exchange
`commands and responses, and a second that the data files are actually sent
`over).Whenever we recognize the signature of one of these types of traffic, we create
`a traffic class (or class hierarchy) that can match all the components of the
`aggregate.”
`
`Ex. 1024 (Riddle’s Provisional), 69.
`See also Weissman ¶¶122-133, 304-305, 353, 356-357, 531, 544, 556-568, 628, 632-634; -00336 Pet. 22, 64-66, 72-75;
`-00337 Pet. 49-53; -00336 Reply 10-13, 15-18; -00337 Reply 10-11, 13, 16.
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`19
`
`Page 00019
`
`

`

`Riddle Overview
`Riddle Classifies Disjointed Flows Resulting from the Same
`Activity into a “Service Aggregate”
`
`Riddle: “In a step 420, an instance of saved traffic is
`retrieved from the saved traffic list 308. Next in a
`decisional step 422, the instance of saved traffic is
`examined to determine whether it is well-known (e.g.
`registered SAP, protocol type, assigned port number)
`and a name representing its type exists. If this is so then
`processing continues with a test of whether the saved
`traffic belongs to a service aggregate in step 426. … For
`example, an FTP session has one flow that is used
`to exchange commands and responses and a
`second flow that is used to transport data files. If
`the traffic does belong to a service aggregate, then
`in a step 428, a traffic class is created which will
`match all components of the service aggregate.”
`
`See also Weissman ¶¶122-133, 304-305, 353, 356-357, 531, 544, 556-568, 628, 632-634;
`-00336 Pet. 22, 64-66, 72-75; -00337 Pet. 49-53; -00336 Reply 10-13, 15-18; -00337 Reply 10-11, 13, 16.
`
`Riddle, 13:40-59.
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`20
`
`Page 00020
`
`

`

`Prior Art Discloses Conversational Flows (All Challenged Claims)
`Riddle Discloses “Conversational Flows” Under the Board’s and
`PO’s Constructions
`
`There is no dispute that Riddle discloses classifying packets and flows by
`underlying application:
`
`PO Admits: “Riddle combines flows of the same type into a traffic class. …
`Once it identifies the type of activity at issue, it can impose an appropriate
`policy (e.g., grant full bandwidth to file-sharing related to work; throttle video
`streaming from Netflix).”
`
`-00336 POR 37 (citing Quigley ¶¶81-82); -00337 POR 43.
`
`Board’s Construction: “sequence of packets that are exchanged in any direction as a
`result of an activity”
`
`PO’s Construction: “[T]he 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—and where some conversational flows involved more than one connection, and
`some even involve more than one exchange of packets between a client and server.”
`
`See generally -00336 Pet.; -00337 Pet.; see also -00336 Reply 8-14, 21-22, 27-29; -00337 Reply 8-14, 21-22, 25-27..
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`21
`
`Page 00021
`
`

`

`Prior Art Discloses Conversational Flows (All Challenged Claims)
`Riddle Discloses “Conversational Flows” Under the Board’s and
`PO’s Constructions
`
`Riddle: “These uses may be isolated and classified into a separate class. Marimba
`and pointcast can be distinguished by looking into the data for a signature
`content header in the get request. Pointcast has URLs that begin with ‘/FIDO-1/.’”
`
`Dr. Weissman: “Riddle teaches forming a
`function of selected packet portions for
`identifying that packet as belong to a
`“conversational flows” by classifying
`separate packet flows as being PointCast
`traffic. …
`
`Riddle, 11:59-62.
`
`Riddle, 10:1-18 (Table 2).
`Weissman ¶553; see also id. ¶¶316-327, 554, 636.
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`Weissman ¶53.
`See also -00336 Pet. 63-64, 69-72; -00337 Pet. 42, 54-57.
`
`22
`
`Page 00022
`
`

`

`Prior Art Discloses Conversational Flows (All Challenged Claims)
`Riddle Discloses “Conversational Flows” Under the Board’s and
`PO’s Constructions
`
`PO’s ‘903 Provisional specifies that identifying PointCast traffic is an
`example of identifying a “conversational flow”:
`‘903 Prov’l: The state processor processes single and multi packet protocol
`recognition. It may have to search through a series of possible states to determine
`the flow's actual state. The result of this processing is a consolidated flow entry. This
`enables the monitor to correctly determine disjointed flows. For example, a
`PointCast session (PointCast, Inc., Cupertino, CA) will open multiple
`conversations packet-by-packet that might look like separate flows to prior art
`monitors. However, each of these connections is merely a sub-flow under the
`PointCast master flow, so a single flow that consolidates all of the information
`for the flow is desired. The analyzer is able to so consolidate individual
`connections since the state of the overall flow is maintained by the monitor.
`
`’903 Prov., 7:16-25;
`See also -00336 Pet. 63-64, 69-72; -00337 Pet. 42, 54-57.
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`23
`
`Page 00023
`
`

`

`Prior Art Discloses Conversational Flows (All Challenged Claims)
`Even Under PO’s Construction, Riddle Teaches “Conversational Flow”
`Limitations By Classifying Packets and Flows Based on a Particular Client
`
`PO argues: “Riddle does not classify traffic per user, but by the type of
`traffic based on properties such as the ports being used.”
`
`-00336 POSR 14; -00337 POSR 13-14.
`
`But Riddle discloses classifying
`traffic based on user’s IP addresses
`and FTP connections:
`
`Riddle: “Table 2 depicts
`components from which Traffic
`classes may be built.”
`
`Riddle, 9:64-65.
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`Riddle, 10:1-18 (Table 2).
`24
`See also Weissman ¶¶487-488, 732-733; -00336 Pet. 19-20, 36; -00337 Pet. 18-19, 71-72..
`
`Page 00024
`
`

`

`Prior Art Discloses Conversational Flows (All Challenged Claims)
`Even Under PO’s Construction, Riddle Teaches “Conversational Flow”
`Limitations By Classifying Packets and Flows Based on a Particular Client
`
`Riddle provides a service aggregate between a particular client and server, which PO’s
`expert never addresses:
`Riddle: “A service aggregate is provided for certain applications that use more than one
`connection in a particular conversation between a client and a server. For example, an FTP
`client in conversation with an FTP server employs a command channel and a transfer channel,
`which are distinct TCP sessions on two different ports. In cases where two or three TCP or UDP
`sessions exist for each conversation between one client and one server, it is useful to provide
`a common traffic class i.e., the service aggregate, containing the separate conversations. In
`practice, these types of conversations are between the same two hosts, but use different
`ports. According to the invention, a class is created with a plurality of traffic specifications,
`each matching various component conversations.”
`
`As Dr. Weissman’s unrebutted testimony establishes, Riddle teaches client- and
`application-specific conversational flows:
`Dr. Weissman: “As an example, one traffic class is a global FTP application (a client-
`server software program for transferring files using the FTP protocol) using a specific client-
`side IP address and a specific server-side IP address, as shown below in Table 2.”
`
`Riddle, 11:10-23.
`
`Weissman ¶126.
`See also, Weissman ¶¶128-131, 302-334, 547-553, 632-636; -00336 Pet. 21-23, 63-72;-00337 Pet. 20-22, 45-46, 49-56; -00336 Reply 10-14; -00337 Reply 10-14.
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`25
`
`Page 00025
`
`

`

`Prior Art Discloses Conversational Flows (All Challenged Claims)
`Even Under PO’s Construction, Riddle Teaches “Conversational Flow”
`Limitations By Classifying Packets and Flows Based on a Particular Client
`
`PO fails to address Riddle’s claims, which teach creating a service
`aggregate from two disjointed flows for a specific pair of hosts:
`Riddle claim 1: “[P]arsing a packet into a first flow specification, said first flow
`specification contains at least one instance of any one of the following: a protocol family
`designation, a direction of packet flow designation, a protocol type designation, a pair of
`hosts, a pair of ports, in HTTP protocol packets, a pointer to a MIME type….”
`
`Riddle claim 2: “The method of claim 1 further comprising the steps of … recognizing
`said second flow specification and said first flow specification to comprise together
`a service aggregate; thereupon, associating said first flow specification and said second
`flow specification with a newly-created classification tree node….”
`
`See also Weissman ¶¶311-313, 632-633, 549, 550; -00336 Pet. 22, 26, 36;
`-00337 Pet. 21, 51, 71-72; -00336 Reply 11-12; -00337 Reply 11-12..
`
`Riddle, 15:56-16:26 (claims 1-2).
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`26
`
`Page 00026
`
`

`

`Prior Art Discloses Conversational Flows (All Challenged Claims)
`Even Under PO’s Construction, Riddle Teaches “Conversational Flow”
`Limitations By Classifying Packets and Flows Based on a Particular Client
`
`PO’s expert fails to address Riddle’s teaching towards displaying service aggregates
`based on host’s source or destination:
`Riddle: The Network manager may … select traffic types she wishes to add to the classification
`tree. The display can be hierarchical, as depicted in lines (3) below:
`FTP (3)
`FTP-cmd
`FTP-data
`to host1
`tcp….
`
`Riddle, 13:8-22; ’864 Prov., 24.
`
`Riddle: “Traffic classes may be defined at any level of the IP protocol as well as for other non-IP
`protocols. For example, at the IP level, traffic may be defined as only those flows between a
`specifi[]ed set of inside and outside IP addresses or domain names. An example of such a low
`level traffic class definition would be all traffic between my network and other corporate offices
`throughout the Internet. At the application level, traffic classes may be defined for specific URIs
`within a web server. Traffic classes may be defined having “Web aware” class attributes. For
`example, a traffic class could be created such as all URIs matching “*.html” for all servers, or all URI
`patterns matching “*.gif” for server X, or for access to server Y with URI pattern “/sales/*” from
`client Z, wherein ‘*’ is a wildcard character, i.e., a character which matches all other character
`combinations. Traffic class attributes left unspecified will simply match any value for that attribute.”
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`Riddle 8:58-9:8.
`See also Weissman ¶¶311-312, 632-633 549-550; -00336 Pet. 22, 26, 36;
`-00337 Pet. 21, 51, 71-72; -00336 Reply 11-12; -00337 Reply 11-12..
`
`27
`
`Page 00027
`
`

`

`Prior Art Discloses Conversational Flows (All Challenged Claims)
`Even Under PO’s Construction, Riddle Teaches “Conversational Flow”
`Limitations By Classifying Packets and Flows Based on a Particular Client
`
`PO argues: “A rule written specifically for a client’s IP address would not
`distinguish one client activity from another; it would simply aggregate all
`traffic for the client.”
`
`-00336 POSR 14-15; -00337 POSR 14.
`
`But Riddle classifies traffic based on
`multiple attributes, including IP
`address, port number, & application:
`
`Riddle: “Table 2 depicts
`components from which Traffic
`classes may be built.”
`
`Riddle, 9:64-65.
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`Riddle, 10:1-18 (Table 2).
`28
`See also Weissman ¶¶487-488, 732-733; -00336 Pet. 19-20, 36; -00337 Pet. 18-19, 71-72..
`
`Page 00028
`
`

`

`Prior Art Discloses Conversational Flows (All Challenged Claims)
`Even Under PO’s Construction, Riddle Teaches “Conversational Flow”
`Limitations By Classifying Packets and Flows Based on a Particular Client
`
`And Riddle discloses that a service aggregate is for a specific activity (e.g.,
`FTP session) between one client and one server:
`
`Riddle: “A service aggregate is provided for certain applications that use more
`than one connection in a particular conversation between a client and a server.
`For example, an FTP client in conversation with an FTP server …. According to
`the invention, a class is created with a plurality of traffic specifications, each
`matching various component conversations.”
`
`Riddle, 11:10-23.
`See also Weissman ¶¶128-131, 302-334, 547-553, 632-636; -00336 Pet. 21-23, 63-72;-00337 Pet. 20-22, 45-
`46, 49-56; -00336 Reply 10-14; -00337 Reply 10-14.
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`29
`
`Page 00029
`
`

`

`Prior Art Discloses Conversational Flows (All Challenged Claims)
`Riddle Identifies and Classifies Bidirectional Traffic − Not Traffic
`in Only One Direction
`
`PO argues: “Riddle expressly teaches that its traffic classes are limited to
`unidirectional traffic, and that service aggregates are traffic classes.”
`
`-00336 POSR 14-15; -00337 POSR 14.
`
`But neither the claims nor the term
`“conversational flow” requires
`bidirectionality under any proposed
`construction.
`PO and its expert admit that
`conversational flows can include, but are
`not limited to, bidirectional flows:
`
`Ms. Quigley: “Conversational flows,
`however, can include a bidirectional
`exchange of packets.”
`
`Quigley, ¶¶83, 60 (Fig. 4).
`
`PO: “Under the Board’s preliminary
`construction (as well as Patent Owner’s
`proposed construction), ‘conversational
`flows’ include bidirectional exchanges of
`packets.”
`
`-00336 POR 36; -00337 POR 44.
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`See also Weissman ¶¶304-309, 549-551, 632-635; -00336 Pet. 64-67;
`-00337 Pet. 49-51; -00336 Reply 12-13; -00337 Reply 13.
`
`30
`
`Page 00030
`
`

`

`Prior Art Discloses Conversational Flows (All Challenged Claims)
`Riddle Classifies Traffic In Both Directions Into a Service
`Aggregate (Which PO’s Expert Never Addresses)
`
`Riddle: [A]n FTP session has one flow that is used to exchange commands and
`responses and a second flow that is used to transport data files. If the traffic does belong to a
`service aggregate, then in a step 428, a traffic class is created which will match all
`components of the service aggregate.”
`
`Riddle, 13:54-59.
`
`Riddle: “A service aggregate is provided for certain applications that use more than one
`connection in a particular conversation between a client and a server. For example, an FTP
`client in conversation with an FTP server employs a command channel and a transfer
`channel, which are distinct TCP sessions on two different ports. In cases where two or three
`TCP or UDP sessions exist for each conversation between one client and one server, it is
`useful to provide a common traffic class i.e., the service aggregate, containing the
`separate conversations. In practice, these types of conversations are between the same
`two hosts, but use different ports. According to the invention, a class is created with a
`plurality of traffic specifications, each matching various component conversations.”
`
`Riddle, 11:10-23.
`See also Weissman, ¶¶120, 292, 309, 551, 634, 269; -00336 Pet. 66-67; -00337 Pet. 49-51;
`-00336 Reply 13, 20; -00337 Reply 19, 36-37.
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`31
`
`Page 00031
`
`

`

`Prior Art Discloses Conversational Flows (All Challenged Claims)
`Riddle Identifies and Classifies Bidirectional Traffic − Not in
`Only One Direction
`
`When describing classification, Riddle never limits it to classifying inbound
`and outbound flows separately:
`Riddle: “Traffic classes have properties or class attributes such as, directionality, which
`is the property of traffic to be flowing inbound or outbound.”
`
`Riddle, 5:42-45.
`
`Riddle: “[P]arsing a packet into a first flow specification, said first flow specification
`contains at least one instance of any one of the following: a protocol family
`designation, a direction of packet flow designation, a protocol type designation, a pair
`of hosts, a pair of ports, in HTTP protocol packets, a pointer to a MIME type….”
`
`Riddle, claim 1.
`See also, Weissman ¶123; -00336 Pet. 21-23, 64-67; -00337 Pet. 20-22, 49-54; -00336 Reply 12-13; -00337 Reply 13.
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`32
`
`Page 00032
`
`

`

`Prior Art Discloses Conversational Flows (All Challenged Claims)
`PO’s Expert Declaration Is Entitled to Little Weight
`
`Ms. Quigley’s declaration includes only four
`pages of conclusory analysis regarding Riddle,
`which fail to address Riddle’s teachings on:
`– Pointcast classification
`– Service aggregate disclosure at 13:36-56
`– Figures, including Figs. 4A, 4B
`– Traffic class examples at 8:58-9:10 (e.g., client
`Z to server Y with specific URI pattern)
`– Flow classification and display disclosure at
`12:65-13:28
`– Subclassification disclosure at 11:24-36
`– Riddle’s claims
`– Material incorporated by reference (e.g.,
`Packer reference)
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`See also, -00336 Reply 3, 12, n. 58; -00337 Reply 3, 12, n. 53.
`
`33
`
`Page 00033
`
`

`

`Prior Art Discloses Conversational Flows (All Challenged Claims)
`PO’s Expert Declaration Is Entitled to Little Weight
`
`PO’s expert: “A POSITA would not understand Riddle to teach conversational flows,
`because Riddle does not teach tracking individual connection flows, let alone relating
`individual connection flows into a conversational flow.”
`
`But neither Board’s nor PO’s
`constructions requires “tracking
`individual connection flows” or
`“relating individual connection flows
`into a conversational flow”:
`
`Quigley ¶80.
`
`Board’s construction: “sequence of
`packets that are exchanged in any direction
`as a result of an activity”
`
`PO’s construction: “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—and where some
`conversational flows involve more than one
`connection, and some even involve more
`than one exchange of packets between a
`client and server”
`
`PETITIONER’S DEMONSTRATIVE EXHIBIT – NOT EVIDENCE
`
`34
`
`Page 00034
`
`

`

`Prior Art Discloses Co