SERVER-GROUP
`MESSAGING SYSTEM
`FOR INTERACTIVE
`APPLICATIONS
`
`Riot Games, Inc. and Valve Corp. v. Paltalk
`Holdings, Inc., IPR2018-00129, IPR2018-
`00130, IPR2018-00131, IPR2018-00132
`
`U.S. Patent Nos. 5,822,523 and 6,226,686
`
`Oral Argument – February 13, 2019
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`MESSAGING SYSTEM
`FOR INTERACTIVE
`APPLICATIONS
`
`Riot Games, Inc. and Valve Corp. v. Paltalk
`Holdings, Inc., IPR2018-00129, IPR2018-
`00130, IPR2018-00131, IPR2018-00132
`
`U.S. Patent Nos. 5,822,523 and 6,226,686
`
`Oral Argument – February 13, 2019
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`Introduction
`
`•
`
`Inter Partes Review was instituted for:
`
`•
`
`•
`
`•
`
`•
`
`IPR2018-00129 (523 Patent): Claims 1-10, 16-18, 31-37, 41, 42, and 44-47 as
`unpatentable under 35 U.S.C. § 103 over Aldred (Ex. 1009) and RFC 1692 (Ex.
`1010), Claims 38-40 as unpatentable under 35 U.S.C. § 103 over Aldred, RFC
`1692, and RFC 1459 (Ex. 1025), and Claim 43 as unpatentable under 35 U.S.C. §
`103 over Aldred, RFC 1692, and Denzer (Ex. 1014);
`
`IPR2018-00130 (523 Patent): Claims 1, 15, and 19-27 as unpatentable under 35
`U.S.C. § 103 over Aldred and RFC 1692, and Claims 11-15, 23, and 27-30 as
`unpatentable under 35 U.S.C. § 103 over Aldred, RFC 1692, and Ulrich (Ex.
`1012);
`
`IPR2018-00131 (686 Patent): Claims 1-4, 7-21, 28-30, 34, 35, 39, 40, 47-49, 53,
`54, 56, 57, 64-66, and 70 as unpatentable under 35 U.S.C. § 103 over Aldred and
`RFC 1692, and Claims 31-33, 50-52, and 67-69 as unpatentable under 35 U.S.C.
`§ 103 over Aldred, RFC 1692, and RFC 1459; and
`
`IPR2018-00132 (686 Patent): Claims 1, 3, 7, 12, 18, 26, 27, 45, 46, 62, and 63 as
`unpatentable under 35 U.S.C. § 103 over Aldred and RFC 1692, Claims 22-27,
`41-46, and 58-63 as unpatentable under 35 U.S.C. § 103 over Aldred, RFC 1692,
`and Ulrich, and Claims 36 and 55 as unpatentable under 35 U.S.C. § 103 over
`Aldred, RFC 1692, and Denzer.
`
`2
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`Introduction
`
`•
`
`Issues
`
`1. Petitioner has not sufficiently demonstrated a POSITA would have been
`motivated to combine Aldred (Ex. 1009) and RFC 1692 (Ex. 1010) – because
`such a combination would render Aldred unsatisfactory for its intended
`purpose
`
`2. Claim Construction of “Aggregated Payload” and “Aggregated Message” –
`Claim 1 (523 Patent); Claims 1, 3, 7, 12, and 18 (686 Patent)
`
`For convenience to both the parties and the Board, unless otherwise noted, citations
`used by Patent Owner in these demonstrative exhibits refer to papers filed in
`IPR2018-00129.
`
`3
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`CLAIM CONSTRUCTION
`
`CLAIM CONSTRUCTION
`
`CLAIM CONSTRUCTION
`
`CLAIM CONSTRUCTION
`
`4
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`CLAIM CONSTRUCTION
`
`Patent Owner’s Proposed Claim Construction:
`
`• “Aggregated Message” (“Server Message” in Claim
`18 of 686 Patent)
`•
`“One or more messages containing a single
`transport layer message header, destination
`data, and data items from an aggregated
`payload.” (PO Resp., Paper 22, at 4)
`
`• “Aggregated Payload” (“aggregating said payload
`portions” in Claim 3 of 686 Patent) (“aggregating said
`payload portion with the payload portion of a second
`host message” in Claim 18 of 686 Patent)
`•
`“A collection of two or more data items that does
`not include transport layer headers.” (PO Resp.,
`Paper 22, at 13)
`
`5
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`CLAIM CONSTRUCTION
`
`Petitioner’s Position: Plain and Ordinary Meaning (Petition, 6)
`• Petitioner’s Support:
`a) Prior Litigation of 523 and 686 Patents (Pet. Reply, 16)
`• No Preclusion - Prior claim construction orders were not final
`(Patent Owner Preliminary Sur-Reply, Paper 10, at 1-3;
`Patent Owner )
`b) Expert Testimony:
`• Expert considered previous constructions – no independent
`research of terms in the art (White Dec., Ex. 1007, ¶ 46; PO
`Resp., 2)
`• Expert admits that no search for terms “aggregated
`payload” and aggregated message” in the prior art was
`performed (White Depo 1, Ex. 2004, 22-23; PO Resp.,
`Paper 22, at 2)
`• Expert Admits that he had never seen the terms
`“aggregated payload” and “aggregated message” used in
`the industry (Ex. 2005, 10:24-11:4; PO Sur-Reply, Paper
`30, at 5)
`
`6
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`CLAIM CONSTRUCTION
`
`Petitioner’s Position: Plain and Ordinary Meaning (Petition, 6)
`
`c) Expert Testimony (cont’d):
`• Petitioner considered only independent meaning of words
`(i.e., independent meaning of “aggregated,” “payload,” and
`“message.”) (Pet. Reply, Paper 25, at 13)
`
`• Expert admits that the combined terms “aggregated
`payload” and “aggregated message” could have unique
`technical meaning beyond the individual words. (White
`Depo 2, Ex. 2005, 18:12-14; PO Sur-Reply, Paper 30, at
`5)
`
`7
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`CLAIM CONSTRUCTION
`
`Patent Owners Position:
`
`a) Aggregated Payload/Message were not known in the Art
`• Ex. 2002, p. 16, ¶40; Ex. 2005, p. 10, l. 23 – p. 11, l. 4; Ex.
`5005, p. 11; l. 6-18; Ex. 5005, p. 12; l. 2-7; PO Resp., paper
`22, p. 3
`
`b) A POSITA would need to look to the specification to determine the
`meaning of Aggregated Payload/Message
`• Ex. 2002, p. 16, ¶40, PO Resp., paper 22, p. 3
`
`c) Aggregated Payload/Massage as a combination can have a
`unique meaning
`• EX. 5005, 18:12-14, PO Sur-Reply, paper 30, p. 5
`
`8
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`CLAIM CONSTRUCTION
`
`Almeroth Declaration:
`
`a) With respect to the term “aggregated payload,” and the closely
`related term “aggregated message,” I am not aware of a
`commonly understood meaning for the term “aggregated payload”
`at the time of filing of the ‘523 and ‘686 Patents, and I was not
`personally aware of specific and understood meanings of the
`terms in the industry in 1996. Ex. 2002, p. 16, ¶40; PO
`Response, paper 22, at 2-3
`b) There does not appear to be any indication that a POSITA upon
`hearing these terms would immediately understand what would be
`included in an aggregated payload or and aggregated message.
`Ex. 2002, p. 16-17, ¶40; PO Response, paper 22, at 3
`c) While a POSITA could make and educated guess as to what
`could make up an “aggregated payload” or an “aggregated
`message,” a POSITA would have had to turn to the specific
`disclosure of the ‘523 and ‘686 Patents to determine the exact
`meaning and composition of an “aggregated payload” and an
`“aggregated message,” as defined by the inventors of the ‘523
`and ‘686 Patent. Ex. 2002, p. 16, ¶40; PO Response, paper 22, at
`3
`
`9
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`CLAIM CONSTRUCTION
`
`Petitioner’s Expert
`Never saw the terms “aggregated payload”
`and “aggregated message” used in the
`industry at the time of filing of 523 and 686
`Patents.
`
`Patent Owner’s Expert
`aware
`of
`commonly
`understood
`Not
`meaning for terms “aggregated payload”
`and “aggregated message” in the industry
`at the time of filing of 523 and 686 Patents.
`
`(White Depo 2, Ex. 2005, 10:24-11:4; PO
`Sur-Reply, Paper 30, at 5)
`
`Petitioner considered only independent
`meaning
`of words
`(i.e.,
`independent
`meaning of “aggregated,” “payload,” and
`“message.”) (Pet. Reply, Paper 25, at 13)
`
`Expert admits combined terms “aggregated
`payload” and “aggregated message” could
`have unique technical meaning beyond the
`individual words. (White Depo 2, Ex. 2005,
`18:12-14; PO Sur-Reply, Paper 30, at 5)
`
`(Almeroth Dec., Ex. 2002, ¶ 40; PO Resp.,
`Paper 22, at 2-4; PO Sur-Reply, Paper 30,
`at 5)
`review specification to determine
`Must
`meaning of
`“aggregated payload” and
`aggregated message.”
`
`(Almeroth Dec., Ex. 2002, ¶ 40; PO Resp.,
`Paper 22, at 3; PO Sur-Reply, Paper 30, at
`5-6)
`
`10
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`CLAIM CONSTRUCTION
`
`Patent Owner’s Expert (Dr. Almeroth):
`
`Ex. 2002, p. 16, ¶40; PO Response, paper 22, at 2-3
`
`11
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`CLAIM CONSTRUCTION
`
`Petitioner’s Expert (Dr. White) Statements on Meaning of Aggregated Payload
`and Aggregate Message:
`
`Ex. 2005, p. 10, l. 23 – p. 11, l. 4; PO Sur-Reply, paper 30, at 5
`
`12
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`CLAIM CONSTRUCTION
`
`Petitioner’s Expert (Dr. White) Statements on Meaning of Aggregated Payload
`and Aggregate Message:
`
`EX. 2005, p. 11; l. 6-18; PO Sur-Reply, paper 30, at 5
`
`13
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`CLAIM CONSTRUCTION
`
`Petitioner’s Expert (Dr. White) Statements on Meaning of Aggregated Payload
`and Aggregate Message:
`
`EX. 2005, p. 12; l. 2-7; PO Sur-Reply, paper 30, at 5
`
`14
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`CLAIM CONSTRUCTION
`
`Petitioner’s Expert (Dr. White) Statement on Combined Terms having a
`Different Technical Meaning:
`
`EX. 2005, 18:12-14; PO Sur-Reply, paper 30, at 5
`
`15
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`CLAIM CONSTRUCTION
`
`PO Support for Constructions:
`• Claims recite two-step process of (1) aggregating payload portions
`of messages and (2) forming an aggregated message using said
`aggregated payload (523 Patent, Ex. 1001, Claim 1) (PO Resp.,
`Paper 22, at 6, 8, 37-39)
`
`• Specification explains that transport layer headers are removed
`from each message, payload portions of the messages are
`aggregated to create an aggregated payload, and an aggregated
`message is formed that includes the aggregated payload and a
`single transport layer header. (PO Resp., Paper 22, at 4-15)
`
`16
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`CLAIM CONSTRUCTION
`
`PO Support for Constructions:
`• Structure of
`Aggregated Message
`as disclosed in 523
`and 686 Patents. PO
`Response, paper 22,
`at 7
`
`• Message header
`(including transport
`header 123) (Blue);
`Aggregated Payload
`129 (Green); Payload
`Portions of Aggregated
`Payload (Red). PO
`Response, paper 22,
`at 7
`
`17
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`CLAIM CONSTRUCTION
`
`PO Support for Constructions (Cont’d):
`• Stripping original transport header from message and placing
`payload portion in queue:
`
`•
`
`“The host sends the send message onto the network with TLP
`header addressing the data . . . The GMS receives the
`message and the GMS control function 136 determines that it
`is a send message datagram and looks up the implicit
`destination address in its implicit ULP address list 138 . . . If
`the address is valid, the GMS control function removes the
`TLP header from the datagram and sends the ULP portion to
`the ULP server process corresponding to the destination
`implicit ULP address . . . The ULP server process 140 will
`extract the single payload item from the message 117, 118,
`and 119 and place the payload item in each of the
`message queues 143.” (523 Patent, Ex. 1001, at 20:14-30;
`PO Resp., Paper 22, at 6)
`
`18
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`CLAIM CONSTRUCTION
`
`PO Support for Constructions (Cont’d):
`• Look Up Address of Destination Host to Create new transport
`layer message header for aggregated message:
`
`•
`
`“The GMS control function 136 will use the destination ULP
`host address to look up the TLP address of the host from the
`host address map 137. This will be used to create a TLP
`header for the message 123.” (523 Patent, Ex. 1001, at
`23:20-23; PO Resp., Paper 22, at 10).
`
`19
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`CLAIM CONSTRUCTION
`
`Definition of TLP:
`A header portion consisting of a source
`address (S) a transport layer protocol
`destination address (A, B, C or D) for the
`destination host and a destination upper layer
`protocol (ULP) address (H, I, J or K) for the
`destination host. Ex. 1001, col. 8, col. 9, col. 10,
`Fig. 7.
`
`20
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`CLAIM CONSTRUCTION
`
`CLAIM CONSTRUCTION
`
`LS [A]H [2] P3]Pa|
`
`96
`
`)
`
`HastA Sends
`
`700
`
`HostAReceives
`
`oT s
`Host B Receives
`Host B Sends
`/
`|6|s[cs[P||si}et[errs]pa]
`
`101
`
`Host G Receives
`Host C Sends
`o
`pPi|P2|Pa|
`
`a8
`
`02
`
`99
`
`103
`
`a| a
`Host 0 Receives
`El
`
` PsToTk [Pt[Pe]Ps4
`
`ea
`&P
`
`(Group Server Recerves.
`*Y
`Group Server Sends
`, YaATsTeyr
`wor Ls lalaTeter]
`UETETOT=|
`Ex. 1001, Fig. 7
`
`pee) , pee
`ws [oT
`«
`[Pi
`[2
`[Ps
`Po [Ts [er]
`
`100
`
`96
`
`
`
`
`21
`
`103
`
`so
`
`Ex. 1001, Fig. 7
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`CLAIM CONSTRUCTION
`Specification with Respect to Figure 7:
`
`• Host 58 Sends message 80 which contains the TLP source address A of
`the host and the destination TLP address S for the GMS 62. The
`destination ULP address G is an implicit address handled by the GMS
`and the payload P1 contains both the data to be sent and the sources
`ULP address H of the host. Ex. 1001, Col. 9:8-13
`• Host 60 sends message 81 with payload P2 containing data and source
`ULP address I. Hosts 59 sends message 82 with payload P3 containing
`data and source ULP address J. Host 61 sends message 83 with payload
`P4 containing data and source ULP address K. The GMS receives all of
`the these messages and sees that each message is addressed to implicit
`message group G with members H, I, J and K. Ex. 1001, Col. 9:16-23
`• Each message is destined to a single host and contains an aggregated
`payload with multiple payload items. Message 100 has a destination ULP
`address H for host 58 and aggregated payload P2, P3 and P4 from the
`messages from hosts 59, 60 and 61. Message 101 is targeted at host
`60, message 102 is targeted at host 59 and message 103 is targeted at
`host 61. Ex. 1001, Col. 10:32-38
`
`22
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`CLAIM CONSTRUCTION
`Definition of Message Header:
`The over all structure of an
`aggregated message includes a
`message header (blue), a payload
`(green) and multiple payload
`elements (red). Ex. 1001, 14:37-
`52; PO Response, paper 22, p. 7.
`
`The fields 123, 124, 125, 126, 127
`and 128 constitute the message
`header. Ex. 2002, ¶ 47; PO
`Response, paper 22, at 7.
`
`23
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`CLAIM CONSTRUCTION
`Specification with Respect to Figure 9:
`
`• The general form of the ULP datagram message format is shown in Fig. 9 as
`elements 123, 124, 125, 126, 127, 128 and 129. The transport header 123 is
`the datagram header of the TLP that is encapsulating the ULP datagram.
`The ULP message type field 124 indicates whether it is a send or receive
`message, if it is a control message or a state message. Ex. 1001, Col. 13:62-
`14:2
`• Send messages are always sent from a host to a group messaging server.
`Messages from a group server to the host or always receive messages. Ex.
`1001, Col. 14: 13-15
`• The destination ULP address 125 is required in ULP datagrams and specifies
`the primary destination of the ULP message. The address count field 126 is
`required and ULP send message types and is not present in ULP receive
`message types. When the address count field in a ULP send message is non-
`zero, it specifies the number of auxiliary destination addresses for the send
`message that follows the address count field. These auxiliary destination
`addresses are shown as items 127 and 128, but it is understood that there
`are many auxiliary ULP destination addresses as specified by the address
`count field. Finally there is the payload 129. Ex. 1001, Col. 14:25-36
`
`24
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`CLAIM CONSTRUCTION
`Specification with Respect to Figure 9 (continued):
`
`• The payload format for ULP datagramsis defined by items 116, 117 181
`19, 120, 121 and 122. Item 116 is the message count and defines how
`many payload elements will be contained in the payload. A single
`payload element consist of a triplet of source ULP address, and datalink
`and data. Items 117, 118 and 119 comprise the first payload element of
`the payload. Item 117 is the ULP address of the source of the payload
`element, item 118 is the data length for the data in the payload element
`and item 119 is the actual data. Items 120, 121 and 122 comprise the
`last payload element in the payload. ULP send messages only support
`payloads with a single payload element, so the message count is
`required to equal one. ULP receive messages may have payloads with
`one or more payload elements. Ex. 1001, Col. 14:37- 50
`
`25
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`CLAIM CONSTRUCTION
`Encapsulated Header:
`The Boards position is that PO’s construction position is that the term
`“aggregated message” does not encapsulate headers. Institution Decision, paper
`11, p. 13-14.
`
`• PO’s position construction position is not that the term “aggregated
`message” does not encompass encapsulated headers. PO Response,
`paper 22, p. 8.
`• PO’s construction is that an “aggregated message” includes only a single
`transport layer message header. PO Response, paper 22, p. 8-9.
`
`26
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`CLAIM CONSTRUCTION
`
`The institution Decision states:
`
`Nonetheless, as noted above, headers, such as headers 117 and 118
`or 120 and 122, appear in each payload. See Ex. 1001, 23:11-12
`(“Each payload item in a message queue will contain a ULP source
`address, a data length and data to be sent.”). Even though an
`embodiment strips out a TLP header from a “message,” it looks up a
`TLP header of the host from “host address map 137.” Id. at 23:20-
`22. The specification consistently shows that a payload, even with an
`aggregated payload, may contain header fields. See, e.g., id. at Fig. 9.
`Emphasis Added. Institution Decision, paper 11, at 12-13
`
`The bolded portion of the above statement are NOT TLP within an
`aggregated message. PO Response, paper 22, p. 10.
`
`27
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`CLAIM CONSTRUCTION
`
`• Discussion of “aggregated message”
`as shown in Fig. 9 shows only a
`single transport layer message
`header that includes fields 123-128.
`While payload 129 does include
`multiple Source ULP addresses 117,
`120, the Source ULP addresses 117,
`120 are not transport layer headers.
`Ex. 2002, ¶48; PO Resp., paper 22,
`p. 9.
`• The source ULP addresses are not
`transport layer headers, as the ULP
`source address is a part of a layer
`above the transport layer (the
`Session Layer). Ex. 2002, ¶48, PO
`Resp., paper 22, p. 9.
`• A ULP source address, a data length,
`and the data to be sent is not
`relevant as none of these
`components comprise a transport
`layer header. PO Resp., paper 22, p.
`
`28
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`CLAIM CONSTRUCTION
`
`No Support for Lookup of TLP Host Address Being
`the TLP Header – Different from Transmission
`
`• Looking up the TLP host address does not suggest that
`an “aggregated payload” includes a transport layer
`header or that an “aggregated message” includes more
`that a single transport layer header. Ex. 2002, ¶¶ 50-52;
`PO Response, paper 22, p. 10-11.
`
`29
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`CLAIM CONSTRUCTION
`Patent’s Motivation for Single Transport Header
`
`•
`
`“[a]ggregation will also reduce the total data rate to the hosts since
`aggregation eliminates the need for separate message headers for
`each payload item. The savings with be significant for small payload
`items since there will be only one message header comprising fields 123,
`124 and 125 for multiple payload items”. Ex. 1001, 24:23-28; PO
`Response, paper 22, p. 12.
`• The ‘523 Patent also states that an aggregated message is “longer and
`contains multiple payloads, but this is a significant improvement over
`received multiple messages with the wasted overhead of multiple
`message headers and message processing time.” Ex. 1001, 10:40-44;
`PO Response, paper 22, p. 12.
`• The specification makes it clear that there is only one transport message
`header (including fields 123, 124, and 125) in an aggregated message, and
`clearly explains that data reduction is significant because there is only one
`transport message header. Ex. 2002, ¶¶ 53-54; PO Response, paper 22,
`p. 12.
`
`30
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`CLAIM CONSTRUCTION
`Legal Rational for Single Transport Header
`
`•
`
`“Where the general summary or description of the invention
`describes a feature of the invention . . . and criticizes other products
`. . . that lack that same feature, this operates as a clear disavowal .
`. .” Astrazeneca AB, Aktiebolaget Hassle, KBI-E, Inc. v. Mut.
`Pharm. Co., 384 F.3d 1333, 1340 (Fed. Cir. 2004). PO Resp., p. 12-
`13.
`
`• The ‘523 Patent both describes the advantages of transmitting a
`single transport layer message header, and criticizes other
`embodiments. Ex. 1001, 24:23-28, 10:40-44; PO Resp., p. 13.
`
`• To state that the specification does not limit aggregated payloads
`from including transport layer headers completely ignores the
`specific disclosure of the ‘523 Patent; PO Resp., p. 13.
`
`31
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`MOTIVATION
`
`MOTIVATION
`
`MOTIVATION TO COMBINE
`ALDRED AND RFC 1692
`MOTIVATION TO COMBINE
`ALDRED AND RFC 1692
`
`32
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`MOTIVATION - Petition
`
`Petitioner’s motivation to combine analysis can be summarized as follows:
`
`(1) Aldred uses a serialization process to transmit serialized packets to a
`destination node;
`(2) Aldred discloses the generation of small packets with respect to a
`drawing board;
`(3) RFC 1692 aggregates small packets using the T-Mux protocol; and,
`the conclusion being:
`(4) The combination of Aldred and RFC 1692
`simply comprises the application of the T-Mux
`protocol with serialized small packets of
`Aldred.
`
`PO Resp., Paper 22, 15-16.
`
`33
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`MOTIVATION - Petition
`
`DR. WHITE’S RATIONALE
`
`•
`
`“Incorporating the TMux protocol into Aldred would simply involve using
`the TMux-enhanced IP protocol for Aldred’s transportation, something well-
`within the abilities of an Ordinary Artisan. Ex. 1007, ¶149. This arranges
`known elements, each preforming known functions, to yield no more than
`one would expect from such an arrangement (RFC 1692’s functionality
`multiplexing outgoing messages from Aldred’s CSP).” Petition, 38-39.
`
`PO Resp., Paper 22, 17; Ex. 1007, ¶149, Petition, 38-39.
`
`• Petitioner has not provided a complete analysis regarding the motivation to
`combine Aldred and RFC 1692.
`PO Resp., Paper 22, 18; Almeroth Dec., Ex. 2002, ¶ 65.
`
`34
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`MOTIVATION - Petition
`
`PETITIONER FAILED TO CONSIDER:
`
`•
`
`•
`
`(1) the requirement for “order” in the serialisation operation of “all”
`packets in Aldred, and that order is not addressed in RFC 1692;
`
`(2) the possibility of large packets in the serialisation process of Aldred;
`
`•
`
`(3) how using the TMux protocol disclosed in RFC 1692 could disrupt
`the required order of the serialisation operation of Aldred in light of the
`disclosure in RFC 1692 that large packets should not be multiplexed
`and immediately transmitted.
`PO Resp., Paper 22, 18.
`
`• Petitioner has not provided a complete analysis regarding the motivation to
`combine Aldred and RFC 1692.
`PO Resp., Paper 22, 18; Almeroth Dec., Ex. 2002, ¶ 65.
`
`35
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`MOTIVATION - Petition
`
`ORDER
`
`(A) Petitioner has failed to consider order in the combination of RFC 1692 with
`the CSP of Aldred. Ex. 1009, 51. (PO Resp., Paper 22, 20)
`
`(B) RFC 1692 does not address the order of packets to be TMuxed as being a
`concern, or the order in which packets can be sent relative to the order in
`which they are generated. (PO Resp. Paper 22, 20; Almeroth Dec., Ex.
`2002, ¶ 68)
`
`36
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`MOTIVATION - Petition
`
`ORDER
`(C) Serialization queue disclosed in Aldred has an order requirement (PO Resp., Paper
`22, at 19-21; Almeroth Dec., Ex. 2002, at ¶¶ 68-69.)
`
`•
`
`•
`
`•
`
`“Serializing channel set data packets are combined from different channels,
`serialised, and delivered to each application such that each receiving port
`receives the same sequence of data.” (Aldred, Ex. 1009, at 7; PO Resp., Paper
`22, at 20; Almeroth Dec., Ex. 2002, at ¶ 68.)
`
`“However, there is the important additional constraint that the data packets are
`guaranteed to arrive at all the receiving ports in the identical sequence.”
`(Aldred, Ex. 1009, 50; PO Resp., Paper 22, 26)
`
`An example of data serialisation is illustrated by a shared drawing board
`application illustrated in Figure 6. Two identical applications, A and B (50 and
`52), allow their users to draw on a single shared surface. In order that the
`users at A and B see identical results, all the drawing orders at A must be sent
`to B via ports 53 and 54, and vice versa via ports 55 and 56, in such a way
`that the sequence processed at A and B is identical. This is accomplished
`by each transmitting their own data both to each other and to themselves, over
`two channels 57 and 58 which are members of a common serialising channel
`set 59. (Ex. 1009, 7 (Emphasis Added); PO Resp., Paper 22, at 23)
`
`37
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`MOTIVATION - Petition
`
`LARGE PACKETS IGNORED
`Petitioner Position
`
`(A) Dr. White, as he admitted at his deposition, did not consider large packets
`with respect to the analysis of the combination of Aldred with RFC 1692:
`
`Is that correct, that what you analyzed, systems of small packet –
`• Q.
`with small packet operation?
`• A.
`I analyzed systems that were intended to transmit a number of small
`packets.
`• …
`• Q. Did you analyze the situation where you have a system that’s
`predominately large packets?
`• A.
`I didn’t analyze that in detail, no.
`• Q. Did you analyze a system where there was a combination of small
`packets and large packets?
`• A.
`I didn’t analyze it in detail. I’m aware that it’s discussed in the TMux
`reference, but that was not a --.
`
`(White Depo1, Ex. 2004, 44-45; PO Resp., Paper 22, at 21-22)
`
`38
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`MOTIVATION - Petition
`
`LARGE PACKETS IGNORED
`Petitioner Position
`(B) Specifically, Petitioner recites Aldred’s teaching of “drawing orders” as an
`example of an application generating small packets and supports this with
`testimony from Petitioner’s expert, Dr. White, who indicates that the
`drawing orders would generate small packets whose transmissions could
`be TMuxed to improve the operation of Aldred. (PO Resp., Paper 22, at 17
`(emphasis added); Petition, 37-38; White Dec, Ex. 1007, ¶146)
`
`(C) Petitioner recites only this one example, with no quantifiable support for
`“smaller”:
`• Aldred explains that messages such as “drawing orders” and events
`are transmitted between shared application to maintain consistent
`operations. . . . As Dr. White explains, an Ordinary Artisan would have
`understood that drawing orders and other events used to keep data
`consistent between applications, such as user input, would result in
`messages significantly smaller than the IP protocol supports, such that
`RFC 1692 would improve Aldred’s performance by reducing the
`number of packets.
`Petition, 37-38; Ex. 1007, ¶146.
`
`39
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`MOTIVATION - Petition
`
`LARGE PACKETS IGNORED
`
`(D) Petitioner Position as to “smaller”:
`
`•
`
`“An Ordinary Artisan would have understood that Aldred’s system could
`likewise produce the small packets that would benefit from RFC 1692’s
`multiplexing. Ex. 1007, ¶146. The IP protocol supports packet sizes up to
`65,535 octets, with every host supporting at least datagrams up to 576
`octets. Ex. 1011, 13.”
`(Petition, 37)
`
`•
`
`“It is also suggested that larger segments (e.g., those over 700 octets)
`should be sent as standard IP datagrams, and not multiplexed.
`. . .
`
`A TCP segment consisting of a 20 octet TCP header, 5 octets of data
`and 3 octets of padding.”
`(RFC 1692, Ex. 1010, 7)
`
`40
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`MOTIVATION - Petition
`
`LARGE PACKETS IGNORED
`Patent Owner Position
`(A) Large packets were thus ignored by Petitioner and Petitioner’s expert in
`their analysis despite the fact that Aldred clearly discloses the transmission
`of data that would comprise large packets. (PO Resp., Paper 22, at 22).
`
`(B) There is no suggestion in Aldred that the CSP would not be able to receive
`both large and small packets to be serialised and transmitted to nodes in a
`sharing set. Ex. 2002, ¶ 70. (PO Resp., Paper 22, at 22)
`
`(C)Aldred can deal with large packets. Aldred discloses a shared drawing
`board:
`“The chalkboard 103 implements a common drawing area with two
`image planes, which is accessible to all users in a call. The background
`plane can be loaded from bit-map files, the system clipboard, or from
`the contents of an application window. The foreground plane can be
`used for interactive annotation using a range of simple text and
`graphics tools. Remote pointers over the chalkboard are also
`supported.”
`(Aldred, Ex. 1009, at 28; PO Resp., Paper 22, at 26; Ex. 2002, ¶ 77.)
`
`41
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`MOTIVATION - Petition
`
`LARGE PACKETS IGNORED
`
`(D) If application A attaches an image from its local clipboard onto its drawing plane, the
`image would need to be transmitted to all the workstations. This would involve
`creating a packet including the image, along with certain commands for handling the
`image, such as location data for where to place the image on the receiving
`applications’ drawing board. The packet would then be transmitted to the CSP and
`placed in the queue. Id.
`In many situations the packet including the image could be deemed a large packet,
`not TMuxed, and immediately sent ahead of the TMux message currently under
`construction in the buffer, causing a disruption in the packet order.
`(PO Resp., Paper 22, 27; Ex. 2002, ¶ 78)
`
`(E) In the Reply, Petitioner argued emphasized that PO’s arguments stated a packet
`could be deemed a large packet and could by transmitted out of order. Reply, Paper
`25, at 3, 8.
`•
`This is not correct – see Ex. 1010 at p. 7 (top paragraph).
`
`42
`
`Ex. 2006 | IPR2018-00129, -130, -131, -132 | Patent Owner's Demonstrative Exhibits - Not Evidence
`
`
`
`MOTIVATION - Petition
`
`LARGE PACKETS IGNORED
`• Petitioner’s expert oversimplifies combination of Aldred and RFC 1692
`as “simply” involving using TMux with the serialization queue of Aldred.
`(Petition, Paper 1, 38-39).
`
`• Petitioner’s expert’s analysis merely alleges it is a “simple”
`combination, also only referring to the single “drawing orders”
`example, with no quantifiable support for “smaller”. (White Dec., Ex.
`1007, ¶ 149, 161; PO Resp. 27-28)
`
`• Petitioner’s expert further stated twice during deposition that he
`believes Aldred and RFC 1692 are “easy” to combine. (White Depo1,
`Ex. 2004, at 60:11, 60:21)
`
`• However, the combination requires more technical consideration than
`the “simple” addition of TMux as provided by Petitioner and its expert.
`Simply implementing RFC 1692 into Aldred would require a redesign of
`the structure of the Aldred system – resulting in undue experimentation
`and modification to implement, and would render the Aldred system
`unsatisfactory for its intended purpose.. (PO Resp., 28; Ex. 2002 ¶ 81)
`
`4
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
