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.
`
`Case IPR2020-00337
`U.S. Patent No. 6,771,646
`
`PATENT OWNER’S SURREPLY
`
`
`
`
`
`
`
`Mail Stop “PATENT BOARD”
`Patent Trial and Appeal Board
`U.S. Patent and Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`PATENT OWNER’S EXHIBIT LIST
`
`
`
`2003
`
`2004
`2005
`
`Exhibit No. Description
`2001
`Withdrawn
`2002
`Packet Intelligence LLC v. Sandvine Corp., No. 2:16-cv-00147, Dkt.
`No. 17 (E.D. Tex. June 1, 2017) (order consolidating cases)
`File History for U.S. Patent No. 6,771,646 – Feb. 10, 2004,
`Response to Office Action (annotated version of Ex. 1020)
`Reserved
`Palo Alto Networks, Inc. v. Packet Intelligence LLC (No. 19-cv-
`02471-WHO) and Packet Intelligence LLC v. Juniper Networks, Inc.
`(No. 19-cv-04741-WHO), Transcript of Case Management
`Conference on January 7, 2020
`Palo Alto Networks, Inc. v. Packet Intelligence LLC, No. 19-cv-
`02471-WHO, Dkt. No. 62 (May 15, 2020) (Order Granting Palo
`Alto Networks’ Proposed Modification to the Scheduling Order)
`Packet Intelligence LLC v. Juniper Networks, Inc., No. 3:19-cv-
`04741-WHO, Dkt. No. 48 (March 29, 2020) (Stipulated First
`Amended Scheduling Order)
`PAN Contentions A5 – (Riddle)
`PAN Contentions A13 – (Yu)
`JUN Contentions A6 - (Riddle and Ferdinand)
`JUN Contentions A7 - (Riddle and Ferdinand and Yu)
`JUN Contentions A8 - (Riddle and Ferdinand and Baker)
`JUN Contentions A9 - (Riddle and Ferdinand and Baker and Yu)
`JUN Contentions A10 - (Riddle and Ferdinand and RFC1945)
`JUN Contentions A11 - (Riddle and Ferdinand and Baker and
`RFC1945)
`JUN Contentions B6 - (Riddle and Baker)
`JUN Contentions B7 - (Riddle and Baker and Yu)
`JUN Contentions B8 - (Riddle and Baker and RFC1945)
`JUN Contentions C6 - (Riddle and Ferdinand and Wakeman)
`
`2006
`
`2007
`
`2008
`2009
`2010
`2011
`2012
`2013
`2014
`2015
`
`2016
`2017
`2018
`2019
`
`ii
`
`

`

`2020
`
`2021
`
`2022
`2023
`2024
`2025
`2026
`2027
`2028
`2029
`
`2030
`2031
`2032
`2033
`
`2034
`2035
`2036
`
`2037
`2038
`2039
`2040
`2041
`
`2042
`
`2043
`2044
`
`2045
`
`IPR2020-00337
`U.S. Pat. No. 6,771,646
`JUN Contentions C7 - (Riddle and Ferdinand and Wakeman and
`Yu)
`JUN Contentions C8 - (Riddle and Ferdinand and Wakeman and
`RFC1945)
`JUN Contentions D6 - (Riddle and Ferdinand)
`JUN Contentions D7 - (Riddle and Ferdinand and Yu)
`JUN Contentions D8 - (Riddle and Ferdinand and RFC1945)
`JUN Contentions E6 - (Riddle and Ferdinand)
`JUN Contentions E7 - (Riddle and Ferdinand and Yu)
`JUN Contentions E8 - (Riddle and Ferdinand and Wakeman)
`JUN Contentions E9 - (Riddle and Ferdinand and Wakeman and Yu)
`JUN Contentions E10 - (Riddle and Ferdinand and Wakeman and
`RFC1945)
`JUN Contentions E11 - (Riddle and Ferdinand and Baker)
`JUN Contentions E12 - (Riddle and Ferdinand and Baker and Yu)
`JUN Contentions E13 - (Riddle and Ferdinand and RFC1945)
`JUN Contentions E14 - (Riddle and Ferdinand and Baker and
`RFC1945)
`JUN Contentions E15 - (Riddle and Ferdinand and Hasani)
`JUN Contentions E16 - (Riddle and Ferdinand and Hasani and Yu)
`JUN Contentions E17 - (Riddle and Ferdinand and Hasani and
`RFC1945)
`U.S. Patent No. 7,748,002 (“Beser”)
`File History for USPN 7,748,002 - October 3, 2006 Office Action
`U.S. Patent No. 7,706,357 (“Dyckerhoff”)
`File History for USPN 7,706,357 - June 30, 2009 Office Action
`January 18, 2019 Letter to Palo Alto Networks re Notice of
`Infringement
`January 18, 2019 Letter to Juniper Networks Inc re Notice of
`Infringement
`Withdrawn
`Complaint in Palo Alto Networks, Inc. v. Packet Intelligence LLC,
`No. 3:19-cv-02471-WHO (N.D. Cal.)
`Petition in IPR2019-01289
`
`iii
`
`

