Paper No. 25
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`––––––––––––––––––
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`––––––––––––––––––
`
`RIOT GAMES, INC., and
`VALVE CORP.,
`Petitioners,
`
`v.
`
`PALTALK HOLDINGS, INC.,
`Patent Owner.
`
`––––––––––––––––––
`
`Case No. IPR2018-001321
`U.S. Patent No. 6,226,686 & 6,226,686 C1
`
`
`––––––––––––––––––
`
`PETITIONERS’ REPLY
`
`
`
`
`
`
`
`
`
`
`
`
`
`1 Case IPR2018-01243 has been joined with this proceeding.
`
`

`

`IPR2018-00132 (U.S. Pat. No. 6,226,686)
`
`Petitioners’ Reply
`
`TABLE OF CONTENTS
`
`I.
`
`II.
`
`Introduction .................................................................................................... 1
`
`The Challenged Claims are Unpatentable .................................................. 2
`
`A.
`
`The Combination of Aldred and RFC 1692 was Obvious .................... 2
`
`i.
`
`ii.
`
`RFC 1692 Does Not Reorder TCP Segments ............................. 3
`
`Aldred Maintains the Order of Serialized Updates ..................... 5
`
`iii. Aldred Does Not Require the Use of Large Packets .................. 7
`
`iv.
`
`The Techniques of Aldred and RFC 1692 are Complementary . 8
`
`B.
`
`Aldred and RFC 1692 Disclose the Claimed “Aggregated Message,”
`“Server Message,” and “Aggregated Payload” (All Claims) .............. 12
`
`i.
`
`ii.
`
`iii.
`
`iv.
`
`There is No Basis for PalTalk’s “Transport Layer” Header
`Requirement .............................................................................. 13
`
`The ’686 Patent’s Transport Level Protocol Disclosure Cannot
`Support a “Transport Layer” Requirement ............................... 18
`
`PalTalk’s Construction Would Read Out a Preferred
`Embodiment .............................................................................. 20
`
`The ’686 Patent Does Not Disclaim Including “Transport
`Layer” Headers ......................................................................... 21
`
`Claims 22, 41, and 58 are Unpatentable ............................................. 23
`
`Claims 23, 42, and 59 are Unpatentable ............................................. 25
`
`Claims 24, 25, 43, 44, 60, and 61 are Unpatentable ........................... 27
`
`Remaining Claims ............................................................................... 27
`
`C.
`
`D.
`
`E.
`
`F.
`
`III. Conclusion .................................................................................................... 28
`
`Exhibit List ............................................................................................................. 29
`i
`
`

`

`IPR2018-00132 (U.S. Pat. No. 6,226,686)
`
`Petitioners’ Reply
`
`Certificate Of Compliance .................................................................................... 32
`
`Certificate Of Service............................................................................................. 33
`
`
`
`
`
`
`
`ii
`
`

`

`IPR2018-00132 (U.S. Pat. No. 6,226,686)
`
`Petitioners’ Reply
`
`TABLE OF AUTHORITIES
`
` Page(s)
`
`Cases
`Accent Packaging, Inc. v. Leggett & Platt, Inc.,
`707 F.3d 1318 (Fed. Cir. 2013) .......................................................................... 21
`Apple Inc. v. VirnetX Inc.,
`IPR2014-00237, Paper 41 (PTAB May 11, 2015) ............................................... 8
`Bristol-Myers Squibb Co. v. Teva Pharms. USA, Inc.,
`752 F.3d 967 (Fed. Cir. 2014) ............................................................................ 10
`Dealertrack, Inc. v. Huber,
`674 F.3d 1315 (Fed. Cir. 2012) .......................................................................... 21
`In re Fulton,
`391 F.3d 1195 (Fed. Cir. 2004) ...................................................................... 9, 10
`i4i Ltd. P’ship v. Microsoft Corp.,
`598 F.3d 831 (Fed. Cir. 2010) ............................................................................ 22
`KSR Int’l Co. v. Teleflex Inc.,
`550 U.S. 398 (2007) ........................................................................................ 9, 11
`In re Kubin,
`561 F.3d 1351 (Fed. Cir. 2009) .......................................................................... 11
`Liebel-Flarsheim Co. v. Medrad, Inc.,
`358 F. 3d 898 (Fed. Cir. 2004) ........................................................................... 16
`In re Mouttet,
`686 F.3d 1322 (Fed. Cir. 2012) .......................................................................... 24
`PalTalk Holdings, Inc. v. Microsoft Corp.,
`C.A. 2:06-cv-367-DF, Dkt. 55 ............................................................................ 17
`PalTalk Holdings, Inc. v. Riot Games, Inc.,
`C.A. 1:16-cv-1240-JFB-SRF, Dkt. 59, 64, 67, 69 .............................................. 12
`PalTalk Holdings, Inc. v. Sony Comput. Ent. Inc.,
`C.A. 2:09-cv-274-DF, Dkt. 209 (E.D. Tex. Oct. 25, 2010) ................................ 17
`iii
`
`

