IPR2018-00131
`Patent 6,226,686
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`_______________
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`_______________
`
`
`RIOT GAMES, INC.,
`Petitioner,
`
`v.
`
`PALTALK HOLDINGS, INC.,
`Patent Owner.
`
`_______________
`
`
`Case IPR2018-00131
`Patent 6,226,686
`_______________
`
`
`
`
`
`
`
`
`PATENT OWNER’S RESPONSE TO PETITION FOR
`INTER PARTES REVIEW OF U.S. PATENT NO. 6,226,686
`
`
`
`i
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`
`I. 
`
`II. 
`
`A. 
`
`B. 
`
`TABLE OF CONTENTS
`INTRODUCTION..........................................................................................................................1 
`
`CLAIM CONSTRUCTION ..........................................................................................................1 
`
`“AGGREGATED MESSAGE” (CLAIMS 1, 3, 7, 12) AND “SERVER MESSAGE” (CLAIM 18) ...............4 
`
`“AGGREGATED PAYLOAD” (CLAIMS 1, 7, 12); “AGGREGATING SAID PAYLOAD
`PORTIONS” (CLAIM 3) AND “AGGREGATING SAID PAYLOAD PORTION WITH THE
`PAYLOAD PORTION OF A SECOND HOST MESSAGE” (CLAIM 18) .................................................13 
`
`III. 
`
`PETITIONER HAS FAILED TO PROVE INVALIDITY WITH RESPECT TO
`ANY OF THE ‘686 PATENT CLAIMS ....................................................................................15 
`
`A.  PETITIONER’S MOTIVATION TO COMBINE ALDRED AND RFC 1692 .........................................15 
`
`B.  PETITIONER HAS FAILED TO FULLY SUPPORT THE MOTIVATION TO COMBINE
`ALDRED AND RFC 1692 ...............................................................................................................18 
`
`1.  The CSP in Aldred has an “order” requirement ....................................................................................................... 20 
`2.  Petitioner failed to consider the effects of large packets with respect to the serialization process of Aldred .......... 21 
`3.  Petitioner failed to consider the requirements of packet order in the Serialization process when Aldred
`and RFC 1692 are combined ................................................................................................................................... 23 
`4.  Petitioner failed to consider why a POSITA would turn to RFC 1692 when Aldred already discusses
`alternative bandwidth solutions ............................................................................................................................... 29 
`5.  Petitioner’s Failure to Consider the Issues in Sections III.B.1-4. Render Its Obviousness Analysis
`Insufficient ............................................................................................................................................................... 31 
`C.  PETITIONER HAS FAILED TO DEMONSTRATE THAT ALDRED IN VIEW OF RFC 1692
`RENDERS OBVIOUS CLAIMS 1-4, 7-21, 28-30, 34, 35, 39, 40, 47-49, 53, 54, 56, 57, 64-66,
`AND 70 OF THE ‘686 PATENT UNDER 35 U.S.C. § 103 .................................................................33 
`
`1.  Aldred in view of RFC 1692 does not render obvious Claims 1, 3, 7, 12, and 18 ................................................... 33
`a. Petitioner has failed to demonstrate that RFC 1692 discloses or suggests “aggregating said payload
`portions of said host messages . . . to create an aggregated payload” (Claim 1 and 3); “aggregating said
`payload portions of said messages . . . to create an aggregated payload” (Claim 7 and 12); and
`“aggregating said payload portion with the payload portion of a second host message” (Claim 18) ................... 33
`b. Petitioner has failed to demonstrate that RFC 1692 discloses or suggests “forming an aggregated
`message using said aggregated payload” (Claims 1, 12); “create an aggregated message” (Claim 3);
`“said aggregated message” (Claim 7); and “forming a server message . . .” (Claim 18) ..................................... 43
`2. Aldred in view of RFC 1692 does not render obvious Claims 30, 34, 35, 49, 53, 54, 66, and 70 ........................... 50 
`
`ii
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`
`3.  Aldred in view of RFC 1692 does not render obvious Claims 2, 4, 8-11, 13-17, 19-21, 28, 29, 39, 40, 47,
`48, 56, 57, 64, and 65 ............................................................................................................................................... 53 
`D.  PETITIONER HAS NOT DEMONSTRATED THAT ALDRED IN VIEW OF RFC 1692 AND
`RFC 1459 RENDERS OBVIOUS CLAIMS 31-33, 50-52, AND 67-69 OF THE ‘686 PATENT
`UNDER 35 U.S.C. § 103 ................................................................................................................55 
`
`IV.  CONCLUSION ............................................................................................................................57 
`
`
`
`
`
`iii
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`
`Exhibit 2002:
`Exhibit 2003:
`Exhibit 2004:
`
`
`
`LIST OF EXHIBITS
`
`Declaration of Dr. Kevin C. Almeroth
`Curriculum Vitae of Dr. Kevin C. Almeroth
`Transcript of Deposition of Dr. Steve White
`
`
`
`iv
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`I.
`
`INTRODUCTION
`
`Pursuant to 37 C.F.R. § 42.120, Patent Owner Paltalk Holdings, Inc.
`
`(“Paltalk” or “Patent Owner”) respectfully submits this Patent Owner’s Response,
`
`to the Petition for Inter Partes Review (Paper 1) filed by Riot Games, Inc.
`
`(“Petitioner”) concerning U.S. Patent No. 6,226,686 (“the ‘686 Patent”) (Ex.
`
`1002). The Patent Trial and Appeal Board (“the Board”) instituted this proceeding
`
`on May 15, 2018, with respect to (1) Claims 1-4, 7-21, 28-30, 34, 35, 39, 40, 47-
`
`49, 53, 54, 56, 57, 64-66, and 70 of the ‘686 Patent under Petitioner’s alleged 35
`
`U.S.C. § 103 combination of International Publication No. WO 94/11814 to Aldred
`
`(“Aldred”) (Ex. 1009) and “Transport Multiplexing Protocol (TMux),” RFC 1692
`
`(“RFC 1692”) (Ex. 1010), and (2) Claims 31-33, 50-52, and 67-69 of the ‘686
`
`Patent under Petitioner’s alleged § 103 combination of Aldred, RFC 1692, and
`
`“Internet Relay Chat Protocol,” RFC 1459 (“RFC 1459”) (Ex. 1025). Patent
`
`Owner addresses each of these grounds in the present Response and requests that
`
`the Board hold the claims of the ‘686 Patent valid.
`
`II. CLAIM CONSTRUCTION
`
`The ‘686 Patent has expired. Therefore, the claims should be given their
`
`ordinary and accustomed meaning as understood by one of ordinary skill in the art
`
`consistent with the standard expressed in Phillips v. AWH Corp., 415 F.3d 1303,
`
`1312–13 (Fed. Cir. 2005) (en banc). The ordinary meaning of a term may be
`
`1
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`evidenced by a variety of sources, including “the words of the claims themselves,
`
`the remainder of the specification, the prosecution history, and extrinsic evidence
`
`concerning relevant scientific principles, the meaning of technical terms, and the
`
`state of the art.” Phillips, 415 F.3d at 1314.
`
`Petitioner has argued with respect to the below claim elements that they can
`
`be understood “under any interpretation consistent with their plain and ordinary
`
`meaning in the context of the ‘686 Patent” Petition, 5-6. Petitioner in this
`
`proceeding has attempted to equate the “aggregated payload” and aggregating
`
`steps recited in the claims of the ‘686 Patent with “aggregated packets,” as shown
`
`in RFC 1692. It should be noted that Petitioner’s expert only acknowledged a
`
`previous construction for “aggregating/aggregated” and did not provide an
`
`understood meaning beyond “any interpretation of that phrase consistent with its
`
`plain and ordinary meaning.” Ex. 1007, ¶ 46. Further, Petitioner’s expert did not
`
`perform any search of the use of the term “aggregated payload” in the industry
`
`around the time of 1996. Ex. 2004, 22. Petitioner’s expert has stated that his
`
`understanding of the term “aggregated payload” was based merely on his
`
`professional knowledge around 1996 or before. Id. at 23.
`
`With respect to the terms “aggregated payload” (Claims 1, 7, 12),
`
`“aggregating said payload portions” (Claim 3), and “aggregating said payload
`
`portion with the payload portion of a second host message” (Claim 18), and the
`
`2
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`closely related term “aggregated message” (Claims 1, 3, 7, 12) (referred to as a
`
`server message in Claim 18) there was not a commonly understood meaning for
`
`the term “aggregated payload” at the time of filing of the ‘686 Patent. Ex. 2002, ¶
`
`40. A person of ordinary skill in the art (“POSITA”)1 at the time of filing of the
`
`‘686 Patent would not have understood a commonly accepted meaning for
`
`“aggregated payload” and “aggregated message,” and their associated other terms
`
`Id. While a POSITA could make an 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 ‘686 Patent to determine the exact meaning
`
`and composition of an “aggregated payload” and an “aggregated message.” Id.
`
`1 A person of ordinary skill in the art in February 1996 would have had a
`
`Bachelor’s degree in Computer Science, Computer Engineering, or the equivalent,
`
`and approximately two years experience in the field of interactive, network-based
`
`applications. As a result, a person of ordinary skill in the art would have
`
`understood network protocols like the Transmission Control Protocol (TCP), the
`
`User Datagram Protocol (UDP), and the Internet Protocol (IP). A person of
`
`ordinary skill in the art would also know how to write computer applications that
`
`used “network sockets” to utilize these protocols to communicate over networks
`
`like the Internet. Ex. 2002, ¶ 37.  
`
`3
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`Patent Owner therefore proposes the below constructions, as supported by the
`
`specification of the ‘686 Patent.
`
`A.
`
`“aggregated message” (Claims 1, 3, 7, 12) and “server message”
`(Claim 18)
`
`Patent Owner’s Proposed Construction
`
`One or more messages containing a single transport layer message header,
`
`destination data, and data items from an aggregated payload.
`
` A
`
` proper understanding of the claims of the ‘686 Patent requires
`
`construction of the terms “aggregated message” and “server message” from the
`
`steps of “forming an aggregated message using said aggregated payload” of Claims
`
`1 and 12; “aggregating . . . to create an aggregated message” of Claim 3;
`
`“transmitting said aggregated message” of Claim 7; and “forming a server
`
`message” of Claim 18. The above claim construction is consistent with the
`
`disclosure of the ‘686 patent as described below. Ex. 2002, ¶ 41.
`
`Figure 7, below, of the ‘686 Patent illustrates the messages transmitted by
`
`the Group Messaging Server.
`
`4
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`
`The ‘686 Patent describes that the payload portions of messages 96, 97, 98,
`
`99 are removed by the group messaging server so that the payload portions of these
`
`messages can be aggregated. The ‘686 Patent states:
`
`
`
`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
`
`5
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`
`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.
`
`Ex. 1002 at 20:14-30 (emphasis added); Ex. 2002, ¶¶ 42-44.
`
`Each of the aggregated messages 100, 101, 102 and 103 includes aggregated
`
`payloads (Pn1, Pn2, Pn3) in each message and a header portion consisting of a
`
`transport layer protocol source address (S) of the server, 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. 1002, col.
`
`8, col. 9, col. 10, Fig 7. As can be seen from the disclosure of Fig. 7 and the
`
`associated discussion thereof, only a single message header consisting of the
`
`transport layer protocol source address, the transport layer protocol destination
`
`address and the ULP address is utilized. This single message header is then
`
`combined with the aggregated payload generated by the previous aggregating step.
`
`Ex. 2002, ¶ 45.
`
`More detail of the datagram structure is provided with respect to Figure 9 of
`
`the ‘686 Patent, as shown in Patent Owner’s annotated Figure 9 below.
`
`6
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`
`
`
`As shown above, the overall structure of an aggregated message includes a
`
`message header (blue) a payload (green), and multiple payload elements (red)
`
`included as part of an aggregated payload. Ex. 1002, 14:37-52. An upper layer
`
`protocol (ULP) message comprises the transport header 123, the ULP message
`
`type field 124, the destination ULP address 125, the address count field 126, the
`
`auxiliary destination addresses 127, 128 and the payload 129. Id. at 13:60-14:50,
`
`Fig. 9. The fields 123, 124, 125, 126, 127 and 128 constitute the message header.
`
`Ex. 2002, ¶ 47. The structure of the payload 129 is illustrated in the center portion
`
`7
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`of the figure. The “payload format . . . is defined by items 116, 117, 118, 119, 120,
`
`121, and 122.” Ex. 1002 at 14:37-40. The claims requires, in a first and separate
`
`step, aggregating the payload portions to “create an aggregated payload,” which is
`
`shown by the payload portion 129, and items 116-122 of FIG. 9. Ex. 2002, ¶ 47.
`
`Each of the aggregated payload elements include the source ULP address 117, 120
`
`of the transmitted payload element, the data length 118, 121 of the payload element
`
`and the actual data 119, 122. Ex. 1002 at 14:37-50.
`
`
`
`In response to the Patent Owner’s arguments in the Preliminary Response
`
`with respect to Fig. 9, the Institution Decision states:
`
`Patent Owner does not dispute, in a clear fashion, Petitioner’s
`contention that the claims may encompass encapsulated headers. See
`PO Prelim. Sur-Reply 4. (“The annotation of Figure 9 does not
`concede that the recited terms comprise a transport layer message
`header as described with respect to the referenced discussions of the
`OSI reference model.” (emphasis added)). In any event, on this
`preliminary record, the ‘686 patent discloses using TLP headers or a
`“datagram protocol” to encapsulate messages and/or payloads that
`include headers (e.g. address information, message type), as discussed
`above.
`
`Institution Decision, 13. First, the Patent Owner’s construction position is not that
`
`the terms “aggregated message” and “server message” do not encompass
`
`encapsulated headers. The Patent Owner’s construction is that an “aggregated
`
`8
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`message” or “server message” includes only a single transport layer message
`
`header. The discussion of an “aggregated message” or “server message” as shown
`
`in Fig. 9 shows only a single transport layer message header that includes fields
`
`123, 124, 125, 126, 127 and 128. While the payload 129 does include multiple
`
`Source ULP addresses 117, 120, the Source ULP addresses 117, 120 are not
`
`transport layer headers. Ex. 2002, ¶ 48.
`
`As described in the ‘686 Patent, the Upper Level Protocol (ULP) “is layered
`
`above the existing network Transport Level Protocol (TLP). In the OSI reference
`
`model the protocol can be described as a Session Layer protocol on top of the
`
`transport layer of the network.” Ex. 1002, 12:47-50. Therefore, even though Fig.
`
`9 illustrates multiple Source ULP addresses 117, 120, the source ULP addresses
`
`are not transport layer headers, as the ULP source address is part of a layer above
`
`the transport layer (the Session Layer). Ex. 2002, ¶ 49.
`
`
`
`The Institution Decision also states:
`
`Nonetheless, as noted above, headers, such as headers 117 and 118 or
`120 and 122, appear in each payload. See Ex. 1002, 23:11-12 (“Each
`payload [includes] a ULP source address, a data length and the 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
`
`9
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`
`a payload, even with an aggregated payload, may contain header
`fields. See, e.g., id. at Fig. 9.
`
`Institution Decision, 12. Again, 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. As discussed previously, the message header consists of the items
`
`highlighted in blue in the above discussion with respect to Fig. 9. Additionally, the
`
`portion of the specification regarding looking up a TLP header of the host from the
`
`“host address map 137” actually supports Patent Owner’s construction. The
`
`specification states:
`
`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.
`
`Ex. 1002, 23:20-23 (emphasis added). This TLP header for the message 123 thus
`
`is at least a part of the single transport layer message header for the aggregated
`
`message:
`
`10
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`
`
`
`There is thus no indication in the ‘686 Patent that multiple TLP headers are
`
`included within the aggregated message. Therefore, 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 than a single transport layer
`
`header. A single transport layer header is used because all aggregated payloads are
`
`being transmitted to a same destination host running a same application as other
`
`hosts, such as a game, and thus there is no need for multiple transport layer
`
`headers. Ex. 2002, ¶¶ 50-52.
`
`11
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`
`The Institution Decision further states:
`
`The specification describes any data reduction as significant only for
`small packet sizes, and generally attributes data reductions due to
`message aggregation.
`
`Institution Decision, 14 (citing Ex. 1002, 24:23-28). The ‘686 Patent however
`
`clearly discusses significant data reduction by eliminating transport headers from
`
`payloads. The ‘686 Patent states “[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 will 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. 1002, 24:23-28 (emphasis added). The ‘686
`
`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. 1002, 10:44-47.
`
`The specification makes it clear that there is only one transport message
`
`header (including fields 123, 124, and 125) in an aggregated message or server
`
`message, and clearly explains that data reduction is significant because there is
`
`only one transport message header. Ex. 2002, ¶¶ 53-54. “Where the general
`
`summary or description of the invention describes a feature of the invention . . .
`
`12
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`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). The ‘686 Patent both describes the
`
`advantages of transmitting a single transport layer message header, and criticizes
`
`other embodiments. Ex. 1002, 24:23-28, 10:40-44. To state that the specification
`
`does not limit aggregated payloads from including transport layer headers
`
`completely ignores the specific disclosure of the ‘686 Patent. Therefore, Patent
`
`Owner proposes adoption of this claim construction for “aggregated message.”
`
`B.
`
`“aggregated payload” (Claims 1, 7, 12); “aggregating said payload
`portions” (Claim 3) and “aggregating said payload portion with
`the payload portion of a second host message” (Claim 18)
`
`Patent Owner’s Proposed Construction
`
`A collection of two or more data items that does not include transport layer
`
`headers.
`
` A
`
` proper understanding of the claims of the ‘686 Patent requires
`
`construction of the term “aggregated payload” (Claims 1, 7, 12), “aggregating said
`
`payload portions” (Claim 3), and “aggregating said payload portion with the
`
`payload portion of a second host message” (Claim 18). The above construction is
`
`consistent with the disclosure of the ‘686 Patent. Ex. 2002, ¶ 55.
`
`13
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`
`
`The above Section II.A. regarding the Patent Owner’s construction for
`
`“aggregated message” and “server message” describes that payload portions of
`
`messages, such as the messages 96, 97, 98, and 99 in FIG. 7, received by the group
`
`messaging server have TLP headers removed and are aggregated into an
`
`aggregated payload. The aggregated payload is included in a single aggregated
`
`message with a single transport layer message header. As explained above in
`
`Section II.A., the specification of the ‘686 Patent describes that transport layer
`
`headers are removed from messages sent to the group messaging server. Ex. 1002
`
`at 20:14-30; Ex. 2002, ¶ 56.
`
`The process of creating the aggregated payload is further described by the
`
`‘686 Patent at 23:50-24:52. The ‘686 Patent states:
`
`[t]he ULP server process 140 removes payload items from a message
`queue 143 for a host and accumulates them in an aggregation buffer
`149 . . . At the end of the aggregation period, the each host
`aggregation buffer may hold multiple payload items. The host
`aggregation buffer will hold a message count of the payload items
`followed by the multiple payload items. The contents of a host
`aggregation buffer along with
`the ULP host address of
`the
`corresponding host are sent to the GMS control function 136 where it
`will be used to create a ULP receive message sent to the destination
`host . . . The payload in this case will have a message count 116 set by
`the message count value from the host aggregation buffer. The
`
`14
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`
`payload will contain all of the payload items from the host
`aggregation buffer.
`The effect of aggregation will be to greatly reduce the total message
`rate received by the hosts. A single message to a host will be able to
`carry multiple payload items received from the other hosts during the
`aggregation period.
`
`Ex. 1002 at 23:53-24:15 (emphasis added).
`
`Thus, an aggregated payload as described in the ‘686 Patent is a collection
`
`of two or more data items that does not include transport layer headers. Ex. 2002,
`
`¶¶ 57-58. Therefore, Patent Owner proposes adoption of this claim construction
`
`for “aggregated payload” and the “aggregating” steps of Claims 1, 3, 7, 12, and 18.
`
`III. PETITIONER HAS FAILED TO PROVE INVALIDITY WITH RESPECT TO ANY
`OF THE ‘686 PATENT CLAIMS
`
`A.
`
`Petitioner’s Motivation to Combine Aldred and RFC 1692
`
`Petitioner’s analysis has provided an insufficient basis for the combination
`
`of Aldred and RFC 1692 due to its failure to consider the effects of several key
`
`factors. 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;
`
`15
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`
`(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.
`
`Petitioner applies the disclosure of Aldred with respect to a serialization
`
`channel set and Central Serialization Point (CSP) to most of the limitations of the
`
`claims except with respect to the aggregation and formation of the aggregated
`
`message steps. For these elements, Petitioner turns to RFC 1692. With respect to
`
`Aldred, Petitioner states:
`
`Aldred discloses the serialising and transmission of data streams by a
`CSP. Ex. 1009, 9. Data is sent over channels in packets. Id., 16.
`This functionality illustrated in Figure 22, where each packet is added
`to a queue and then serially transmitted to each member of the Sharing
`Set associated with the serialised channel set. Id., 51, Fig. 22; Ex.
`1007, ¶142. Aldred does not, however, explicitly disclose the claimed
`“aggregating.”
`
`Petition, 31.
`
`Petitioner thus turns to RFC 1692 for the claimed “aggregating.” Petitioner
`
`states “[i]t would have been obvious to an Ordinary Artisan in 1995 to modify
`
`Aldred’s CSP to communicate with other nodes via RFC 1692’s TMux protocol so
`
`16
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`as to ‘aggregat[e] said payload portions’ as claimed.” Id., 32. Petitioner’s alleged
`
`motivation for this combination is based on its small packet centric argument that
`
`RFC 1692 provides benefits for systems generating a number of small packets and
`
`“[a]n Ordinary Artisan would have understood that Aldred’s system could likewise
`
`produce the small packets that would benefit from RFC 1692’s multiplexing.” Id.,
`
`33. 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. Id., 33-34; Ex. 1007, ¶146.
`
`Petitioner characterizes utilizing the TMux protocol of RFC 1692 in the
`
`system disclosed in Aldred as a simple addition, stating:
`
`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, 34-35 (emphasis added). As shown above, Petitioner states that
`
`incorporating TMux into the serialising process of Aldred would be a “simple”
`
`17
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`addition by arranging known elements to yield a predictable result. However,
`
`Petitioner and Petitioner’s expert fail to consider a number of problems that would
`
`arise from the combination of Aldred and RFC 1692 that cause the combination to
`
`be more complex than Petitioner believes, and thus Petitioner has not provided a
`
`complete analysis regarding the motivation to combine Aldred and RFC 1692. Ex.
`
`2002, ¶ 65.
`
`B. Petitioner Has Failed to Fully Support the Motivation to Combine
`Aldred and RFC 1692
`
`Petitioner has failed to consider several key factors in its analysis of
`
`combining Aldred and RFC 1692. Specifically, Petitioner has failed to fully
`
`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; and
`
`18
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`
`(4) why a POSITA would turn to RFC 1692 when RFC 1692
`
`would introduce additional latency into the system of Aldred and
`
`when Aldred already discusses alternative bandwidth solutions.
`
`Since Petitioner has failed to address the above considerations, Petitioner has not
`
`sufficiently supported its assertion that combining Aldred with RFC 1692 would
`
`“simply involve” using the TMux protocol in the serialisation process disclosed in
`
`Aldred. Petition, 34-35. Rather, incorporating TMux into the serialization process
`
`of Aldred would require undue experimentation and modification, and would
`
`introduce additional latency into the system of Aldred, which is highly undesirable
`
`for interactive applications. Ex. 2002, ¶ 67. Therefore, a POSITA would not have
`
`been motivated to combine Aldred with RFC 1692. Id.
`
`The inquiry regarding whether to combine references “must be thorough and
`
`searching,” and arguments with respect to common sense “cannot be used as a
`
`wholesale substitute for reasoned analysis and evidentiary support.” In re
`
`NuVasive, Inc., 842 F.3d 1376, 1381, 1383 (Fed. Cir. 2016). To invalidate a claim
`
`based on obviousness, Petitioner must demonstrate “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 in doing so.” ActiveVideo Networks, Inc. v. Verizon
`
`Commc’ns, Inc., 694 F.3d 1312, 1327 (Fed. Cir. 2012).
`
`19
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`
`1. The CSP in Aldred has an “order” requirement
`
`Petitioner in its attempt to find some disclosure in Aldred to equate to “a
`
`group messaging server” as recited in the claims, turns to the CSP of Aldred.
`
`However, Petitioner has failed to consider the effect of combining RFC 1692 with
`
`the CSP of Aldred, where the CSP has a very specific function – ordering
`
`messages and transmitting the messages in that particular order. Ex. 1009, 51. In
`
`Aldred, “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.” Id., 7. Also, Aldred states “[t]he order of signals . . .
`
`is maintained. Signals sent . . . are serialized themselves so that all sources receive
`
`the same sequence of commands.” Id., 8. Thus, data packets are combined,
`
`serialized and transmitted in a same sequence to all targets. Ex. 2002, ¶ 68. RFC
`
`1692 does not discuss 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. Id.
`
`The particular example in RFC 1692, that of a terminal server (Ex. 1010, 2),
`
`is an example of numerous packets being sent to a few hosts, wherein the order of
`
`the packets generated and received is of no relevance as to the receiving processes
`
`on the receiving hosts, since the packets can be destined for any number of
`
`applications running at the receiving host. Ex. 2002, ¶ 69. Further, and as
`
`20
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`described below, RFC 1692 sends large packets right away, thereby causing them
`
`to arrive out of order, a behavior that will lead to problems if implemented in the
`
`system disclosed in Aldred. Id. While Petitioner and Petitioner’s expert recognize
`
`that order is important with respect to the CSP of Aldred, Petitioner and
`
`Petitioner’s expert failed to analyze how the order would be maintained by the CSP
`
`if implementing the TMux protocol disclosed in RFC 1692. Pet., 13-14, 19-20;
`
`Ex. 1007, ¶¶ 61-67.
`
`2. Petitioner failed to consider the effects of large packets with
`respect to the serialization process of Aldred
`
`Petitioner and Petitioner’s expert, 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. An excerpt from the deposition of Dr.
`
`White is below:
`
`Is that correct, that what you analyzed, systems of small packet
`Q.
`– with small packet operation?
`
`I analyzed systems that were intended to transmit a number of
`A.
`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.
`
`21
`
`

`

`IPR201