`
`
`
`
`
`
`
`
`
`Paper No. 31
`
`
`
`
`
`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 IPR2018-00131
`Patent 6,226,686 & 6,226,686 C1
`_______________
`
`
`PATENT OWNER’S SUR-REPLY TO PETITIONERS’ REPLY
`
`
`
`
`
`IPR2018-00131
`
`TABLE OF CONTENTS
`
`
`I.
`
`ORDERING REQUIREMENT OF ALDRED ...........................................................................1
`A. PETITIONERS’ NEW ARGUMENTS SHOULD BE GIVEN NO WEIGHT ............................................1
`B. TCP IS NOT REQUIRED IN ALDRED OR RFC 1692 ......................................................................2
`C. RFC 1692 WILL TRANSMIT OUT OF ORDER PACKETS ................................................................3
`D. PETITIONERS’ OTHER ARGUMENTS ARE DEFICIENT ...................................................................5
`II.
`“AGGREGATED MESSAGE” AND “AGGREGATED PAYLOAD” ....................................5
`A. THE CONSTRUCTIONS DO NOT EXCLUDE “ALL BUT ONE HEADER TYPE” ................................6
`B. TLP HEADER .................................................................................................................................7
`
`
`ii
`
`
`
`IPR2018-00131
`
`UPDATED PATENT OWNER EXHIBIT LIST
`
`Exhibit 2001:
`Exhibit 2002:
`Exhibit 2003:
`Exhibit 2004:
`Exhibit 2005:
`
`
`Declaration of Nancy Miracle
`Declaration of Dr. Kevin C. Almeroth
`Curriculum Vitae of Dr. Kevin C. Almeroth
`Transcript of July 24, 2018 Deposition of Dr. Steve White
`Transcript of December 19, 2018 Deposition of Dr. Steve
`White
`
`
`
`
`
`
`
`
`iii
`
`
`
`IPR2018-00131
`
`I.
`
`ORDERING REQUIREMENT OF ALDRED
`
`A. Petitioners’ New Arguments Should Be Given No Weight
`
`Petitioners incorrectly state that Patent Owner’s Response argued that RFC
`
`1692 would reorder “TCP segments,” and Petitioners refer to “TCP segments”
`
`throughout the Reply. Reply, 2, 3-11. However, Patent Owner and its expert never
`
`asserted Aldred or RFC 1692 require “TCP segments” or using the TCP protocol,
`
`never asserted RFC 1692 reorders “TCP segments,” and never referred to packets
`
`as “TCP segments.” See PO Resp. 15-32; Ex. 2002, ¶¶ 66-85 (describing
`
`combining Aldred and RFC 1692 disrupts the order of “packets”).
`
`The Reply now essentially asserts a combination of Aldred, RFC 1692, and
`
`the TCP protocol, which was not properly presented in the Petition. See Pet., 33-
`
`34; see also Reply, 2 (“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.”); see also Ex. 2005, 144:5-7 (“Aldred based on TCP/IP, with the
`
`TMux extensions to IP, is the combination that we’ve considered.”). Petitioners
`
`mischaracterize the statements in the Response and introduce new arguments in the
`
`Reply that limit with no underlying rationale the combination of Aldred and RFC
`
`1692 to transmitting TCP segments. Petitioners’ new arguments are not directed to
`
`the specific issues in the Response, and should be given no weight.
`
`1
`
`
`
`IPR2018-00131
`
`B. TCP Is Not Required In Aldred or RFC 1692
`
`Even if Petitioners’ new arguments are considered, they still fail. Petitioners
`
`argue RFC 1692 would not reorder “TCP segments” because the TCP protocol
`
`assigns sequence numbers to transmitted data to order and ensure reliability of
`
`data. Reply, 6-7; Ex. 1051, 4. As described above, Patent Owner never argued
`
`“TCP segments” would be sent out of order if Aldred and RFC 1692 are
`
`combined, but argued the order of “packets” would be disrupted. PO Resp. 15-32.
`
`Aldred, nor RFC 1692, require the use of the TCP protocol or TCP segments, and
`
`in fact strive to be over-inclusive of other standards and protocols. See Ex. 1009,
`
`30 (“The support system architecture is designed to permit inter-working between
`
`different computer platforms, operate over varied communications networks, and
`
`support relevant communication and data standards.”); see also Ex. 1010, 8
`
`(illustrating non-TCP segments such as UDP segments can be multiplexed).
`
`Further, TCP segments a datastream into packets having no relation to the
`
`message, Ex. 2005 106:4-7 (“TCP doesn't have any knowledge of how the
`
`application uses the data stream, it only has knowledge of what bits it's presented
`
`with in order to transmit.”). Petitioners thus provide no support for “aggregating
`
`payload portions … to create an aggregated message.”
`
`The Reply requires the combination of Aldred and RFC 1692 be limited to
`
`using the TCP protocol and transmitting TCP segments, and ignores the flexibility
`
`2
`
`
`
`IPR2018-00131
`
`emphasized in both Aldred and RFC 1692. A POSITA would not have been
`
`motivated to limit the flexibility of Aldred, and would not have been motivated to
`
`combine Aldred and RFC 1692 because of the disruption of packet transmission
`
`order, as described in the Response.
`
`C. RFC 1692 Will Transmit Out of Order Packets
`
`Petitioners argue Aldred discloses serialized channels that maintain the order
`
`of messages regardless of the “physical communication network in existence
`
`between the nodes.” Reply, 5 (quoting Ex. 1009, 6). The portion of Aldred quoted
`
`by Petitioners does not state order is maintained “regardless” of the physical
`
`communication network, but actually states “[t]here may be no direct mapping
`
`between the logical channel structure seen by the aware applications and the
`
`physical communication network in existence between the nodes” – i.e., the
`
`application ports in Aldred are connected by separate, logical, channels. Ex. 1009,
`
`6. This is consistent with the disclosure of Aldred describing a logical serialization
`
`queue that orders messages to be transmitted. Id., 51. However, as explained in the
`
`Response, combining RFC 1692 with Aldred would disrupt the order central to
`
`Aldred, as smaller items would be removed from the serialization queue and added
`
`to the TMux buffer, and larger segments would be transmitted immediately. PO
`
`Resp. 15-32.
`
`Petitioners argue Section 5.2 of RFC 1692 discusses adding segments “that
`
`3
`
`
`
`IPR2018-00131
`
`would not normally be multiplexed—such as a large segment” to a TMux message
`
`under construction, and then sending the TMux message. Reply, 3-4. However,
`
`Section 5.2 actually discusses FTP segments as an example of segments that
`
`should not normally be TMuxed, contrasting such FTP segments with segments for
`
`interactive sessions; Section 5.2 makes no specific mention of larger segments. Ex.
`
`1010, 8. Petitioners’ expert, Dr. White, even admits Section 5.2 is limited to
`
`TMuxing segments that are “small enough to fit in the buffer.” Ex. 2005, 63:21-23.
`
`RFC 1692 describes placing messages to be TMuxed in a buffer. Ex. 1010,
`
`6. When a timer expires or when the buffer holding the TMux message under
`
`construction fills, the multiplexed message is transmitted. Id. For “segments that
`
`are larger than the maximum allowed for TMux . . . individual IP datagrams should
`
`be sent,” and larger segments should not be multiplexed to avoid delaying the
`
`transmission of larger segments by the TMux timer. Id., 4, 7. RFC 1692 discloses
`
`sending a TMux message in two situations – when the timer expires or when the
`
`buffer fills. Id., 6. RFC 1692 is clear a larger segment that would overfill the buffer
`
`would not be added to the buffer since the larger segment is not to be multiplexed.
`
`Id., 7. Since the larger segment should not be delayed by the buffer, the larger
`
`segment is transmitted before the TMux message, as the TMux message under
`
`construction must wait for the timer to expire or the buffer to fill before the TMux
`
`message is sent. Petitioners’ analysis of RFC 1692 is therefore incorrect.
`
`4
`
`
`
`IPR2018-00131
`
`D. Petitioners’ Other Arguments Are Deficient
`
`Petitioners argue Aldred encompasses “scenarios where only small packets
`
`are generated,” (Reply, 7), but Petitioners cannot quantify the size (Ex. 2005,
`
`130:18). Dr. White, however, admits Aldred considers systems that can send
`
`“small messages, big messages, or both.” Ex. 1053, ¶ 26. This is consistent with
`
`the Response – that Aldred can send both small and large packets, and RFC 1692
`
`would disrupt the required order. PO Resp. 15-32.
`
`Petitioners argue Aldred “encourages multiplexing at lower layers—the very
`
`technique to which RFC 1692 is directed.” Reply, 9. This statement is taken out of
`
`context. Multiplexing in Aldred refers to the “separation of data traffic,” such that
`
`“voice, video and data traffic . . . can be sent over multiple channels” so that “data
`
`components are presented individually.” Ex. 1009, 30. Therefore, Aldred does not
`
`encourage the same technique to which RFC 1692 is directed – combining multiple
`
`messages into a single message for transmission.
`
`II.
`
`“AGGREGATED MESSAGE” AND “AGGREGATED PAYLOAD”
`
`Both experts agree the terms “aggregated payload” and “aggregated
`
`message” were not commonly known at the time of filing of the ’686 Patent. Ex.
`
`2005, 10:24-11:4; Ex. 2002 ¶ 40. Dr. White admits it is “possible to have two
`
`words combined that have a different technical meaning than the individual
`
`words.” Ex. 2005, 18:12-14. Since both expects agree the combined terms were not
`
`5
`
`
`
`IPR2018-00131
`
`commonly known at the time of filing, then they must be interpreted in the context
`
`of the specification of the ’686 Patent, as provided in the Response. PO Resp., 1-
`
`15.
`
`A. The Constructions Do Not Exclude “All But One Header Type”
`
`Petitioners assert Patent Owner “fails to justify why the claim requires the
`
`‘aggregated payload’ and ‘aggregated message’ exclude all or all but one of a
`
`specific type of header.” Reply, 13. Patent Owner’s construction for “aggregated
`
`message” is “one or more messages containing a single transport layer message
`
`header, destination data, and data items from an aggregated payload,” and the
`
`proposed construction for “aggregated payload” is “a collection of two or more
`
`data items that does not include transport layer headers.” PO Resp., 4-15. Neither
`
`of these constructions exclude all or all but one of a specific type of header; other
`
`types of headers could be included under either construction.
`
`Petitioners’ statements that an “aggregated payload” and an “aggregated
`
`message” could include multiple TCP headers (Reply, 14-16) are not supported by
`
`the specification of the ’686 Patent. Patent Owner’s proposed constructions relate
`
`to transport layer headers and not to TCP headers specifically. See PO Resp., 4-
`
`15. Petitioners further argue the transport layer header limitation is based on
`
`“nothing more than an embodiment in the ’686 Patent.” Reply, 16. Petitioners’
`
`argument ignores the fact that all of the embodiment’s disclosed in the ’686 Patent
`
`6
`
`
`
`IPR2018-00131
`
`describe removing the TLP header from received messages before aggregating the
`
`payloads. Ex. 1001, 20:22-23; 20:54-55; 21:25-26; 22:6-7.
`
`B. TLP Header
`
`Petitioners attempt to characterize TLP as comprising an IP header alone,
`
`which is not accurate. Reply, 18-19. Petitioners refer to the language “[a]s before, a
`
`TLP such as IP (where the message header contain[s] the source and destination
`
`TLP address) is assumed to be used here” and “[i]n the preferred embodiment, the
`
`wide area network is the Internet and the TLP protocol is TCP/IP.” Reply, 18-19;
`
`Ex. 1001, 9:6-8, 26:28-29. The ’686 Patent clearly does not limit TLP headers or
`
`the TLP protocol to IP, but indicates IP is but one example of a TLP header, and
`
`indicates the TLP protocol is TCP/IP. The Reply submits impermissible new
`
`arguments that construe the terms as comprising a single IP or TCP/IP header,
`
`inconsistent with Petitioners’ previously presented position of plain and ordinary
`
`meaning. Pet. 6. Petitioners’ arguments that the proposed constructions exclude the
`
`preferred embodiment of the ’686 Patent are not accurate. Items 117, 118, 120 and
`
`122 comprising the ULP address and Data Length are not transport headers. As
`
`clearly explained in Patent Owner’s Response, the transport header comprises
`
`items 123-128. PO Resp., 4-15. Patent Owner’s proposed constructions should
`
`therefore be adopted.
`
`Dated: December 24, 2018
`
`
`
`
`
`
`
`
`
`
`
`By:
`
`
`/Gregory M. Howison/
`Gregory M. Howison
`
`7
`
`
`
`IPR2018-00131
`
`CERTIFICATE OF SERVICE
`
`Pursuant to 37 C.F.R. § 42.6(e), the undersigned hereby certifies that a true
`and correct copy of the foregoing was served via electronic mail on December 24,
`2018, in its entirety on the following:
`
`Joseph A. Micallef (Lead Counsel)
`Reg. No. 39,772
`SIDLEY AUSTIN LLP
`1501 K Street, N.W.
`Washington, D.C. 20005
`202-736-8492
`Riot_paltalk@sidley.com
`Samuel A. Dillon (Backup Counsel)
`Reg. No. 65,197
`SIDLEY AUSTIN LLP
`1501 K Street, N.W.
`Washington, D.C. 20005
`P: 202-736-8298
`Riot_paltalk@sidley.com
`Reynaldo C. Barcelo (Backup Counsel)
`Reg. No. 42,290
`BARCELO, HARRISON & WALKER, LLP
`2901 West Coast Highway, Suite 200
`Newport Beach, CA 92663
`949-340-9736
`rey@bhiplaw.com
`Kyle Friesen (Backup Counsel)
`Reg. No. 65,371
`SHOOK, HARDY & BACON L.L.P.
`600 Travis St., Suite 3400
`Houston, TX 77002-2926
`713-546-5671
`kfriesen@shb.com
`
`Scott M. Border (Backup Counsel)
`SIDLEY AUSTIN LLP
`1501 K Street, N.W.
`Washington, D.C. 20005
`202-736-8818
`Riot_paltalk@sidley.com
`
`Sharon A. Israel (Backup Counsel)
`Reg. No. 41,867
`SHOOK, HARDY & BACON LLP
`600 Travis St., Suite 3400
`Houston, TX 77002-3400
`713-546-5689
`sisrael@shb.com
`Patrick A. Lujin (Backup Counsel)
`Reg. No. 35,260
`SHOOK, HARDY & BACON L.L.P.
`2555 Grand Blvd.
`Kansas City, Missouri 64108
`816-559-2186
`plujin@shb.com
`
`
`/Gregory M. Howison, Reg. #30646/
`Gregory M. Howison
`Registration No. 30,646
`Lead Counsel for Patent Owner
`
`
`By:
`
`8
`
`