`
`
`
`
`
`
`
`
`
`Paper No. 30
`
`
`
`
`
`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-00132
`Patent 6,226,686 & 6,226,686 C1
`_______________
`
`
`PATENT OWNER’S SUR-REPLY TO PETITIONERS’ REPLY
`
`
`
`
`
`
`IPR2018-00132
`
`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-00132
`
`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-00132
`
`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., 36-
`
`37; 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-00132
`
`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-00132
`
`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-00132
`
`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-00132
`
`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-00132
`
`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-00132
`
`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-00132
`
`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
`
`
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