`

`2046
`2047
`2048
`2049
`2050
`
`2051
`
`2052
`
`2053
`2054
`2055
`2056
`2057
`2058
`2059
`
`2060
`
`2061
`2062
`2063
`2064
`2065
`2066
`
`2067
`
`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`Petition in IPR2019-01290
`Petition in IPR2019-01291
`Petition in IPR2019-01292
`Petition in IPR2019-01293
`Stay Order in Uniloc 2017 LLC v. Apple, Inc., No. 19-cv-01904-
`WHO (N.D. Cal.)
`Joint Motion to Amend the Scheduling Order in Palo Alto Networks,
`Inc. v. Packet Intelligence LLC, No. 3:19-cv-02471-WHO (N.D.
`Cal.)
`Order Granting PAN’s Proposed Modification to the Scheduling
`Order in Palo Alto Networks, Inc. v. Packet Intelligence LLC, No.
`3:19-cv-02471-WHO (N.D. Cal.)
`Petition in IPR2017-00450
`Petition in IPR2017-00451
`Petition in IPR2017-00629
`Petition in IPR2017-00630
`Petition in IPR2017-00769
`Petition in IPR2017-00869
`Final Judgment in Packet Intelligence LLC v. NetScout Systems,
`Inc. et. al., No. 2:16-cv-00230-JRG (E.D. Tex.)
`Packet Intelligence LLC v. NetScout Systems, Inc., et al, No. 2019-
`2041 (Fed. Cir. July 14, 2020) Decision
`Declaration of Cathleen T. Quigley
`CV of Cathleen T. Quigley
`Reserved
`RFC 768 - User Datagram Protocol
`RFC 1340 - Assigned Numbers
`Palo Alto Networks, Inc. v. Packet Intelligence LLC, No. 19-cv-
`02471-WHO, Dkt. No. 63 (June 4, 2020) (Packet Intelligence LLC’s
`Opening Claim Construction Brief)
`Palo Alto Networks, Inc. v. Packet Intelligence LLC, No. 19-cv-
`02471-WHO, Dkt. No. 67 (July 2, 2020) (Palo Alto Networks’
`Responsive Claim Construction Brief)
`
`iv
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`Palo Alto Networks, Inc. v. Packet Intelligence LLC, No. 19-cv-
`02471-WHO, Dkt. No. 68 (July 21, 2020) (Packet Intelligence
`LLC’s Reply Claim Construction Brief)
`Packet Intelligence LLC v. Juniper Networks, Inc., No. 19-cv-
`04741-WHO, Dkt. No. 57 (June 4, 2020) (Packet Intelligence LLC’s
`Opening Claim Construction Brief)
`Packet Intelligence LLC v. Juniper Networks, Inc., No. 19-cv-
`04741-WHO, Dkt. No. 62 (July 2, 2020) (Juniper’s Responsive
`Claim Construction Brief)
`Packet Intelligence LLC v. Juniper Networks, Inc., No. 19-cv-
`04741-WHO, Dkt. No. 68 (July 21, 2020) (Packet Intelligence
`LLC’s Reply Claim Construction Brief)
`Packet Intelligence LLC v. Juniper Networks, Inc., No. 19-cv-
`04741-WHO, Dkt. No. 71 (August 5, 2020) (Juniper’s Sur-Reply
`Claim Construction Brief)
`U.S. Patent No. 5,917,821 - Gobuyan
`U.S. Patent No. 5,850,388 - Anderson
`
`
`
`2068
`
`2069
`
`2070
`
`2071
`
`2072
`
`2073
`2074
`
`
`
`
`v
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`
`
`TABLE OF CONTENTS
`Introduction ....................................................................................................... 1 
`I. 
`II.  Argument .......................................................................................................... 1 
`A.  The Construction of “Conversational Flow” ............................................ 1 
`1.  A Network Activity Occurs Between Specific Entities ..................... 2 
`2.  Specification Embodiments Teach That Conversational
`Flows Occur Between Specific Entities ............................................. 5 
`B.  PI Addressed Each Ground Under the Board’s Preliminary
`Construction ............................................................................................ 12 
`C.  Riddle Fails to Disclose “Conversational Flows” ................................... 13 
`1.  Riddle Does Not Classify Activities Based on a Particular
`Client ................................................................................................. 13 
`2.  Riddle Categorizes Inbound and Outbound Traffic
`Separately .......................................................................................... 15 
`3.  Riddle Fails to Distinguish between Different Activities of
`the Same Type .................................................................................. 16 
`D.  Yu Fails to Teach Conversational Flows ................................................ 16 
`E.  RFC1945 Fails to Teach or Render Obvious Conversational Flows ...... 17 
`F.  Petitioner Fails to Prove that Yu is Prior Art .......................................... 17 
`G.  There is No Reason to Combine Yu with Riddle ................................... 17 
`H.  The Asserted Grounds Fail to Teach the State-Based Limitations ......... 18 
`I.  The Asserted Grounds Fail to Teach the Flow-Entry Database
`Limitations .............................................................................................. 20 
`J.  The Asserted Grounds Fail to Render the Associative Cache
`Limitations Obvious ................................................................................ 22 
`K.  The Board Should Limit Its Analysis to the Petition .............................. 23 
`III.  Conclusion ...................................................................................................... 23 
`
`
`
`
`
`vi
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`TABLE OF AUTHORITIES
`
`Cases 
`Arctic Cat Inc. v. Bombardier Rec. Prods.,
`876 F.3d 1350 (Fed. Cir. 2017) ......................................................................... 22
`Eon Corp. IP Holdings LLC v. Silver Spring Networks, Inc.,
`815 F.3d 1314 (Fed. Cir. 2016) ........................................................................... 3
`Koninklijke Philips N.V. v. Google LLC,
`948 F.3d 1330 (Fed. Cir. 2020) ......................................................................... 21
`Polaris Indus. v. Arctic Cat, Inc.,
`882 F.3d 1056 (Fed. Cir. 2018) ......................................................................... 18
`Realtime Data, LLC v. Stanley,
`554 F. App’x 923 (Fed. Cir. 2014) ...................................................................... 4
`Realtime Data, LLC v. Stanley,
`875 F. Supp. 2d 276 (S.D.N.Y. 2012) ................................................................. 4
`
`
`
`vii
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`I. Introduction
`Nothing in Petitioner’s Reply overcomes the deficiencies identified in Packet
`Intelligence’s (“PI”) Response (“POR”). Petitioner relies on art that categorizes
`network packet traffic into broad categories depending on the type of activity that
`generates a packet. This sort of generalized grouping does not teach the claimed
`conversational flow, which recognizes packets corresponding to a related
`conversation activity involving the same parties. Petitioner’s attempts to address the
`other shortcomings in its grounds (such as Riddle’s unidirectional nature of traffic
`classes) conflict with the express teachings of those references. Petitioner also failed
`to satisfy its burdens of proving that Yu is prior art, that a POSITA would have
`modified Riddle in view of Yu, or that the asserted grounds teach the state-based,
`flow-entry database, or associative cache limitations. Finally, Petitioner fails to
`justify why the Board should permit the use of Petitioner’s 525-page expert
`declaration to circumvent word limits.
`
`II. Argument
`A. The Construction of “Conversational Flow”
`A critical aspect of “conversational flows” is that each conversational flow
`relates to an activity. When read in the context of the specification, that “activity”
`occurs between specific entities, as explained by express language of the patent and
`as understood by a POSITA from embodiments disclosed in the specification. This
`is further confirmed by the specification’s teachings that a flow is understood within
`the context of its endpoint participants.
`
`1
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`1. A Network Activity Occurs Between Specific Entities
`Contrary to Petitioner’s assertion, PI does not seek to “narrow” the meaning
`of conversational flow. Reply at 2. Rather, PI clarifies that an activity implicates
`specific network devices (e.g., a client and server) and does not include all packet
`exchanges of a generic activity type as Petitioner proposes. The specification’s
`definitional language explains that an activity is, “for instance, the running of an
`application on a server as requested by a client….” EX1001 at 2:39-40; see also id.
`at 9:14-19 (“Any network activity—for example an application program run by the
`client 104 (CLIENT 1) communicating with another running on the server 110
`(SERVER 2)—will produce an exchange of a sequence of packets over network 102
`that is characteristic of the respective programs and of the network protocols.”). The
`invention background describes network activity monitors and information obtained
`by such monitors, including “who is using [network services.]” Id. at 1:57; see also
`id. at 3:23-25 (“What is needed, therefore, is a network monitor that makes it
`possible to continuously analyze all user sessions on a heavily trafficked
`network.”);1 id. at 3:34-35 (describing need to determine “an end user’s pattern of
`use within each application”); id. at 4:45-47 (object and advantage of the invention
`to “Recognize and classify all packets that are exchanges between a client and
`server into respective client/server applications”).
`The specification repeatedly teaches that flows occur in the context of
`communication between particular devices—not all communication of a particular
`
`
`1 All emphases added unless otherwise noted.
`
`2
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`type. See id. at 12:4-5 (“A flow is a stream of packets being exchanged between any
`two addresses in the network.”); id. at 6:37-38 (discussing “client/server
`conversational flow”). Flows are typically recognized based on a signature that
`includes information about the endpoint devices (client/server) involved in the
`packet communication. See, e.g., id. at 4:34-36 (“[A] signature is built for every flow
`such that future packets of the flow are easily recognized.”); id. at 32:43-47 (“A
`source and destination network address occupy the first two fields of each packet,
`and…the flow signature…will also contain these two fields…”); id. at 13:22-29
`(explaining that most flow signatures rely on source and destination addresses). To
`the extent an endpoint is not identified in a particular protocol (e.g., an application
`layer protocol), that information is embedded within lower-layer protocols (e.g.,
`Ethernet, TCP, IP). See id. at 9:54-57.
`Conversational flow must be interpreted in the context of the specification.
`See Eon Corp. IP Holdings LLC v. Silver Spring Networks, Inc., 815 F.3d 1314,
`1320-23 (Fed. Cir. 2016) (rejecting constructions “untethered to the context of the
`invention” even though they could, “in the abstract, be given such a broad
`meaning”). And the specification teaches that flows, flow signatures, and network
`activities (which result in flows) involve specific endpoints (client and server). To
`remove this aspect of a conversational flow, as Petitioner proposes, eliminates the
`notion of a flow, which is communication between two devices. See EX1001 at 12:4-
`5 (“A flow is a stream of packets being exchanged between any two addresses in the
`network.”). This understanding of conversational flow and network activity
`
`3
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`(corresponding to a client request) tracks how a POSITA would have understood
`these terms within the context of the specification. See EX2061 ¶¶41, 43-44, 47.
`Even if the language clarifying the scope of an activity were “exemplary,”
`that language must still be considered in determining the meaning of the term
`“conversational flow.” See Realtime Data, LLC v. Stanley, 554 F. App’x 923, 932-
`33 (Fed. Cir. 2014). The district court in Realtime Data construed the term “data
`field type” as “[c]ategorization of the data in the field (or block) as one of ASCII,
`image data, multimedia data, signed and unsigned integers, pointers, or other data
`type”, consistent with the examples provided in the specification. See Realtime
`Data, LLC v. Stanley, 875 F. Supp. 2d 276, 290-91, 296 (S.D.N.Y. 2012)
`(construing “data field type” from U.S. Patent No. 7,417,568, which enumerates the
`exemplary types at 14:6-8 as “data types (e.g., ASCII, image data, multimedia data,
`signed and unsigned integers, pointers, etc.)”). The Federal Circuit affirmed the
`construction, finding “[t]he district court was correct in concluding that, based on
`the specifications of the patents, the ‘data field/block type’ term…must be tied to
`some analysis of the content of the data field or block and cannot simply encompass
`any characteristic or attribute of data.” Realtime, 554 F. App’x at 933. The clarifying
`language regarding “an activity” is important here for the same reason—in the
`context of the specification, no reasonable person, let alone a POSITA, would
`interpret the use of “an activity” to include all packets related to the same type of
`activity.
`Despite Petitioner’s assertions otherwise (see Reply at 3), Ms. Quigley’s
`declaration extensively
`reinforces
`that a POSITA would understand a
`
`4
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`conversational flow to relate to a specific activity as requested by a client. Ms.
`Quigley analyzed, inter alia, the ’646 and ’099 Patent disclosures, and explained
`that the sequence of packets occurs “as requested by a client,” and noted that related
`connection flows are identified “based on an underlying activity involving
`particular network devices (users, clients, or servers).” EX2061 ¶¶41, 43-44; see
`id. ¶47 (describing conversational flow in the context of launching an application),
`¶50 (giving the analogy of conversations involving particular people—the
`users/clients/servers involved with a given action), ¶51 (noting that conversational
`flows are used to identify which applications are running and who is using them—
`i.e., which client requested them), ¶52 (“Applying the concept of conversational
`flows as taught by the Challenged Patents allows a monitor to understand the
`context of the application and the causal relationship of the launch to the creation
`of the multiple connections, and to capture all the relevant information needed to
`identify and monitor the individual calls.”), ¶54 (“A Zoom or Webex call ‘activity’
`is started by a user…”), ¶56 (same).
`
`2. Specification Embodiments Teach That Conversational Flows
`Occur Between Specific Entities
`Petitioner’s claim that “certain disclosed embodiments describe that different
`clients may be part of the same conversational flow” is incorrect. Reply at 3-4.
`Petitioner states that the SAP (Service Advertising Protocol) example “describes
`identifying packets as part of a conversational flow when those packets originate
`from different clients.” Id.
`
`5
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`Petitioner misreads the SAP example, which teaches two critical points. First,
`the SAP example
`teaches recognizing disjointed connection flows as a
`conversational flow because they relate to the same network activity. This first point
`is explained in PI’s Response. See POR at 10-11, 35-38. In short: an SAP Request
`is sent, and the server responds with an SAP Reply, which identifies the address (or
`port) for the print service. EX1001 at 2:52-56; EX1016 at 135:6-10. Later, a print
`request is sent to the address (or port) previously identified. EX1001 at 2:61-64. If
`the sender of the print request is the same client that sent the SAP request, that print
`request connection flow is recognized as related to the earlier SAP Request
`connection flow, thus belonging to the same conversational flow. If not, the print
`request connection flow (from a different client) is recognized as a different
`conversational flow.
`Second, the SAP example explains how to determine the type of a network
`activity based on previously observed communications, despite a protocol’s
`reliance on dynamic port allocation (such as server announcement protocols like
`SAP). This second point relates to the network monitor’s ability to recognize
`subsequent print requests from different clients as being “print request” activities.
`Because SAP uses a dynamic addressing scheme in which service addresses are
`determined by the server and then announced (or advertised) to the network, clients
`(and a network monitor) learn of the address correlation by intercepting a server
`announcement involving that address. EX1016 at 28:8-16, 30:4-15.
`
`6
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`Petitioner relies on the quote below to purportedly show how the same type
`of activity by different clients is considered a single conversational flow. But the
`language simply illustrates the scenario explained above:
`
`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.
`EX1016 at 3:28-30 (quoted by Reply at 4). The first sentence of this quote merely
`illustrates PI’s first point (above) about how disjointed connection flows can be
`recognized as related. The second sentence illustrates how a later print request by a
`different client can also be recognized as a print request activity because it uses the
`now known address of the print service.
`Petitioner also ignores an important detail: the location of SAP services can
`be acquired by means other than an SAP request, such as SAP advertising messages
`broadcast to the network. This is why it is possible for other clients who did not send
`the request to still know the server’s address. EX1016 at 3:18-21, 28:8-16 (“In the
`server announcement mode there are messages which are put out onto the network,
`in either a broadcast or multicast approach which, all stations in the network
`receive…There are several examples for this type of server announcement
`implementation…[including] SAP”), 135:12-13 (“SAP periodically broadcasts
`services that are in its advertising database.”). Thus, the passage quoted by Petitioner
`does not say that every exchange of SAP packets is part of a single conversational
`flow regardless of the clients involved. Instead, it addresses a case specific to
`dynamic addressing technology, in which the invention can still correctly identify
`
`7
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`the second conversational flow exchange as being associated with a print service
`even though the second client never issued its own SAP Request to the server.
`Ms. Quigley addressed the SAP example and reached the same conclusion.
`EX2061 ¶¶58-60. As she notes, the print request from the second client is part of a
`different conversational flow, and because the invention can recognize it as such it
`can “provide accurate monitoring data of service usage by individual users, rather
`than aggregating together all usage of a service by multiple users.” Id. Thus, a
`POSITA would understand the SAP example to reinforce that a conversational flow
`relates to a specific activity as requested by a client.
`Petitioner’s argument that “[Ms. Quigley] agrees that communications from
`different clients may be associated into a single ‘conversational flow’” is supported
`only by Petitioner stringing together statements from two different parts of Ms.
`Quigley’s declaration: “a conversational flow may include ‘other client-server
`connections’ related based on ‘servers.’” Reply at 5-6 (quoting EX2061 at p. 23
`¶51, then ¶43). This misquotation is misleading at best—the first portion of Ms.
`Quigley’s testimony explains that multiple connection flows (including “other
`client-server connections”) can be associated with a conversational flow. EX2061
`¶51. One way the specification reflects this concept is by the SAP example, which
`associates a first client-server connection (the SAP request) with another client-
`server connection (the print request). Id. ¶59. The second portion of Petitioner’s
`manufactured quote from Ms. Quigley is a snippet from the following: “This
`technique uses novel methods including inspecting and tracking connection flows
`and identifying whether connection flows are related based on an underlying
`
`8
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`activity involving particular network devices (users, clients, or servers).” EX2061
`¶43. Petitioner’s suggestion that Ms. Quigley agrees that a conversational flow
`includes all packets related to the same type of network activity is a gross
`misrepresentation of the actual language in her declaration.
`Additionally, Petitioner’s expert provides no testimony supporting its
`assertion that the SAP example describes different clients as being part of the same
`conversational flow. Dr. Weissman’s declaration mentions “SAP” in 24 paragraphs,
`and never once provides an opinion on how the SAP exchanges relate to
`conversational flows. See EX1006 ¶¶83-84 (noting the prosecution history
`statement that the flows are linked “[i]f the clients were the same”), ¶¶113, 943
`(discussing unrelated “service access point” SAP), ¶¶278, 330, 361, 388, 396, 560,
`675, 678, 694, 722, 726, 747, 785, 807, 815, 829, 951 (listing SAP as a protocol
`type), ¶¶307, 332, 638 (listing registered SAP as a “well-known” traffic type). Nor
`did Petitioner include any other evidence to support its new SAP theory with its
`Reply. Thus, the record contains no evidentiary support for Petitioner’s theory that
`SAP recognizes network activities initiated by different clients as part of the same
`conversational flow.
`reflects a similar
`the RPC protocol
`Petitioner’s argument about
`misunderstanding. See Reply at 5. Like SAP, RPC is another “server announcement
`protocol” that advertises the “appropriate connection point for communicating for
`[a] particular application.” EX1016 at 30:4-19. Typically, with RPC, specific
`programs or applications are available from a server. Id. at 30:16-21, 31:7-15. The
`’903 Provisional describes an example in the context of Figure 1:
`
`9
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`If Client 3 wants to identify the connection point for a specific application, it sends
`an RPC Bind Lookup Request to Server 2 requesting a version of that program. Id.
`at 31:7-11. Server 2 responds with an RPC Bind Lookup Reply “contain[ing] the
`specific Port number…on which future transactions will be accepted for the specific
`RPC program.” Id. at 31:12-20. Other clients may see this reply and therefore not
`need to make a similar request to initiate a network activity with the specific
`application being announced. Id. at 32:1-5. The network monitor can use this same
`information to identify the application implicated by later communications with the
`identified server and port. Id. at 31:23-26, 32:5-7. Yet nowhere in the disclosure
`
`10
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`does it say that RPC call flows initiating network activity with a specific application
`from different clients should be grouped into a single conversational flow.
`Petitioner’s arguments about SAP and RPC stem from either a
`misunderstanding or misrepresentation of server announcement protocols and how
`they announce (or advertise) the connection point for an application. If the
`connection point for a print application becomes known to multiple clients (either
`through individual requests, broadcasting, or some other means), those clients do
`not then have to make the same request to use the application that was previously
`announced. Instead, they can initiate network activity with those applications based
`on the previously obtained announcement information. Likewise, the network
`monitor can rely on the same announcement information to properly recognize such
`subsequent network activities as relating to the service or application that was
`announced. And Dr. Weissman’s declaration provides no support for Petitioner’s
`assertion that RPC describes different clients as being part of the same
`conversational flow. See generally EX1006.2
`In short, Petitioner provides no evidence supporting its theory that the
`claimed invention teaches that exchanges as a result of the same-type activities from
`multiple clients are grouped into the same conversational flow. Rather than submit
`evidence on this point, Petitioner proposes a convoluted read of the specification’s
`
`
`2 Dr. Weissman mentions RPC twice, neither of which supports Petitioner’s
`assertion all network activities of the same type are grouped into a single
`conversational flow. See EX1006 ¶¶83, 529.
`
`11
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`teachings and manufactures quotations from disparate portions of Ms. Quigley’s
`declaration to support its new theory.
`Finally, Petitioner states that “no tribunal has construed ‘conversational flow’
`as limited to ‘application activity involving the same client.’” Reply at 7. This issue
`has not been raised—despite multiple challenges to the validity of the patent—
`because no prior challenger has ever suggested that a conversational flow is
`completely independent of the participants in the conversation and instead only
`conglomerates all network activity of a certain type. As detailed above, this
`argument ignores the specification’s teachings about flows and network activities—
`the client and server participating in a conversation are part of the nature of a
`conversational
`flow. Petitioner’s
`last-resort argument conflicts with
`the
`specification and must be rejected.
`
`B. PI Addressed Each Ground Under the Board’s Preliminary Construction
`Petitioner’s claims that PI did not analyze the asserted grounds under the
`Board’s preliminary construction are false. Reply at 1-2, 10-11, 21 n.77. PI
`extensively discussed why Riddle does not teach conversational flows involving
`sequences of packets exchanged as a result of an activity. See POR at 34-43. PI also
`explained why Riddle does not teach “packets that are exchanged in any direction.”
`Id. at 44-45. And, PI explained that Yu cannot teach conversational flows at least
`because “it merely discloses treating similar types of connection flows according to
`the same policy” and cannot distinguish between different activities. Id. at 48-50; id.
`at 52-53 (addressing RFC1945). Finally, the Board determined that PI’s proposed
`
`12
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`construction is no different from the Board’s preliminary construction. See Paper 27
`at 4 (suggesting that the proposed clarifying language would be “non-limiting”).
`
`C. Riddle Fails to Disclose “Conversational Flows”
`Petitioner’s analysis of conversational flows and Riddle once again glosses
`over the requirement that the sequence of packets be exchanged as a result of an
`activity. Reply at 8-14. Petitioner points out that “Riddle teaches applying ‘policies’
`to control traffic classified as to type of service required.” Id. at 8 (internal quotes
`omitted). PI agrees that Riddle’s monitoring is limited to identifying traffic based
`only on the type of service being used. It does not teach identifying specific instances
`of service usage (activities) as required to teach conversational flows. Not only does
`Riddle not disclose the claimed limitation, it also does not even identify a need to
`classify specific activities; it is concerned with “classifying packet flows for use in
`allocating bandwidth resources.” EX1008 at Abstract; POR at 16-18, 40, 43. Riddle
`gives examples of a network operator dividing bandwidth between FTP and web
`traffic. EX1008 at 10:18-51. In the examples given, it is unnecessary to identify
`specific instances of FTP activity or specific instances of web activity to allocate
`bandwidth between the traffic classes.
`
`1. Riddle Does Not Classify Activities Based on a Particular Client
`Petitioner suggests that a service aggregate can distinguish between the same
`type of activity between different clients. Reply at 11-12. But Petitioner’s
`explanation hinges on an extrapolation of how a single connection example is
`classified that is not supported by the rest of the specification. In Riddle, service
`aggregates are a “common traffic class” that are “created with a plurality of traffic
`
`13
`
`

`

`IPR2020-00337
`U.S. Pat. No. 6,771,646
`
`specifications.” EX1008 at 11:15-23. Riddle notes “[a] traffic class is broadly
`defined as traffic between one or more clients and one or more servers.” Id. at 8:48-
`49, 14:18-20 (“[A]nother method of identifying an individual traffic class is to detect
`simultaneous connections to the same host port from different clients.”). Thus,
`Riddle does not classify traffic per user, but by the type of traffic based on properties
`such as the ports being used. This understanding reflects Riddle’s stated purpose—
`bandwidth management.
`Petitioner also suggests that, because a traffic class can be defined in terms of
`a specific source or destination IP address, that Riddle discloses “classifying traffic
`into client-specific conversational flows.” Reply at 11-12 (citing Riddle at 8:5