`

`IPR2018-00132 (U.S. Pat. No. 6,226,686)
`
`Petitioners’ Reply
`
`Phillips v. AWH Corp.,
`415 F.3d 1303 (Fed. Cir. 2005) .................................................................... 13, 16
`Thorner v. Sony Comput. Entm’t Am. LLC,
`669 F.3d 1362 (Fed. Cir. 2012) .......................................................................... 21
`Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc.,
`200 F.3d 795 (Fed. Cir. 1999) ............................................................................ 12
`
`iv
`
`

`

`IPR2018-00132 (U.S. Pat. No. 6,226,686)
`
`Petitioners’ Reply
`
`I.
`
`Introduction
`
`PalTalk does not dispute that the combination of Aldred and RFC 1692
`
`satisfies the literal language of almost every claim. Instead, PalTalk misreads the
`
`references and the Petition’s grounds to manufacture disputes, asserting self-
`
`serving limitations contrary to the patents’ disclosures and decades of
`
`representations in litigation. Because PalTalk’s Response (Paper 22, “Resp.”) fails
`
`to overcome the arguments and substantial evidence in the Petition (Paper 1,
`
`“Pet.”) demonstrating the unpatentability of claims 1, 3, 7, 12, 18, 22-27, 36, 41-
`
`46, 55, and 58-63 of the ’686 patent, the Board should cancel the challenged
`
`claims.
`
`PalTalk advances two main arguments with respect to the challenged
`
`independent claims. First, PalTalk asserts that RFC 1692’s TMux protocol “could
`
`disrupt the required order of the serialisation operation” in Aldred. Resp. 18-28.
`
`But RFC 1692, Aldred, and the TCP protocol (which Aldred discloses using) all
`
`maintain the order of packets. Patent Owner’s other obviousness arguments
`
`likewise ignore the prior art’s express teachings and impermissibly treat a skilled
`
`artisan as an automaton. Resp. 29-32.
`
`Second, PalTalk advances constructions of “aggregated payload” and
`
`“aggregated message”/“server message” that ignore the plain language of the
`
`claims, the specification, and the testimony of its own expert. Resp. 4-15, 33-50.
`
`1
`
`

`

`IPR2018-00132 (U.S. Pat. No. 6,226,686)
`
`Petitioners’ Reply
`
`The claims require “aggregating said payload[s],” and the record shows that
`
`message headers, including transport headers, may be included in such
`
`“payload[s].” There is no basis to limit “aggregati[on]” to scenarios where
`
`specific “headers” are removed from messages. And in any event, the prior art
`
`identified by Petitioners removes those very headers.
`
`PalTalk’s arguments with respect to the dependent claims fare no better and
`
`are based on a misreading of the Petition and prior art. For the reasons explained
`
`in the Petition and below, every challenged claim should be cancelled.
`
`II. The Challenged Claims are Unpatentable
`
`A. The Combination of Aldred and RFC 1692 was Obvious
`
`An Ordinary Artisan would have found it obvious to extend Aldred’s use of
`
`TCP/IP for inter-node data transfer to use RFC 1692’s TMux functionality. Pet.
`
`33-38. PalTalk argues against the viability of this combination based on a number
`
`of assumptions: (i) that RFC 1692 reorders large and small TCP segments; (ii) that
`
`“reordering” TCP segments would interrupt Aldred’s serialization; (iii) that Aldred
`
`necessarily requires the use of large packets; and (iv) that an Ordinary Artisan
`
`would ignore RFC 1692’s benefits in favor Aldred’s “alternative bandwidth
`
`solutions.” Resp. 18-31. As explained below, none of these assumptions are
`
`supported by the record.
`
`2
`
`

`

