Trials@uspto.gov
`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.
`
`
`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
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
