`Tel: 571-272-7822
`
`Paper 11
`Entered: May 15, 2018
`
`
`
`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 & 6,226,686 C11
`_______________
`
`
`Before THU A. DANG and KARL D. EASTHOM,
`Administrative Patent Judges.
`
`DANG, Administrative Patent Judge.
`
`
`
`DECISION
`Institution of Inter Partes Review
`35 U.S.C. § 314(a)
`
`
`
`
`1 The Petition challenges original claims and claims issued pursuant to an
`ex parte reexamination.
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`
`I.
`
`INTRODUCTION
`
`Background
`A.
`Riot Games Inc. (“Petitioner”) filed a Petition requesting an inter
`partes review of claims 1–4, 7–21, 28–35, 39, 40, 47–54, 56, 57, and 64–70
`of U.S. 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 under 35 U.S.C. § 314, which provides that an
`inter partes review may not be instituted “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
`reasonable likelihood that it would prevail in showing the unpatentability of
`at least one of the challenged claims. Accordingly, we grant the Petition.
`
`Related Proceedings
`B.
`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-00132,
`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.
`
`
`
`1
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`
`Petitioner also states that the following cases involve the ’523 and
`’686 patents: PalTalk Holdings, Inc. v. Valve Corporation, No. 16-cv-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.
`
`The ’686 Patent
`C.
`The ’686 patent issued on May 1, 2001, from an application filed
`September 28, 1999, and claims priority to parent application No.
`08/896,797, filed on July 18, 1997, now US 6,018,766, which in turn is a
`continuation of application No. 08/595,323, filed on February 1, 1996, now
`US 5,822,523. Ex. 1002, [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.” Id. at [57].
`Figure 5, reproduced below, illustrates a unicast network over which the
`interactive applications may be deployed.
`
`
`
`2
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`
`
`
`
`
`
`Figure 5 depicts a wide area network with hosts 58, 59, 60, and 61, and a
`group messaging server (“GMS”) 62. Id. at 8:65–66. Host 58 has Transport
`Level Protocol (TLP) address A and Upper Level Protocol (ULP) address H.
`Id. at 8:66–67. Host 59 has TLP address C and ULP address J, host 60 as
`TLP address B and ULP address I, host 61 has TLP address D and ULP
`address K, and GMS 62 has TLP address S. Id. 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.
`GMS “62 receives messages from the hosts addressed to a message group
`and sends the contents of the messages to the members of the message
`group.” Id. 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.
`
`
`
`3
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`
`
`
`
`Figure 7 shows GMS (“Group Server”) 62 receiving multiple messages 96,
`97, 98, and 99 before sending them to hosts within message group G. Id. at
`9, 18–20, 10:24–28. As shown in 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 (shown in Figure 7 as “Host A sends”), host 60 sends
`message 97 (shown in 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
`(shown in Figure 7 as “Host D sends”), wherein each of the messages from
`the hosts has destination TLP address S and ULP address G for GMS 62. Id.
`at 10:28–32. After GMS 62 receives all four of these messages, it creates
`four outbound messages 100, 101, 102, and 103. Id. at 10:33–34.
`
`
`
`4
`
`
`
`IPR2018-00131
`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. Id. at 10:38–40. Aggregated
`message 101 targets host 60, aggregated message 102 targets host 59, and
`aggregated message 103 targets host 61. Id. at 10:41–42.
`Figure 9, reproduced below, depicts a datagram format and address
`format for ULP messages.
`
`
`
`
`
`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 count field 126, auxiliary
`destination address 127 and 128, and finally payload 129. Id. 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 contained in
`the pay load. Items 117, 118, and 119 comprise the first payload element in
`the payload, and items 120, 121, and 112 comprise the last payload element
`
`
`
`5
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`in the payload. Id. at 14:39–48. In particular, item 117 specifies the ULP
`address of the source of 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 of
`the 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. Id.
`
`The Challenged Claims
`D.
`Of the challenged claims, claims 1, 3, 7, 12, and 18 are the independent
`
`claims at issue. Claim 1 is illustrative of the challenged claims, and is
`reproduced below:
`
`A method for facilitating communications among a
`1.
`plurality of host computers over a network to implement a shared,
`interactive application, comprising the steps of:
`(1) receiving a create message from one of the plurality of host
`computers, wherein said create message specifies a message group to
`be created;
`(2) receiving join messages from a first subset of the plurality of
`host computers, wherein each of said join messages specifies 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 message using said aggregated
`payload; and
`(6) transmitting said aggregated message to said first subset of
`the plurality of host computers belonging to said message group;
`wherein said aggregated message keeps the shared, interactive
`
`
`
`6
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`
`application operating consistently on each of said first subset of the
`plurality of host computers.
`Ex. 1002, 27:50–28:8.
`Asserted Grounds of Unpatentability
`E.
`Petitioner contends that the challenged claims are unpatentable based
`on the following specific grounds (Pet. 20, 52):
`
`Reference
`
`Aldred,2 and RFC 16923
`
`Basis Claim Challenged
`§ 103 1–4, 7–21, 28–30, 34, 35, 39, 40, 47–49,
`53, 54, 56, 57, 64–66, and 70
`Aldred, RFC 1692, and RFC 14594 § 103 31–33, 50–52, and 67–69
`
`Petitioner also relies on the testimonies of Dr. Steve R. White and
`David H. Crocker.5 Exs. 1007, 1026. Patent Owner relies on, inter alia, the
`testimony of Nancy Miracle. Ex. 2001.
`
`II. ANALYSIS
`
`Claim Construction
`A.
`The parties agree that the ’686 patent expired. Pet. 5; Prelim. Resp. 2.
`Accordingly, we construe its challenged claims as they would be 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
`
`
`2 WO 94/11814 (May 26, 1994) (“Aldred”; Ex. 1009).
`3 Request for Comments (RFC) 1692 (Aug. 1994) (“RFC 1692”; Ex. 1010).
`4 Request for Comments (RFC) 1459 (May 1993) (“RFC 1459”; Ex. 1025).
`5 Petitioner superfluously cites the “Knowledge of an Ordinary Artisan,”
`which we do not repeat, as an obviousness determination takes into account
`that knowledge.
`
`
`
`7
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`will expire within 18 months from the entry of the Notice of Filing Date
`Accorded to Petition”).
`In district court, claim terms carry their plain and ordinary meaning as
`would be understood by a person of ordinary skill in the art at the time of the
`invention and in the context of the entire patent disclosure. Phillips v. AWH
`Corp., 415 F.3d 1303, 1313 (Fed. Cir. 2005) (en banc). “There are only two
`exceptions to this general rule: 1) when a patentee sets out a definition and
`acts as his own lexicographer, or 2) when the patentee disavows the 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 constructions for . . .
`claim elements” in prior district court litigation. See Pet. 5. In its Petition,
`Petitioner generally contends the “precise scope” of the terms need not be
`determined, provided the terms track “any interpretation consistent with
`their plain and ordinary meaning in the context of the [’]686 [p]atent.” Id. at
`5–6.
`
`In its Preliminary Response, Patent Owner proposes constructions 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 what it provided in prior district court
`litigation (Paper 8), we authorized the filing of a Preliminary Reply by
`Petitioner (Paper 9 (“Prelim. Reply”)) and a Sur-Reply by Patent Owner
`(Paper 10 (“Sur-Reply”)). The claim terms at issue in this proceeding and
`
`
`
`8
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`addressed by the briefing include “aggregated payload,” “aggregated
`message,” and “payload portion.” Prelim. Reply 1. As discussed below, in
`general, the Specification, Petition, Preliminary Response, evidence, and
`additional briefing show collectively that the construction of the three terms
`turns on similar evidence and includes the overlapping issue of a transport
`layer header. We also construe the claim term “group messaging server”
`addressed by Patent Owner with respect to claim 12. Prelim. Resp. 3–4.
`1. “aggregated payload”
`As indicated above, the Petition contends the term “aggregated
`payloads” should carry its “plain and ordinary meaning in 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 data items that does
`not include transport layer headers.” Prelim. Resp. 11 (emphasis added).
`To support its construction, Patent Owner contends 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 to be included into a
`single message with a single message header to be sent to a
`host, where the message includes payload portions from the
`messages sent by the hosts.
`
`Id. at 12.
`Patent Owner explains further that “the specification . . . describes that
`transport layer headers are removed from messages sent to the
`group messaging server.” Id. (citing Ex. 1002, 20:14–30; Ex. 2001 ¶¶ 38,
`41). Patent Owner also contends that the Specification describes removing
`“payload items from a message queue 143” and then aggregating them after
`
`
`
`9
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`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 message rate 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.” Id. at 24:23–25. This results in
`“significant” savings for “small payload items [because] there will be only
`one message header comprising fields 123, 124 and 125 for multiple payload
`items.” Id. 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 prior litigation, Patent
`Owner submitted 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 construction in this proceeding relative to
`its proposed claim constructions in prior litigation. See id. at 2–3 (asserting
`Patent Owner “has persuaded a court to accept those positions”).
`Turning to the Specification, Petitioner contends that “the ’686 patent
`explains that the Internet Protocol (IP) and conventional networking use the
`OSI reference model for layers of network protocols.” Id. at 4 (citing Ex.
`1002, 3:29–54 (citing RFC 791)). Further, according to Petitioner, in OSI
`
`
`
`10
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`network layers, “an IP packet payload may be an entire TCP packet
`including a TCP header and payload.” Id. (citing Ex. 1011 (RFC 791), 1).
`Furthermore, Petitioner contends, the Preliminary Response annotates Figure
`9, and it shows that “[t]he aggregated payload includes payload elements
`(red) that comprise the ‘actual data’ of the payload (119 & 122) and header
`information (117, 118, 120, 121), such as a source address and length of data
`in the payload.” Id. (citing Prelim. Resp. 8; Ex. 1002, Fig. 9, 14:38–51).
`
`In its Preliminary Sur-Reply, Patent Owner replies that judicial
`estoppel should not and does not apply, arguing, inter alia, that “issues [with
`respect] to the headers . . . were not addressed in the prior proceedings,” and
`none of the previous claim construction orders in prior litigation constitutes
`a final judgement. See PO Prelim. Sur-Reply 1–3. Patent Owner further
`replies:
`[t]he annotation of Figure 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. Id. The
`transport layer message header includes the fields 123–128 as
`previously discussed.
`
`PO Prelim. Sur-Reply 4–5 (citing Prelim. Resp. 7–9, Ex. 2001 ¶¶ 34–36).
`Patent Owner also argues that the Specification describes significant
`savings “for small payload items [because] there will be only one message
`header.” Id. at 5.
`Figure 9, annotated by Patent Owner, follows:
`
`
`
`11
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`
`
`
`
`As annotated and described by Patent Owner, Figure 9 shows a message
`with message header 123–128 (blue), a payload 129 (green) with at least 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
`Prelim. Resp. 7–8; Ex. 1002, 14:37–50.
`
`As Patent Owner argues, Figure 9 of the Specification does not
`include a TLP header in each payload packet of 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 [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 also 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 within an aggregated payload, may contain header fields. 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 datagram. For
`
`
`
`12
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`example, Petitioner states that the Specification explains that “the Internet
`Protocol (IP) and conventional networking use the OSI reference model for
`layers of network protocols.” Pet. Prelim. Reply 4 (citing Ex. 1002, 3:29–
`54, and noting that portion cites RFC 791). As Petitioner explains,
`OSI network layers 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 and user 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
`concedes these [claim] terms can comprise encapsulated headers.” Id.
`Patent Owner does not dispute, in a clear fashion, Petitioner’s
`contention that the claims may emcompass encapsulated headers. See PO
`Prelim. Sur-Reply 4. (“The annotation of Figure 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 payloads that include
`headers (e.g., address information, message type), as discussed above. See
`supra Section I.C.; Ex. 1002, 13:59–62, 14:38–62.
`Regarding Patent Owner’s argument that excluding a TLP header
`creates data reduction, the challenged claims do not limit the payload size
`and generally allow for different header types according to the Specification.
`
`
`
`13
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`See, e.g., Ex. 1002, 14:38–47. The Specification describes any data
`reduction as significant only for small packet sizes, and generally attributes
`data reductions due to message aggregation. Id. 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 message to a host will be able to
`carry multiple payload items received from the other hosts during the
`aggregation period.” Id. at 24:12–15. The Specification therefore does not
`limit an aggregated payload, as claimed, from including headers in general,
`including transport layer headers.6
`
`On this 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 items that may
`include headers transported 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 discussed herein.
`2. “aggregated message”
`Patent Owner contends “aggregated message” means “[o]ne or more
`
`messages containing a single transport layer message header, destination
`
`6 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 removing a specific type from
`that scope.
`
`
`
`
`14
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`data, and data items from an aggregated payload.” Prelim. Resp. 5. Patent
`Owner relies 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 (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.
`
`
`
`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 responds that in prior litigation, 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). Petitioner also 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
`“aggregated message” as including an aggregated payload and at least one
`header in 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 includes at least one
`header. See Pet. Prelim. Reply 4; Ex. 1016, 93; Ex. 1002, 3:24–52, Fig. 7.
`For reasons similar to those explained above in construing an
`“aggregated payload,” an “aggregated message” includes a message having
`an aggregated payload and at least one header in addition to any additional
`headers that may happen to be within the aggregated payload.
`
`
`
`15
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`
`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. As part of its showing, Patent
`Owner acknowledges that “[a]n agreed construction in [previous] litigation
`for ‘payload portion’ was ‘[t]he part of a message that contains data item(s)
`conveying information.’” Id. at n.1 (citing Ex. 1032, 2).
`
`As discussed above in connection with an “aggregated payload” and
`an “aggregated message,” Petitioner responds that in prior litigation, Patent
`Owner submitted 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, presumably at the server. However, the addition of
`server functionality included in Patent Owner’s proposed construction does
`not embody the ordinary and customary meaning in 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).
`
`
`
`16
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`
`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 Owner in 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 Owner proposes the 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.
`Patent Owner contends the construction “is consistent with the
`disclosure of the ’686 patent.” Id. at 4 (citing Ex. 2001 ¶ 27). Patent Owner
`and Ms. Miracle do not provide any citations to the ’686 patent to support
`
`
`
`17
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`the proposed construction. Patent Owner also contends that another party
`and Patent Owner agreed to the construction in prior litigation. Id. (citing
`Ex. 1032, 1–2).
`
`However, the proposed construction improperly incorporates
`unclaimed limitations from the Specification. The Specification states “[i]n
`a preferred embodiment, the [GMS] is a general purpose computer system
`with a network interface to connect it 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 “Network Interface” 135. The GMS includes
`addresses and group server control functionality for hosts. See id., Fig. 10.
`
`Accordingly, on this preliminary record, the ordinary meaning of a
`GMS in light of the ’686 patent Specification is a “server or general purpose
`computer system 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–4, 7–21, 28–30, 34, 35, 39, 40, 47–49,
`53, 54, 56, 57, 64–66, and 70 would have been obvious over Aldred and
`RFC 1692 as viewed by the knowledge of an ordinary artisan. Pet. 18–61.
`Petitioner also alleges that claims 31–33, 50–52, and 67–69 would have been
`obvious over the combination of Aldred, RFC 1692 in further view of RFC
`1459. Pet. 61–69. Patent Owner raise several arguments in response.
`Prelim. Resp. 13–52. Brief overviews of Aldred, RFC 1692, and RFC 1459
`follow, followed by an analysis of the parties’ contentions regarding the
`challenged claims.
`
`
`
`18
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`
`Aldred
`1.
`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 nodes and logical dedicated
`data channels connecting members of the sharing set.” 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.
`
`
`
`
`
`19
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`
`
`Figure 3 depicts aware applications sharing data and resources
`between nodes A, B, C, D, and E. Id. at 5–6. Figure 4 depicts the two
`sharing sets resulting from the sharing of the aware applications in Figure 3.
`Id.
`
`An aware application initiates a share request, naming an application
`sharing set, a target application and a destination node. Id. at 5. Support
`software passes the request to a call manager at the sending node, which
`then transfers it to the call manager at the destination node. Id. 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 communication links with each
`other known as channels. Id. at 6. As shown in 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, which all belong to the same sharing set. One channel links aware
`
`
`
`20
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`application 7 at node D and aware application 9 at node E, which belong to
`the same sharing set. Id.
`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 sequence of data. Id. at 7.7 Through this
`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.” Id.
`Figure 6