`IPR2018-00132 (U.S. Pat. No. 6,226,686)
`
`Petitioners’ Reply
`
`i.
`
`RFC 1692 Does Not Reorder TCP Segments
`
`PalTalk argues that, in RFC 1692, “large” TCP segments could be
`
`transmitted “out of order” with respect to a pending multiplexed packet (containing
`
`“small” TCP segments), thereby violating Aldred’s “order” requirement. Resp. 18-
`
`28. But, as explained below, RFC 1692 expressly discloses that large TCP
`
`segments can be added to the end of any pending multiplexed packet, such that all
`
`segments would be sent in the order received.
`
`PalTalk asserts that “large” segments (such as those sent using FTP) in RFC
`
`1692 “would be transmitted immediately in a separate IP datagram before the
`
`TMuxed message under construction” is sent. Resp. 25-26; Ex.2002, ¶¶68-75.
`
`However RFC 1692 merely suggests sending large segments separately. Ex.1010,
`
`7. If following that suggestion would have imperiled the functionality of the
`
`combination of Aldred and RFC 1692, an Ordinary Artisan would have known to
`
`disregard that suggestion in a combined implementation. Ex.1053, ¶¶19-23, 35.
`
`In fact, the very next page of RFC 1692 describes such a scenario. In
`
`Section 5.2, RFC 1692 explains that when a segment that would not normally be
`
`multiplexed—such as a large segment—is received and a multiplexed message is
`
`under construction, “the extra segment can be added to the TMux message under
`
`construction, and this complete message should be sent immediately ….”
`
`Ex.1010, 8-9 (emphasis added). This disclosure specifically relates this
`
`3
`
`

`

`IPR2018-00132 (U.S. Pat. No. 6,226,686)
`
`Petitioners’ Reply
`
`functionality to the “large” segments identified by PalTalk (“segments sent by
`
`FTP,” id.), and works analogously to TMux’s operation when sufficient data to fill
`
`a multiplexed message is received: “If, during construction of the Multiplexed
`
`Message, the buffer holding the message fills, the Multiplexed Message is
`
`transmitted immediately.” Ex.1010, 6; Ex.1053, ¶¶19-23. RFC 1692 therefore
`
`teaches exactly what PalTalk claims it does not: large and small TCP segments can
`
`be sent in-order by the multiplexing process. Ex.1053, ¶¶19-23. Neither PalTalk
`
`nor its expert acknowledge, let alone address, this disclosure.
`
`Dr. Almeroth further ignores the express disclosures of RFC 1692 in arguing
`
`that this reference “does not discuss the order of packets to be TMuxed as being a
`
`concern.” Ex.2002, ¶68. But RFC 1692 discusses adding segments to a
`
`multiplexed message in the order they are received (Ex.1010, 6-7)2 and also
`
`recommends “that the segments in the TMux message should be processed in the
`
`same order that they are in the TMux message” (id., 3 (emphasis added)). Having
`
`repeatedly ignored its disclosures, Dr. Almeroth’s characterizations of RFC 1692
`
`are not credible. Absent PalTalk’s assumption that RFC 1692 reorders large and
`
`small TCP segments, PalTalk cannot show that concerns about in-order packet
`
`delivery would deter the Ordinary Artisan from combining RFC 1692 with Aldred.
`
`
`
`2 Patent Owner does not contest that the “small” segments are sent in order.
`
`4
`
`

`

`IPR2018-00132 (U.S. Pat. No. 6,226,686)
`
`Petitioners’ Reply
`
`ii.
`
`Aldred Maintains the Order of Serialized Updates
`
`Even if PalTalk’s first assumption was correct—that RFC 1692 might re-
`
`order some “large” TCP segments relative to “small” TCP segments—PalTalk’s
`
`arguments remain premised on another incorrect assumption: that out-of-order
`
`TCP segments would go uncorrected by the combined system. Resp. 18-28. But
`
`Aldred’s scheme maintains the order of serialized updates regardless of the order
`
`of IP packets transmitted by RFC 1692 through both Aldred’s channel mechanism
`
`and the use of TCP, as explained below.
`
`Aldred’s channel mechanism maintains the order of updates within a
`
`channel regardless of the underlying layers. Ex.1053, ¶25. Channels are designed
`
`so that a node “receives data packets from the channel in the order in which they
`
`were sent,” regardless of the “physical communication network in existence
`
`between the nodes.” Ex.1009, 6, 29-30. Aldred’s channels therefore maintain the
`
`order of data packets within a given channel. Ex.1009, 6, 51. As Dr. White
`
`explains, “Aldred provides an order guarantee at the logical channel level,
`
`regardless of the underlying networking scheme.” Ex.1053, ¶25. PalTalk argues
`
`that transmitting TCP segments out-of-order would break this functionality, but
`
`fails to address Aldred’s disclosure that order is maintained regardless of the
`
`physical network’s implementation. Resp. 21-28; Ex.2002, ¶¶73-79.
`
`5
`
`

`

