`Tel: 571-272-7822
`
`Paper11
`Entered: May 15, 2018
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`RIOT GAMES,INC.,
`Petitioner,
`
`Vv.
`
`PALTALK HOLDINGS, INC.,
`Patent Owner.
`
`Case IPR2018-00132
`Patent 6,226,686 & 6,226,686 C1!
`
`Before THU A. DANG and KARL EASTHOM,
`Administrative Patent Judges.
`
`DANG,Administrative Patent Judge.
`
`DECISION
`Institution of Inter Partes Review
`35 US.C. 314(a)
`
`' The Petition challenges original claims and claims issued pursuant to an ex
`parte reexamination.
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`A.
`
`Background
`
`I.
`
`INTRODUCTION
`
`Riot GamesInc. (“Petitioncr”) filed a Petition requesting an inter
`partes review ofclaims 1, 3, 7, 12, 18, 22-27, 36, 41-46, 55, and 58-63 of
`US. Patent No. 6,226,686 (Ex. 1002,“the ’686 patent”). Paper 1 (“Pet.”).
`
`PalTalk Holdings, Inc. (“Patent Owner”) filed a Preliminary Response.
`
`Paper 6 (“Prelim. Resp.”).
`~ We have jurisdiction under35 U.S.C. § 314, which provides that an
`inter partes review maynotbeinstituted “unless .
`.
`. there is a reasonable
`likelihood that the petitioner would prevail with respect to at least 1 of the
`claims challenged in the petition.” 35 U.S.C. § 314(a); see also 37 C.F.R.
`42.4(a) (“The Board institutes the trial on behalf of the Director.”). Upon
`considering the record before us, we determine that Petitioner has shown a
`reasonablelikelihood that it would prevail in showing the unpatentability of
`
`at least one of the challenged claims. Accordingly, we grantthe Petition.
`
`B.
`
`Related Proceedings
`
`Petitioner states that the ’686 patent is related to the following U.S.
`
`Patents: 5,822,523 (“the ’523 patent”) and 6,018,766. Pet. 1. According to
`~ Petitioner, ex partes reexamination No. 90/011,036 (Ex. 1006) involved a
`
`reexamination of the ’686 patent. Pet. 1.
`
`A concurrent request for inter partes review, IPR2018-00131,
`
`challenges claims of the ’686 patent. Pet. 1. Two other concurrent requests
`for inter partes review, IPR2018-00129, and IPR2018-00130, challenge
`
`claims of the 523 patent. Pet. 1.
`
`Petitioner also states that the following cases involve the °523 and
`
`°686 patents: PalTalk Holdings, Inc. v. Valve Corporation, No. 16-cv-
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`1239-JFB-SRF (D. Del.) (filed Dec. 16, 2016); PalTalk Holdings, Inc. v.
`Riot Games, Inc., Case No. 1:16-cv-1240-JFB-SRF (D. Del.) (filed Dec. 16,
`
`2016); PalTalk Holdings, Inc. v. Sony Computer Entertainment America,
`Inc. et al., Case No. 2:09-cv-00274-DF-CE (E.D. Tex.) (filed Sept. 14,
`2009); PalTalk Holdings, Inc. v. Microsoft Corporation, Case No, 2:06-cv-
`00367-DF(E.D. Tex.) (filed Sept. 12, 2006); and Mpath Interactive v.
`Lipstream Networks, Inc., et al., Case No. 3:99-cv-04506-WHA (N.D.Cal.)
`(filed Oct. 7, 1999). Pet. 1-2.
`
`C.
`
`The ’686 Patent
`
`The ’686 patent issued on May 1, 2001, from an application filed
`September 28, 1999, and claimspriority to parent application No.
`08/896,797, filed on July 18, 1997, now US 6,018,766, which in turn isa
`continuation of application No. 08/595,323, filed on February 1, 1996, now
`US 5,822,523. Ex. 1002, at [45], [22], [63].
`The ’686 patent is directed to “server-group messaging,” and
`describes a “method for deploying interactive applications over a network
`containing host computers and group messaging servers.” Jd. at [57].
`Figure 5, reproducedbelow,illustrates a unicast network over which the
`interactive applications may be deployed.
`
`
`
`IPR2018-00132
`
`Patent 6,226,686
`
`Figure 5
`Figure 5 depicts a wide area network with hosts 58, 59, 60, and 61, anda
`group messagingserver (“GMS”) 62. Jd. at 8:65—66. Host 58 has
`Transport Level Protocol (TLP) address A and Upper Level Protocol (ULP)
`address H. Jd. at 8:66-67. Host 59 has TLP address C and ULP addressJ,
`
`host 60 as TLP address B and ULP addressI, host 61 has TLP address D
`
`and ULP address K, and GMS62 has TLP address S. Jd. at 8:67-9:2. “The
`network is a conventional unicast network of network links 69, 70, 71, 72,
`73, 74, 75, 76, and 77 and unicast routers 63, 64, 65, 66, 67, and 68.” Id. at
`9:2-5. GMS62 “receives messages from the hosts addressed to a message
`group andsendsthe contents of the messages to the members of the
`message group.” Jd. at 9:5-8.
`Figure 7, reproduced below, depicts ULP datagrams with payload
`aggregations for implementing an interactive gaming application between
`the four hosts in Figure 5.
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`36
`
`97
`
`Host A Sends
`
`Lats]¢{P|
`
`100
`
`101
`
`eraetta
`
`Host A Receives
`
`:
`
`(8Ts1s|2|apeinatea
`
`Host B Recelves
`
`;
`
`Host B Sends
`
`102
`
`Host C Sends
`” Host C Receives
`Pe[se[Ps|\s[Tesrryre|Ps]
`
`Host D Sends
`Host D Receives
`(ots{sc{rs|‘so[«[Pi[21P3|
`
`103
`
`100
`
`96
`
`401 enane og
`
`Group Server Sends
`
`Group Server Receives
`
`~LALSTs[Pt
`
`oe repsLe[rs]
`2~rsTorTe Ts [elr) *-foTsl[e]]
`103
`$9
`
`Figure 7
`Figure 7 shows GMS(“Group Server”) 62 receiving multiple messages 96,
`97, 98, and 99 before sending them to hosts within message group G.
`/d. at
`9, 18-20, 10:24—28. As shownin Figure 7, multiple messages 96, 97, 98,
`and 99, each respectively contain payload P1, P2, P3, and P4, to be
`aggregated into a single larger message, 100, 101, 102, or 103. Id. Host 58
`sends message 96 (shownin Figure 7 as “Host A sends”), host 60 sends
`message 97 (shownin Figure 7 as “Host B sends”), host 59 sends message
`98 (shown in Figure 7 as “Host C sends”), and host 61 sends message 99
`(shownin Figure 7 as “Host D sends”), wherein each of the messages from
`the hosts has destination TLP address S and ULP address G for GMS62.
`
`Id. at 10:28-32. After GMS 62 receives all four of these messages,it
`
`creates four outbound messages 100, 101, 102, and 103. Td. at 10:33-34.
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`Aggregated message 100 includes destination TLP address A and ULP
`
`address H for host 58 and aggregated payload P2, P3, and P4 respectively
`from the messages from hosts 59, 60, and 61. Jd. at 10:38-40. Aggregated
`message 101 targets host 60, aggregated message 102 targets host 59, and
`
`aggregated message 103 targets host 61. Jd. at 10:41—-42.
`Figure 9, reproduced below, depicts a datagram format and address
`
`format for ULP messages.
`
`Transport|ULP Msg.|Dest.ULP|Address} Destination | Destination Paytosd
`
`
`
`Header Type|Address|Count|Address 4 Address Ni
`
`4123
`
`124
`
`126
`
`126
`
`127
`
`128
`
`129
`
`Date
`[Source Up]
`voce,
`Data
`Message Source LP!
`
`Count|Address 1|Lengiht Address N|Length N.
`
`
`116
`
`7
`
`18
`
`119
`
`120
`
`121
`
`122
`
`130
`
`131
`
`132
`
`Figure 9
`Figure 9 shows a ULP datagram message comprising elements 123, 124,
`125, 126, 127, 128, and 129. Id. at 13:62-64. Transport datagram TLP
`
`header 123 encapsulates the ULP datagram that includes ULP message type
`field 124, destination ULP address 125, address countfield 126, auxiliary
`destination address 127 and 128, andfinally payload 129. Jd. at 13:64—
`
`14:37. Items 116, 117, 118, 119, 120, 121, and 122 define the payload
`
`format of the ULP datagram. Id. at 14:38-39. Item 116 specifies the
`message count and defines the number of payload elements containedin the
`pay load. Items 117, 118, and 119 comprisethefirst payload element in the
`payload, and items 120, 121, and 112 comprise the last payload elementin
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`the payload. Jd. at 14:39-48. In particular, item 117 specifies the ULP
`address of the sourceof the first payload element, item 118 specifies the
`data length for the data in the first payload element, and item 119
`constitutes the actual data. Similarly, item 120 specifies the ULP address of
`the source ofthe last payload element N, item 121 specifies the data length
`for the data in the last payload element N,and item 122 constitutes the
`
`actual data. Jd.
`
`D.
`
`The Challenged Claims
`
`Ofthe challenged claims, claims 1, 3, 7, 12, and 18 are the
`independentclaimsat issue. Claim1isillustrative of the challenged
`claims, and is reproduced below:
`1,
`A method forfacilitating communications amonga plurality of host
`computers over a network to implement a shared, interactive application,
`comprising the stepsof:
`(1) receiving a create message from oneofthe plurality of host
`computers, wherein said create message specifies a message group to
`be created;
`(2) receiving join messages fromafirst subset ofthe plurality of host
`computers, wherein each ofsaid join messagesspecifies said
`message group;
`(3) receiving host messages from a second subset of said first subset
`of the plurality of host computers belonging to said message group,
`wherein each of said messages contains a payload portion and a
`portion that is used to identify said message group;
`(4) aggregating said payload portions of said host messages received
`from said second subset of the plurality of host computers to create
`an aggregated payload;
`(5) forming an aggregated messageusing said aggregated payload;
`and
`(6) transmitting said aggregated messageto said first subset of the
`plurality of host computers belonging to said message group,
`wherein said aggregated message keepsthe shared,interactive
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`application operating consistently on eachofsaid first subset of the
`plurality of host computers.
`Ex. 1002, 27:50-28:8.
`
`E.
`
` Asserted Grounds of Unpatentability
`
`Petitioner contends that the challenged claims are unpatentable based
`
`on the following specific grounds (Pet. 21, 51, and 66):
`
`
`
`Reference Basis|Claim Challenged
`
`Aldred,? and RFC 16923
`§ 103
`1, 3,7, 12, 18, 26, 27, 45,46, 62,
`
`
`
`
`
`
`
`Aldred, RFC 1692, and Ulrich*|§ 103 22-27, 41-46, and 58-63
`
`and 63
`
`Aldred, RFC 1692, and Denzer?|§ 103 36, and 55
`
`
`
`
`Petitioner also relies on the testimonies of Dr. Steve R. White and
`
`David H.Crocker.® Exs. 1007, 1026. Patent Ownerrelies on,inter alia, the
`
`testimony of Nancy Miracle. Ex. 2001.
`
`II.
`
`ANALYSIS
`
`A.
`
`Claim Construction
`
`The parties agree that the ’686 patent expired. Pet. 5; Prelim. Resp.
`2. Accordingly, we construe its challenged claims as they would be
`
`2 WO 94/11814 (May 26, 1994) (“Aldred”; Ex. 1009).
`3 Request for Comments (RFC) 1692 (Aug. 1994) (“RFC 1692”; Ex. 1010).
`4 US 5,466,200 (Nov. 14, 1995) “Ulrich”; Ex. 1012).
`SUS 5,307,413 (Apr. 26, 1994) (“Denzer”; Ex. 1014).
`6 Petitioner superfluously cites the “Knowledge of an Ordinary Artisan,”
`which wedonot repeat, as an obviousness determination takes into account
`that knowledge.
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`construed in district court. See 37 C.F.R. § 42.100(b) (permitting a “district
`
`court-type claim construction approach. . . if a party certifies that the
`involved patent will expire within 18 months from the entry of the Notice of
`
`Filing Date Accorded to Petition”).
`In district court, claim termscarry their plain and ordinary meaning
`as would be understood by a person ofordinary skill in the art at the time of
`the invention and in the contextof the entire patent disclosure. Phillipsv.
`AWHCorp., 415 F.3d 1303, 1313 (Fed. Cir. 2005) (en banc). “There are
`only two exceptionsto this general rule: 1) when a patentee sets out a
`definition and acts as his own lexicographer, or 2) when the patentee
`disavowsthe full scope of a claim term either in the specification or during
`prosecution.” Thorner v. Sony Comput. Entm’t Am. LLC, 669 F.3d 1362,
`1365 (Fed. Cir. 2012). Only terms in controversy must be construed and
`only to the extent necessary to resolve the controversy. Vivid Techs., Inc.v.
`Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999).
`Petitioner notes Patent Owner“advanced several constructionsfor. .
`
`Inits
`. claim elements”in prior district court litigation. See Pet. 5-6.
`Petition, Petitioner generally contends the “precise scope”ofthe terms need
`not be determined, provided the termstrack “any interpretation consistent
`with their plain and ordinary meaning in the context ofthe [’]686 [p]atent.”
`Id.
`
`In its Preliminary Response, Patent Ownerproposesconstructions for
`several terms. Prelim. Resp. 3-13. After determining via a teleconference
`with the parties that with respect to three claim terms, Patent Owner’s
`proposed constructions differed from whatit providedin prior district court
`litigation (Paper 8), we authorized the filing of a Preliminary Reply by
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`Petitioner (Paper 9 (“Prelim. Reply”)) and a Sur-Reply by Patent Owner
`(Paper 10 (“Sur-Reply”)). The claim termsat issue in this proceeding and
`addressed by thebriefing include “aggregated payload,” “aggregated
`message,”and “payloadportion.” Prelim. Reply 1. As discussed below,in
`general, the Specification, Petition, Preliminary Response, evidence, and
`additional briefing show collectively that the constructionof the three terms
`turns on similar evidence and includes the overlapping issue of a transport
`layer header. Wealso construe the claim term “group messaging server”
`addressed by Patent Owner with respect to claim 12. Prelim. Resp. 3-4.
`1. “aggregated payload”
`Asindicated above, the Petition contends the term “agsregated
`payloads” should carry its “plain and ordinary meaningin the context of the
`°686 patent,” but the Petition does not set forth an explicit claim
`construction. See Pet. 6—7. Patent Owner contends“aggregated payload”
`should be construed as “[a] collection of two or more dataitems that does
`not include transport layer headers.” Prelim. Resp. 11 (emphasis added).
`To support its construction, Patent Owner contendsthat
`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 andare aggregated to be included into a
`single message with a single message headerto besent to a
`host, where the message includes payload portions from the
`messagessent by the hosts.
`Id. at 12.
`. describes
`.
`Patent Ownerexplainsfurther that “the specification .
`that transport layer headers are removed from messagessent to the
`group messaging server.” Id. (citing Ex. 1002, 20:14-30; Ex. 2001 q41 38,
`41). Patent Owneralso contends that the Specification describes removing
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`“payload items from a message queue 143” and then aggregating them after
`accumulating them in an aggregation buffer. See id. (quoting Ex. 1002,
`
`23:53-55) (emphasis omitted).
`The Specification explains that “[t]he effect of aggregation will be to
`greatly reduce the total messagerate received by the hosts,” because “[a]
`single message to a host will... carry multiple payload items received from
`the other hosts.” Ex. 1002, 24:12-15. Another benefit involves reducing
`
`the total data rate, because “aggregation eliminates the need for separate
`message headers for each payload item.” Jd. at 24:24—-25. This results in
`“significant” savings for “small payload items [because] there will be only
`one message header comprisingfields 123, 124, and 125 for multiple
`payload items.” Jd. at 24:26-28.
`In its Preliminary Reply, Petitioner essentially contends “aggregated
`payload”should be construed as “[a] collection of two or more data items.”
`See Pet. Prelim. Reply 1. Petitioner notes that in priorlitigation, Patent
`Ownersubmitted a construction for “aggregating said payload portions”
`without submitting the negative limitation regarding the “transport layer
`header” requirements. See id. at 2 (citing Ex. 1016, 93, 121-22). Petitioner
`contends these “prior positions” undermine Patent Owner’s position in this
`proceeding. See id. Petitioner also argues Patent Owner should be
`judicially estopped from narrowing its claim constructionin this proceeding
`relative to its proposed claim constructionsin priorlitigation. See id. at 2-3
`(asserting Patent Owner“has persuaded a court to acceptits positions”).
`Turning to the specification, Petitioner contendsthat “the ’686 patent
`explainsthat the Internet Protocol (IP) and conventional networking use the
`OSI reference modelfor layers of network protocols.” Jd. at 4 (citing Ex.
`
`10
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`1002, 3:29-54 (citing RFC 791)). Further, according to Petitioner, in OSI
`
`network layers, “an IP packet payload may be an entire TCP packet
`including a TCP headerand payload.” Jd. (citing Ex. 1011 (RFC 791), 1).
`Furthermore, Petitioner contends, the Preliminary Response annotates
`Figure 9, and it showsthat “[t]he aggregated payload includes payload
`elements (red) that comprise the ‘actual data’ of the payload (119 & 122)
`and headerinformation (117, 118, 120, 121), such as a source address and
`length of data in the payload.” Jd. (citing Prelim. Resp. 8; Ex. 1002,Fig.9,
`
`14:38-51).
`In its Preliminary Sur-Reply, Patent Ownerreplies that judicial
`estoppel should not and does notapply, arguing, interalia, that “issues with
`respect to the headers .
`.
`. were not addressedin the prior proceedings,” and
`none ofthe previous claim construction ordersin priorlitigation constitutes
`a final judgement. See PO Prelim. Sur-Reply 1-3. Patent Ownerfurther
`
`replies:
`[t]he annotation of Figure 9 does not concedethat the recited
`terms comprise encapsulated headers, but merely describes that
`the Source ULP Addresses by themselves do not comprise a
`transport layer message headeras described with respectto the
`referenced discussions of the OSI reference model. Jd. The
`transport layer message header includesthe fields 123-128 as
`previously discussed.
`
`PO Prelim. Sur-Reply 4—5 (citing Prelim. Resp. 7-8, Ex. 2001 J 34-36).
`Patent Owner also argues that the Specification describes significant
`savings “for small payload items [because] there will be only one message
`
`header.” Jd. at 5.
`
`Figure 9, annotated by Patent Owner, follows:
`
`11
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`
`124
`5
`126
`?
`ra
`~~
`Tearsport|ULP tan.|Cet. ULF|Anctess|Oeetisation
`eader Type|Adress|Coun|avornsst|°°" *
`
`
`
`
` ws 148
`316
`
`and
`
`
`
`
`Shassege |Kocrce UP|Date HSoucotAP| Oate
`
`
`Count|]Addess1|tengha|USPEES” f] Address. N|LengN
`
`
`
`
`WwW
`
`as
`
`Figure 9
`
`Asannotated and described by Patent Owner, Figure 9 shows a message
`with message header 123-128 (blue), a payload 129 (green) with atleast
`two payloads (red), one having mini-headers 117 and 118 and data portion
`119, and another having mini-headers 120 and 122 and data portion 122.
`
`See Ex. Prelim. Resp. 7-8; 1002, 14:37-50.
`As Patent Ownerargues, Figure 9 of the Specification does not
`include a TLP header in each payload packetof the aggregated payload.
`See Prelim. Resp. 7-8. Nonetheless, as noted above, header, such as
`headers 117 and 118, or 120 and 122, appear in each payload. See Ex.
`
`1002, 23:11-12 (“Each payload item in a message queue will contain a
`ULPsource address, a data length and the data to be sent.”). Even though
`an embodimentstrips out a TLP header from a “message,”it also looksup a
`TLP headerofthe host from “host address map 137.” Jd. at 23:20-22. The
`Specification consistently showsthat a payload, even within an aggregated
`payload, may contain headerfields.
`See, e.g., id. at Fig. 9.
`In addition, the preliminary record supports Petitioner’s argument
`that the Specification describes using the OSI model, which appears to
`include encapsulating a TCP header and data as a data portion of a
`
`12
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`datagram. For example, as Petitioner states that the Specification explains
`that “the Internet Protocol (IP) and conventional networking use the OSI
`reference modelfor layers of network protocols.” Pet. Prelim. Reply 4
`
`(citing Ex. 1002, 3:24--50, and noting that portion cites RFC 791). As
`
`Petitioner explains,
`OSI networklayers are hierarchical: an IP packet payload may
`be an entire TCP packet including a TCP header and payload.
`E.g., Ex. 1011 (RFC 791), 1 (“[T]he [IP] module [could] take a
`TCP segment(including the TCP header anduser data) as the
`data portion of an [IP] datagram.”). A “payload portion” could
`thus comprise a TCP header, and an “aggregated
`payload’”/“aggregated message” could have multiple TCP
`headers.
`
`Id.
`
`Furthermore, Petitioner asserts “Patent Owner’s Preliminary
`Response concedesthese [claim] terms can comprise encapsulated
`
`headers.” Jd.
`
`Patent Ownerdoes not dispute, in a clear fashion, Petitioner’s
`contention that the claims may encompass encapsulated headers. See PO
`Prelim. Sur-Reply 4. (“The annotation ofFigure 9 does not concede that
`the recited terms comprise encapsulated headers, but merely describes that
`the Source ULP Addresses by themselves do not 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 payloadsthat include
`headers (e.g., address information, message type), as discussed above. See
`supra Section I.C.; Ex. 1002, 13:59-62, 14:38-62.
`
`13
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`Regarding Patent Owner’s argument that excluding a TLP header
`
`creates data reduction, the challenged claims do notlimit the payload size
`
`and generally allow for different header types according to the
`Specification. See, e.g., Ex. 1002, 14:38-47. The Specification describes
`any data reduction assignificant only for small packet sizes, and generally
`attributes data reductions due to message aggregation. Jd. at 24:23—28. In
`other words, the Specification generally describes savings based on
`aggregation for all packet sizes based on “greatly reduc[ing] the total
`message rate received by the hosts,” because “[a] single messageto a host
`will be able to carry multiple payload items received from the other hosts
`during the aggregation period.” Jd. at 24:12—-15. The Specification
`therefore does not limit an aggregated payload, as claimed, from including
`headersin general, including transport layer headers.’
`Onthis record, the °686 Specification supports Petitioner’s argument
`that the claim term “aggregated payload,” consistent with its ordinary and
`plain meaning, encompasses a collection of two or more data itemsthat
`may include headerstransported as data. Patent Owner’s past claim
`construction positions support this preliminary determination by showing,
`at the least, how Patent Owner viewed the meaning of various claim terms,
`
`including the three terms discussedherein.
`
`7 The Federal Circuit instructs that simply describing alternative features
`without articulating advantages or disadvantages of each feature cannot
`support a negative limitation. Inphi Corp. v. Netlist, Inc., 805 F.3d 1350,
`1356-57 (Fed.Cir. 2015). To the extent that excluding multiple TLP
`headers involves data reduction, allowing some header types within the
`scope of the claim defeats any advantage of removingaspecific type from
`that scope.
`
`14
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`2.
`
`“aggregated message”
`
`Patent Owner contends “aggregated message” means “[o]ne or more
`messages containinga single transport layer message header,destination
`data, and data items from an aggregated payload.” Prelim. Resp. 5. Patent
`Ownerrelies on Figure 7 of the Specification as providing an example:
`Each of the messages 100, 101, 102, and 103 received by a
`host from a server includes the aggregated payloads (Pni, Pm,
`Pn3) in each message and a headerportion 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.
`Prelim. Resp. 6—7 (citing Ex. 1002, 8:1-10:67, Fig. 7).
`Similar to its arguments with respect to the “aggregated payload”as
`discussed above, Petitioner respondsthatin priorlitigation, Patent Owner
`submitted a construction for “aggregated message” without submitting the
`“transport layer header” requirements. See Pet. Prelim. Reply 2-3 (citing,
`e.g., Ex. 1016, 93). Petitioneralso relies on the similar evidence and
`reasons addressed above regarding the “aggregated payload,” showing on
`this preliminary record,that the Specification and evidence support an
`“aporegated message”as including an aggregated payloadandat least one
`headerin addition to any that may happen to be within the aggregated
`payload. See id. at 1-5; Ex. 1016, 93; Ex. 1002, Fig. 7. In other words, as
`noted above, a payload may include a header, for example, “a triplet of
`source ULP address, data length and data.” Ex. 1002, 14:40-42 (discussing
`items 117, 118, and 119). Typically, a packet message includesat least one
`header. See Pet. Prelim. Reply 4; Ex. 1016, 93; Ex. 1002, 3:24—52,Fig. 7.
`
`
`
`IPR2018-00132
`. Patent 6,226,686
`
`For the reasons similar to those explained above in construing an
`“ageregated payload,” an “aggregated message” includes a message having
`an aggregated payload and at least one header in addition to any additional
`headers that may happento be within the aggregated payload.
`
`3.
`“payload portion”
`Patent Owner submits a “payload portion” means “[a] portion of the
`original network message (that contains data item(s) conveying
`information) sent to the group messaging server remaining after the
`
`transport layer
`header is removed.” Prelim. Resp. 9-10. Aspart of its showing, Patent
`Owneracknowledgesthat “[a]n agreed construction in [previous] litigation
`for ‘payload portion’ was‘[t]he part of a message that containsdata item(s)
`conveying information.’” Jd. at n.1 (citing Ex. 1032, 2).
`As discussed above in connection with an “aggregated payload” and
`
`an “aggregated message,” Petitioner respondsthatin priorlitigation, Patent
`Ownersubmitted a construction for “payload portion” without submitting
`the “transport layer header” requirements. See Pet. Prelim. Reply 1-3
`(citing, e.g., Ex. 1032, 2). Petitioner also relies on the similar reasons and
`evidence addressed above regarding the “aggregated payload.” See id. at 3—
`
`5.
`
`Patent Owner’s proposed claim construction improperly requires
`functionality related to the group server. In other words, “[a] portion of the
`original network message: .
`. sent to the group messaging server remaining
`after the transport layer header is removed”(Prelim. Resp. 9-10) includes
`header removal steps, presumablyat the server. However, the addition of
`server functionality included in Patent Owner’s proposed construction does
`
`16
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`not embodythe ordinary and customary meaningin light of the claim
`language and specification. As noted above, a payload may include headers
`such as “a triplet of source ULP address, data length and data.” Ex. 1002,
`
`14:40-42 (discussing items 117, 118, and 119).
`
`For additional reasons similar to those explained above with respect
`
`to “aggregated payload” and “aggregated message,” on this preliminary
`record, and tracking language proposed by Patent Ownerin previous
`litigation, a “payload portion” includes “[t]he part of a message that
`contains data item(s) conveying information.” See Ex. 1002, 14:40-42
`
`(discussing items 117, 118, and 119); Ex. 1032, 2.
`4.
`“group messaging server”(claim 12)
`
`Claim 12 recites a method for “providing group messages to a
`plurality of host computers connected to a group messaging server over a
`unicast wide area communication network” comprising a step of
`
`“communicating with the plurality of host computers using the unicast
`network and maintaining a list of message groups, each message group
`
`containing at least one host computer.” Ex. 1002, 29:21—28.
`Patent Ownerproposesthe following construction for “group
`
`messaging server”:
`A server or computer system with a network interface that
`maintains a set of message groups used by the host computers
`to communicate information between themselves. The group
`messaging server must be capable of receiving messages from
`the host computers addressed to a message group and sending
`messages to the host computers that have joined the message
`group. A group messaging server can process messages with
`or without aggregated payloads, and can allow for group
`membership to change very rapidly.
`Prelim. Resp. 3-4.
`
`17
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`Patent Owner contendsthe construction “is consistent with the
`
`disclosure of the 686 patent.” Jd. at 4 (citing Ex. 2001 § 27). Patent
`
`Ownerand Ms. Miracle do not provide any citations to the °686 patentto
`support the proposed construction. Patent Owneralso contendsthat another
`party and Patent Owneragreed to the construction in priorlitigation. Id.
`
`(citing Ex. 1032, 1-2).
`However, the proposed construction improperly incorporates
`unclaimedlimitations from the Specification. The Specification states “[i]n
`
`a preferred embodiment, the [GMS]is a general purpose computer system
`with a networkinterface to connectit to a wide area network.” Ex. 1002,
`
`16:1-3. Figure 10 illustrates a GMS with Item 136, an overall! control
`function for the [GMS], and “NetworkInterface” 135. The GMSincludes
`addresses and groupserver control functionality for hosts. See id., Fig. 10.
`Accordingly, on this preliminary record, the ordinary meaning of a
`GMSinlight of the ’686 patent Specification is a “server” or “general
`purpose computersystem that provides group messaging capability,” as
`
`recited in claim 12.
`
`B.
`
`Asserted Obviousness over Aldred, and RFC 1692; Aldred,
`RFC 1692 and Ulrich; or Aldred, RFC 1692 and Denzer
`
`Petitioner alleges that claims 1, 3, 7, 12, 18, 26, 27, 45, 46, 62, and
`63 would have been obvious over Aldred and RFC 1692 as viewed by the
`knowledge of an ordinaryartisan. Pet. 21-51. Petitioner also alleges that
`claims 22-27, 41-46, and 58-63 would have been obviousoverthe
`combination of Aldred, RFC 1692 in further view of Ulrich; and that claims
`
`36 and 55 would have been obvious over the combination of Aldred, RFC
`
`1692 in further view of Denzer. Pet. 51-69. Patent Ownerraises several
`
`18
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`arguments in response. Prelim. Resp. 13-50. Brief overviews of Aldred,
`
`RFC 1692, Ulrich and Denzerfollow, followed by an analysis of the
`
`parties’ contentions regarding the challenged claims.
`
`1.
`
`Aldred
`
`Aldred,titled, “Collaborative Working in a Network,” published as
`
`an International Application on May 26, 1994 from an application filed on
`November 10, 1993. Ex. 1009, at [54], [43], [22]. Aldred relates to a
`“programmable workstation for collaborative working in a network,” which
`includes a “collaborative application support subsystem for interfacing with
`
`application programs,” wherein the subsystem “is responsive to
`predetermined application program calls to create a logical network model
`of a collaborative environment” that comprises a “sharing set of application
`programs, which share data and resources across nodesandlogical
`dedicated data channels connecting membersofthe sharingset.” Ex. 1009,
`at [57].
`Figures 3 and 4, reproduced below, show a logical network model
`that comprises sharing sets of application programs between various nodes.
`
`CALL MANAGER
`SUPPORT SYSTEM
`
`,
`
`8
`
`r
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`
`
`FIG, 4
`
`
`
`Figure 3 depicts aware applications sharing data and resources
`between nodes A, B, C, D, and E. Jd. at 5-6. Figure 4 depicts the two
`sharing sets resulting from the sharing of the aware applicationsin Figure 3.
`
`Id.
`
`An aware application initiates a share request, naming an application
`sharing set, a target application and a destination node. Jd. at 5. Support
`software passes the request to a call managerat the sending node, which
`then transfers it to the call managerat the destination node. /d. The sharing
`mechanism can be cascaded; for example, two sharing applications can
`initiate a share with a third application naming the same sharing set, with
`the result that all three applications then share with each other. Id.
`Applications in a sharing set establish data communicationlinks with
`each other known as channels. Jd. at 6. As shownin Figures 3 and 4,
`
`various channels link aware applications at nodes A,B, C, and E, and one
`channel links aware applications at nodes D and E. See Figure 3 and 4. In
`particular, various channels link aware application 1 at node A, aware
`application 2 at node B, aware applications 3 and 4 at node C, and aware
`application 8 at node E, whichall belong to the same sharingset. One
`
`20
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`channellinks aware application 7 at node D and aware application 9 at node
`
`E, which belong to the same sharing set. Jd.
`A serializing channel set feature combines data packets from
`different channels, and deliver serialized packets to each application such
`that each receiving port receives the same sequenceof data. Jd. at 7.°
`Throughthis synchronizing features, “data packets on separate channels are
`tied together in time (for example, voice with video), but delivered through
`the individual ports belonging to the channels.” Jd.
`Figure 6, reproduced below, provides an example of a shared
`drawing board usingserializing channel set 59 consisting of channels 57
`
`and 58:
`
` APPLICATION A ogst, 5
`
`Wit