`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-00132
`Patent 6,226,686 & 6,226,686 C11
`_______________
`
`
`Before THU A. DANG and KARL 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-00132
`Patent 6,226,686
`
`
`I.
`
`INTRODUCTION
`
`Background
`A.
`Riot Games Inc. (“Petitioner”) filed a Petition requesting an inter
`partes review of claims 1, 3, 7, 12, 18, 22–27, 36, 41–46, 55, and 58–63 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-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-
`
` 1
`
`
`
`
`
`
`
`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.
`
`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, 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.” Id. at [57].
`Figure 5, reproduced below, illustrates a unicast network over which the
`interactive applications may be deployed.
`
` 2
`
`
`
`
`
`
`
`IPR2018-00132
`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-00132
`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-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. 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 in
`
` 5
`
`
`
`
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`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:
`1.
`A method for facilitating communications among a 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-00132
`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.
`
`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
`
`Aldred,2 and RFC 16923
`
`Basis
`
`§ 103
`
`Claim Challenged
`1, 3, 7, 12, 18, 26, 27, 45, 46, 62,
`and 63
`22–27, 41–46, and 58–63
`36, and 55
`
`Aldred, RFC 1692, and Ulrich4 § 103
`Aldred, RFC 1692, and Denzer5 § 103
`
`Petitioner also relies on the testimonies of Dr. Steve R. White and
`David H. Crocker.6 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
`
`
`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).
`5 US 5,307,413 (Apr. 26, 1994) (“Denzer”; Ex. 1014).
`6 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-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 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–6. 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.
`
`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
`
` 8
`
`
`
`
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`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
`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
`
` 9
`
`
`
`
`
`
`
`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 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:24–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 its 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.
`
`
`
`
`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 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–8, 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-00132
`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 Ex. Prelim. Resp. 7–8; 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 item in a message queue will contain 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
`
`
`
`
`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 model for 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 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 encompass 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.
`
`
`
`
`13
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`
`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. 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.7
`
`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.
`
`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 removing a specific 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 containing a single transport layer message header, destination
`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.
`
`
`
`
`15
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`
`For the 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.
`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
`
`
`
`
`16
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`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).
`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.
`
`
`
`
`17
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`
`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 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, 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 ordinary artisan. Pet. 21–51. Petitioner also alleges that
`claims 22–27, 41–46, and 58–63 would have been obvious over the
`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 Owner raises several
`
`
`
`
`18
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`arguments in response. Prelim. Resp. 13–50. Brief overviews of Aldred,
`RFC 1692, Ulrich and Denzer follow, followed by an analysis of the
`parties’ contentions regarding the challenged claims.
`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-00132
`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
`
`
`
`
`20
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`channel links aware 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 d