`IPR2018-00132 (U.S. Pat. No. 6,226,686)
`
`Petitioners’ Reply
`
`Aldred’s use of TCP also maintains the order of serialized updates. Aldred
`
`supports TCP/IP, and RFC 1692 is an extension of IP that expressly applies to
`
`TCP/IP. Ex.1009, 29-30, Fig.10; Ex.1010, 4-8, 10; Ex.1007, ¶¶143-48. The
`
`Petition demonstrated that it would be obvious to extend Aldred’s use of TCP/IP to
`
`apply RFC 1692 at the IP layer. Pet. 33-38. TCP is “a connection-oriented, end-
`
`to-end reliable protocol” that provides a mechanism for recovering “from data that
`
`is … delivered out of order by the internet communication system” in the form of
`
`“assigning a sequence number to each octet transmitted.” Ex.1051, 1, 4. These
`
`sequence numbers are used “to correctly order segments that may be received out
`
`of order.” Id., 4, 24-30 (emphasis added). Aldred’s use of TCP/IP would thus
`
`guarantee in-order delivery of TCP segments regardless of any purported
`
`reordering by RFC 1692’s TMux-enhanced IP layer. Ex.1053, ¶¶28-31.
`
`PalTalk and its expert never address TCP’s order guarantee, despite the ’686
`
`patent’s express disclosure that “TCP … ensures reliable, in-order delivery.”
`
`Ex.1002, 3:45-56 (citing RFC 793 (Ex.1051)). Dr. Almeroth agreed that TCP re-
`
`orders out-of-order segments upon receipt. Ex.1052, 11:4-13, 43:7-44:13.
`
`Therefore, Aldred and RFC 1692 maintain the correct ordering of packets at every
`
`layer of the combined system: (1) Aldred maintains the order of data packets
`
`within a logical channel, (2) TCP maintains the order of TCP segments using
`
`6
`
`

`

`IPR2018-00132 (U.S. Pat. No. 6,226,686)
`
`Petitioners’ Reply
`
`sequence numbers,3 and (3) RFC 1692’s TMux-enhanced IP protocol never
`
`reorders small and large TCP segments during the multiplexing process. As
`
`combined, TMux would not interfere with Aldred’s “order” requirement.
`
`iii.
`
`Aldred Does Not Require the Use of Large Packets
`
`Even if PalTalk’s second assumption was also correct—out-of-order TCP
`
`segments are uncorrected by the combined system—PalTalk further unjustifiably
`
`assumes that every embodiment of Aldred would require the use of “large” TCP
`
`segments. Resp. 18-28.
`
`However, neither the challenged claims nor Aldred require “large” packets;
`
`both encompass scenarios where only small packets are generated. Ex.1007, ¶146;
`
`Ex.2004, 43:15-25; Ex.1053, ¶¶26-27. As one example, PalTalk fails to address
`
`Aldred’s support of a “broad spectrum of collaborative applications” (Ex.1009, 1-
`
`2), including a shared drawing board application (id., 7), and a chat program where
`
`
`
`3 TCP ensures that packets arrive at Aldred’s “receiving ports” in an identical
`
`sequence. Ex.1051, 9-10. Aldred’s “ports” are the “ends of channels” and need
`
`not correspond to a specific network implementation (e.g., TCP ports). Id., 7.
`
`Even assuming that segments were received “out of order” at the network (TCP)
`
`level of a node, TCP’s ordering mechanism would ensure in-order delivery at
`
`Aldred’s ports (the channel level). Ex.1053, ¶30.
`
`7
`
`

`

`IPR2018-00132 (U.S. Pat. No. 6,226,686)
`
`Petitioners’ Reply
`
`“each participant sees all the exchanged messages, and in the same sequence” (id.,
`
`27-28). These applications “would result in messages significantly smaller than
`
`the IP protocol supports, such that RFC 1692’s methodology would improve
`
`Aldred’s performance by reducing the number of packets.” Ex.1007, ¶146;
`
`Ex.2004, 43:15-25 (“The particular systems that I analyzed have short packets
`
`….”).
`
`PalTalk’s only rebuttal is to construct a hypothetical system that “could
`
`involve interactive notation on a foreground plane,” where “if [an] application
`
`attaches an image from its local clipboard onto its drawing plane,” then “[i]n many
`
`situations the packet … could be deemed a large packet,” causing “a disruption in
`
`the packet order.” Resp. 26-27 (emphasis added). However, prior art references
`
`“must be evaluated for what they fairly teach one of ordinary skill in the art.” In re
`
`Boe, 355, F.2d 961, 965 (CCPA 1968). PalTalk’s “large” packet scenario does not
`
`show nonobviousness when the claims and Aldred’s disclosure encompass systems
`
`that use only small packets. Apple Inc. v. VirnetX Inc., IPR2014-00237, Paper 41
`
`at 40 (PTAB May 11, 2015) (teaching away must be “commensurate in scope with
`
`the challenged claims”).
`
`iv.
`
`The Techniques of Aldred and RFC 1692 are Complementary
`
`Finally, PalTalk argues that an Ordinary Artisan would not have turned to
`
`RFC 1692 because Aldred “already discusses alternative bandwidth solutions” and
`
`8
`
`

`

`IPR2018-00132 (U.S. Pat. No. 6,226,686)
`
`Petitioners’ Reply
`
`adding TMux “would introduce additional latency into the system.” Resp. 18-19,
`
`29-30. But the techniques proposed by RFC 1692 were complementary to the
`
`techniques discussed in Aldred, providing ample reason for an Ordinary Artisan to
`
`use them together.
`
`Aldred’s disclosure of “alternative bandwidth solutions” does not constitute
`
`a “teaching away” because disclosing an alternative, without more, does not
`
`criticize, discredit, or otherwise discourage the use of another. See In re
`
`Fulton, 391 F.3d 1195, 1200-01 (Fed. Cir. 2004). In fact, Aldred actually
`
`encourages multiplexing at lower layers—the very technique to which RFC 1692
`
`is directed. Ex.1009, 32.
`
`Moreover, each of Aldred’s “bandwidth” techniques—degrading video
`
`quality, compressing data, or dynamically re-allocating bandwidth across
`
`channels—are complementary with TMux. Ex.1053, ¶33. As Dr. White
`
`explained, when there is a high-volume of small packets and high data redundancy,
`
`TMux and compression are “both obvious things to do” and “[y]ou can use them
`
`both at the same time. They’re not exclusive.” Ex.2004, 54:21-55:20; see Ex.1053,
`
`¶33.
`
`Furthermore, PalTalk’s latency and quality of service arguments (Resp. 30-
`
`31) ignore that “[a] person of ordinary skill is also a person of ordinary creativity,
`
`not an automaton.” KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 419 (2007). Both
`
`9
`
`

`

`IPR2018-00132 (U.S. Pat. No. 6,226,686)
`
`Petitioners’ Reply
`
`Aldred’s quality of service (QOS) requirements and RFC 1692’s timer are
`
`configurable (Ex.1009, 39-41; Ex.1010, 6), and RFC 1692 even suggests setting
`
`the user-configurable timer small enough so that the “response time” does not
`
`become a “problem.” Ex.1010, 6; Ex.1053, ¶36. An Ordinary Artisan would
`
`know how to configure the combination to avoid the complications PalTalk
`
`identifies, e.g., setting the timer short enough that it does not interfere with
`
`Aldred’s QOS requirements. Ex.1053, ¶¶35-36. And, any increased latency from
`
`RFC 1692’s timer can also be offset by reduced latency from network congestion:
`
`“[T]here’s an engineering tradeoff going on here between tolerating a little bit of
`
`latency and using up the network bandwidth. … [I]f you have a whole lot of
`
`packets going on the network bandwidth, that can also adversely affect latency.”
`
`Ex.2004, 50:23-51:10; In re Fulton, 391 F.3d at 1200-01 (“[Obviousness] does not
`
`require that a particular combination must be the preferred, or the most desirable,
`
`combination....”). PalTalk and Dr. Almeroth offer no response to this testimony.
`
`Moreover, obviousness requires only a showing “that a skilled artisan would
`
`have been motivated to combine the teachings of the prior art references to achieve
`
`the claimed invention, and that the skilled artisan would have had a reasonable
`
`expectation of success from doing so.” Bristol-Myers Squibb Co. v. Teva Pharms.
`
`USA, Inc., 752 F.3d 967, 973 (Fed. Cir. 2014). A “reasonable expectation of
`
`success” does not require “absolute certainty” that a combination would succeed.
`
`10
`
`

`

`IPR2018-00132 (U.S. Pat. No. 6,226,686)
`
`Petitioners’ Reply
`
`In re Kubin, 561 F.3d 1351, 1360 (Fed. Cir. 2009). Dr. Almeroth’s testimony
`
`reveals that he did not consider the level of ordinary skill when opining on this
`
`issue; this undermines his testimony. For example, after explaining the various
`
`ways that he could tune RFC 1692’s configurable timer, he stated that he was “not
`
`sure a person of skill in the art at the time would have had the same appreciation
`
`….” Ex.1052, 53:11-54:23, 56:3-59:8; but see id., 63:5-64:10 (Dr. Almeroth
`
`teaches network configuration to his undergrads), Resp., 3 n.1 (Ordinary Artisan
`
`would know network protocols and network programming). An Ordinary Artisan
`
`would have been more than capable of configuring Aldred and RFC 1692 to
`
`maintain QOS requirements. Ex.1053, ¶¶35-36. Dr. Almeroth’s uncertainty
`
`regarding what one of skill in the art would have known shows he has not properly
`
`considered obviousness from the perspective of a skilled artisan, making his
`
`testimony on this point unreliable and deserving of little to no weight. See KSR,
`
`550 U.S. at 420 (“The question is … whether the combination was obvious to a
`
`person with ordinary skill in the art.”).
`
`11
`
`

`

`IPR2018-00132 (U.S. Pat. No. 6,226,686)
`
`Petitioners’ Reply
`
`B. Aldred and RFC 1692 Disclose the Claimed “Aggregated
`Message,” “Server Message,” and “Aggregated Payload” (All
`Claims)
`
`PalTalk advances arguments premised on impermissibly narrow
`
`constructions of “aggregated message”/“server message”4 and “aggregated
`
`payload” (related to its “transport layer” header requirements) that the Board
`
`already rejected. Resp. 4-15, 33-50.5 The Board should reject those arguments
`
`again because they are contrary to the claims’ ordinary meaning.
`
`
`
`4 PalTalk’s analysis equates claim 18’s “server message” with the “aggregated
`
`message” used in the remaining independent claims. Resp. 2-3 (“‘aggregated
`
`message’ … referred to a server message in Claim 18 …”).
`
`5 The parties dispute other portions of Patent Owner’s proposed constructions of
`
`these terms in district court. See PalTalk Holdings, Inc. v. Riot Games, Inc., C.A.
`
`1:16-cv-1240-JFB-SRF, Dkt. 59, 64, 67, 69. Here, as Patent Owner’s patentability
`
`arguments rely only on its “transport layer” header requirements, Petitioners
`
`respectfully request the Board determine only whether, and to what extent, the
`
`claims include Patent Owner’s “transport layer” header requirements. See Vivid
`
`Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999).
`
`12
`
`

`

`IPR2018-00132 (U.S. Pat. No. 6,226,686)
`
`Petitioners’ Reply
`
`i.
`
`There is No Basis for PalTalk’s “Transport Layer” Header
`Requirement
`
`Claims 1, 3, 7, 12, and 18 of the ’686 patent do not limit the content of
`
`“payloads,” and thus does not limit what “aggregated payload” and “aggregated
`
`message”/“server message” can comprise. PalTalk concedes that “aggregated
`
`payload” and “aggregated message”/“server message” can encompass
`
`encapsulated headers generally (Resp. 8-9), yet fails to justify why the claim
`
`requires the “aggregated payload” and “aggregated message”/“server message”
`
`exclude all or all but one of a specific type of header.
`
`The ordinary meaning of these terms is readily apparent from the context in
`
`which they appear, Phillips v. AWH Corp., 415 F.3d 1303, 1314 (Fed. Cir. 2005),
`
`and this context does not require excluding any headers. Claims 1, 3, 7, 12, and 18
`
`separately recites “aggregating,” “message,” and “payload,” and PalTalk do not
`
`suggest that those terms require construction. Ex.1052, 68:20-25, 70:5-18, 107:5-
`
`108:7. There is no dispute that the claimed “aggregated payload” is the result of
`
`“aggregating said payload portions of said [host] messages”/“aggregating said
`
`payload portion with the payload portion of a second host message” (Ex.1053,
`
`¶¶12-14), or that the claimed “aggregated message”/“server message” is the result
`
`of forming a message “using said [aggregated payload]” (id., ¶¶12-14). Thus, the
`
`terms “message” and “payload” are used by the ’686 patent in their conventional
`
`sense. Ex.1053, ¶¶5-6; Ex.1002, 1:28-55, 3:57-4:17. PalTalk’s district court
`13
`
`

`

`IPR2018-00132 (U.S. Pat. No. 6,226,686)
`
`Petitioners’ Reply
`
`construction of “aggregating/aggregated” likewise includes no “transport layer”
`
`header requirement. Ex.1055, 2-3. The claims provide sufficient guidance on the
`
`meaning of “aggregated payload” and “aggregated message”/“server message.”
`
`They do not support excluding any “transport layer” headers.
`
`The specification supports this reading of the claims as well. The ’686
`
`patent explains the Internet Protocol (IP) and conventional networking use the OSI
`
`reference model, where network protocols are layered. Ex.1002, 3:28-56 (citing
`
`RFC 791). OSI network layers are hierarchical—the packet for each layer
`
`(containing a header and payload) encapsulates the packets for the layers above:
`
`thus, an IP packet payload may contain an entire TCP packet including a TCP
`
`header and payload. This is shown below in two figures annotated by Dr.
`
`Almeroth in testimony from different proceedings. E.g., Ex.1011 (RFC 791), 1
`
`(“[The IP module could] take a TCP segment (including the TCP header and user
`
`data) as the data portion of an [IP datagram].”).
`
`14
`
`

`

`IPR2018-00132 (U.S. Pat. No. 6,226,686)
`
`Petitioners’ Reply
`
`Ex.1056, 5.
`
`
`
`
`
`Ex.1058, 3. The “payload portion” of an IP packet could thus comprise a TCP
`
`header, and an “aggregated payload” and “aggregated message”/“server message”
`
`could have multiple TCP headers. Ex.1053, ¶¶7-8.
`
`15
`
`

`

`IPR2018-00132 (U.S. Pat. No. 6,226,686)
`
`Petitioners’ Reply
`
`Moreover, PalTalk bases its “transport layer” header limitation on nothing
`
`more than an embodiment in the ’686 patent (Ex.1002, 20:21-25), where the server
`
`removes Transport Level Protocol (TLP) headers from received messages. Resp.
`
`4-11, 13-14. But even if a patent discloses only a single embodiment, the claims
`
`of the patent are not “construed as being limited to that embodiment.” Phillips,
`
`415 F.3d at 1323 (citation omitted). The focus is instead “on understanding how a
`
`person of ordinary skill in the art would understand the claim terms” in light of the
`
`specification. Id. at 1323. Notably, Patent Owner points to no “special definition”
`
`or lexicography that would redefine “aggregated payload” and “aggregated
`
`message”/“server message” from their ordinary meaning as described above. Id. at
`
`1316.
`
`The doctrine of claim differentiation also undercuts PalTalk’s position. See
`
`Liebel-Flarsheim Co. v. Medrad, Inc., 358 F. 3d 898, 910 (Fed. Cir. 2004). Claims
`
`1, 3, 7, 12, and 18 do not expressly recite “aggregating” at any specific “layer,”
`
`but certain dependent claims recite specific “layers” with respect to their
`
`requirements. E.g., claim 14 (“session layer protocol”); claims 28, 29, 48, 47, 64,
`
`65 (“upper-level protocol … transport layer protocol”). These dependent claims
`
`show PalTalk knew how to draft claims requiring operations at specific “layers”
`
`when it wanted to, and it failed to do so with respect to the claimed “aggregating.”
`
`16
`
`

`

`IPR2018-00132 (U.S. Pat. No. 6,226,686)
`
`Petitioners’ Reply
`
`Finally, PalTalk’s position is further undercut by the broader constructions it
`
`proposed, over more than a decade, in district courts and during reexamination—
`
`PalTalk never advanced a “transport layer message header” requirement until after
`
`these proceedings were filed. E.g., PalTalk Holdings, Inc. v. Sony Comput. Ent.
`
`Inc., C.A. 2:09-cv-274-DF, Dkt. 209, at 17 (E.D. Tex. Oct. 25, 2010); PalTalk
`
`Holdings, Inc. v. Microsoft Corp., C.A. 2:06-cv-367-DF, Dkt. 55, Ex. A at 7 (E.D.
`
`Tex. May 14, 2007); Ex.1005, 396-97; Ex.1006, 234-36; Ex.1052, 108:8-24. In
`
`fact, PalTalk proposed constructions of these terms without any limitation as to
`
`“headers” as late as January 30, 2018, only two and a half weeks before it filed its
`
`preliminary response on February 15, 2018. Ex.1054, Ex. A at 1, 3. Shortly after
`
`filing its preliminary responses, it changed its district court positions to follow suit.
`
`Ex.1055, 2-4. PalTalk offers no explanation for its reversal.
`
`The Board should reject PalTalk’s self-serving “transport layer” header
`
`limitations. PalTalk does not contest that Aldred as combined with RFC 1692
`
`would disclose an “aggregated message” and an “aggregated payload” without the
`
`“transport layer” header requirement. Resp. 42-47. Thus, without these
`
`requirements, PalTalk concedes that the combination of Aldred and RFC 1692
`
`satisfies each and every element of claims 1, 3, 7, 12, and 18. Id.
`
`17
`
`

`

`IPR2018-00132 (U.S. Pat. No. 6,226,686)
`
`Petitioners’ Reply
`
`ii.
`
`The ’686 Patent’s Transport Level Protocol Disclosure Cannot
`Support a “Transport Layer” Requirement
`
`Even assuming arguendo that the claims require removing headers, only
`
`Transport Level Protocol (TLP) headers would need to be removed, not “transport
`
`layer” headers. Ex.1002, 20:22-23 (“GMS … removes the TLP header from the
`
`datagram … .”). This distinction is critical, because RFC 1692 removes, as part of
`
`its multiplexing process, the headers that the patent characterizes as TLP headers.
`
`The ’686 patent explains that TLP and transport layer protocol are not
`
`synonymous. PalTalk attempts to equate these terms, but Transport Level Protocol
`
`(TLP) is a coined term that does not directly correspond to “transport layer.”
`
`Ex.1002, 8:38-43, 12:46-50; Ex.1052, 79:21-80:15 (Dr. Almeroth: “the patent can
`
`characterize a TLP in any way it wants”).
`
`Only two embodiments in the patent discuss TLP; in neither is TLP a
`
`transport layer protocol. In the first embodiment, the specification explains that
`
`the TLP is IP: “As before, a TLP such as IP (where the message header contain[s]
`
`the source and destination TLP addresses) is assumed to be used here.” Ex.1002,
`
`9:10-12 (emphasis added); Ex.1052, 79:21-80:15 (Dr. Almeroth agreeing that IP is
`
`an example of a TLP). Dr. Almeroth testified that IP is not a transport layer
`
`protocol. Ex.1052, 79:16-20. In the second embodiment, the specification
`
`suggests that the TLP is TCP and IP together: “In the preferred embodiment, the
`
`wide area network is the Internet and the TLP protocol is TCP/IP.” Ex.1002,
`18
`
`

`

`IPR2018-00132 (U.S. Pat. No. 6,226,686)
`
`Petitioners’ Reply
`
`26:28-29 (emphasis added). Here, the ’686 patent refers to a “TCP/IP header” as a
`
`single header. Id., 26:41-43.
`
`These disclosures are fatal to PalTalk’s argument because it means every
`
`example in the ’686 patent that describes removing a TLP header encompasses
`
`removing the IP header alone. Thus, even if the claims are limited to removing a
`
`single TLP header, such a negative limitation would not distinguish the prior art.
`
`As explained in the Petition and by Dr. White, Aldred in view of RFC 1692 results
`
`in an “aggregated payload” without any IP headers and an “aggregated message”
`
`with a single IP header. Pet. 34-38; Ex.1007, ¶¶68-76, 143; Ex.1053, ¶34. The
`
`’686 patent’s disclosure of IP as the TLP protocol means that RFC 1692 discloses
`
`precisely the same functionality: removing incoming IP headers and sending
`
`aggregated messages with only a single IP header.
`
`In the second embodiment, disclosing a TLP that is the combined TCP
`
`header and IP header, Aldred in view of RFC 1692 would similarly result in at
`
`most a single combined TCP header and IP header in the multiplexed packet: the
`
`single IP header and the first TCP header. Ex.1010, 2-3, 6-8; Ex.1053, ¶34. The
`
`remaining TCP headers would not be TLP headers b