Trials@uspto.gov
`Tel: 571-272-7822
`
`Paper 36
`Entered: May 14, 2019
`
`
`
`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-001321
`Patent 6,226,686 & 6,226,686 C12
`_______________
`
`
`Before THU A. DANG, KARL D. EASTHOM, and NEIL T. POWELL,
`Administrative Patent Judges.
`
`DANG, Administrative Patent Judge.
`
`
`
`FINAL WRITTEN DECISION
` Inter Partes Review
`35 U.S.C. § 318(a) and 37 C.F.R. § 42.73
`
`
`
`
`1 The panel joined Petitioner Valve Corp. and Case IPR2018-01243 to the
`instant proceeding. See Paper 34.
`2 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.”). Pursuant to our prior authorization (Paper 8,
`“Order”), Petitioner filed a Reply to the Patent Owner Preliminary Response
`(Paper 9, “Reply to Prelim. Resp.”) as to the issue of Patent Owner’s claim
`constructions, and Patent Owner filed a Preliminary Sur-Reply (Paper 10,
`“Prelim. Sur-Reply”).
`We instituted trial to determine whether claims 1, 3, 7, 12, 18, 22–27,
`36, 41– 46, 55, and 58–63 are unpatentable under 35 U.S.C. § 103 based on
`the combination of Aldred and RFC 1692 either alone or in combination with
`Ulrich or Denzer. See Paper 11 (“Institution Decision” or “Inst. Dec.”).
`After institution of trial, Patent Owner filed a Request for Rehearing. Paper
`14 (“Reh’g. Req.”). We denied Patent Owner’s Request for Rehearing.
`Paper 18 (“Rehearing Decision” or “Reh’g Dec.”).
`Patent Owner then filed a Response. Paper 22 (“PO Resp.”).
`Petitioner filed a Reply to Patent Owner’s Response. Paper 25 (“Pet.
`Reply”). Pursuant to our prior authorization (Paper 26, “Order”), Patent
`Owner filed a Sur-Reply to Petitioner’s Reply (Paper 30, “PO Sur-Reply”).
`Oral argument was conducted on February 13, 2019.
`We have jurisdiction under 35 U.S.C. § 6. This decision is a Final
`Written Decision under 35 U.S.C. § 318(a) as to the patentability of
`
`
`
` 1
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`claims 1, 3, 7, 12, 18, 22–27, 36, 41– 46, 55, and 58–63 of the ’686 patent.
`For the reasons discussed below, we hold that Petitioner has demonstrated by
`a preponderance of the evidence that claims 1, 3, 7, 12, 18, 22–27, 36, 41–
`46, 55, and 58–63 of the ’686 patent are unpatentable under 35 U.S.C.
`§ 103(a).
`
`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 Corp.n, No. 16-cv-1239-JFB-SRF
`(D. Del.) (filed Dec. 16, 2016); PalTalk Holdings, Inc. v. Riot Games, Inc.,
`No. 1:16-cv-1240-JFB-SRF (D. Del.) (filed Dec. 16, 2016); PalTalk
`Holdings, Inc. v. Sony Computer Entertainment America, Inc. et al., No.
`2:09-cv-00274-DF-CE (E.D. Tex.) (filed Sept. 14, 2009); PalTalk Holdings,
`Inc. v. Microsoft Corp., No, 2:06-cv-00367-DF (E.D. Tex.) (filed Sept. 12,
`2006); and Mpath Interactive v. Lipstream Networks, Inc., et al., 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
`
`
`
` 2
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`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], and [63].
`The ’686 patent, titled “Server-Group Messaging System for
`Interactive Applications,” describes a “method for deploying interactive
`applications over a network containing host computers and group messaging
`servers.” Id. at [54], [57]. Figure 5, reproduced below, illustrates a unicast
`network over which the interactive applications may be deployed.
`
`
`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
`
`
`
` 3
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`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.
`
`
`Figure 7 shows GMS (“Group Server”) 62 receiving multiple messages 96,
`97, 98, and 99 before sending them to hosts within message group G.
`
`
`
`
`
` 4
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`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. 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.
`
`
`
`
`
`
`
`
` 5
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`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 payload. 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 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;
`
`
`
` 6
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`
`(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
`application operating consistently on each of said first subset of the
`plurality of host computers.
`Ex. 1002, 27:50–28:8.
`E.
`Instituted Grounds of Unpatentability
`We instituted trial on the following specific grounds (Pet. 21, 51, and
`
`66):
`
`Reference
`
`Aldred,3 and RFC 16924
`
`Aldred, RFC 1692, and Ulrich5
`Aldred, RFC 1692, and Denzer6
`
`Basis Claim(s) Challenged
`§ 103 1, 3, 7, 12, 18, 26, 27, 45, 46, 62,
`and 63
`§ 103 22–27, 41–46, and 58–63
`§ 103 36, and 55
`
`
`3 WO 94/11814 (May 26, 1994) (“Aldred”; Ex. 1009).
`4 Request for Comments (RFC) 1692 (Aug. 1994) (“RFC 1692”; Ex. 1010).
`5 US 5,466,200 (Nov. 14, 1995) (“Ulrich”; Ex. 1012).
`6 US 5,307,413 (Apr. 26, 1994) (“Denzer”; Ex. 1014).
`
`
`
` 7
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`
`
`Petitioner also relies on the testimonies of Dr. Steve R. White.7
`Exs. 1007, 1053. Patent Owner relies on the testimony of Dr. Kevin C.
`Almeroth. Ex. 2002.
`
`II. ANALYSIS
`
`Claim Construction
`A.
`The parties agree that the ’686 patent expired. Pet. 5; PO Resp. 1.
`Accordingly, we construe its challenged claims as they would be construed in
`district court. See 37 C.F.R. § 42.100(b) (2017) (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); Nidec Motor Corp. v. Zhongshan
`
`
`7 Petitioner superfluously cites the “Knowledge of an Ordinary Artisan,”
`which we do not repeat, as an obviousness determination takes into account
`that knowledge.
`
`
`
` 8
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`Broad Ocean Motor Co., 868 F.3d 1013, 1017 (Fed. Cir. 2017) (applying
`Vivid Techs. in the context of an inter partes review).
`Petitioner notes Patent Owner “advanced several constructions for . . .
`claim elements” in prior district court litigation. See Pet. 5–6. 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.
`After determining via a teleconference with the parties that with
`respect to three claim terms, Patent Owner’s proposed constructions in its
`Preliminary Response differed from what Patent Owner provided in prior
`district court litigation (Paper 8, 2–4), we authorized the filing of a
`Preliminary Reply by Petitioner (Paper 9 (“Prelim. Reply”)) and a Sur-Reply
`by Patent Owner (Paper 10 (“Prelim. Sur-Reply”)) to address three terms:
`“aggregated message,” “aggregated payload,” and “payload portion.” In its
`Patent Owner Response (Paper 22, 1–15), Patent Owner maintains the
`constructions for “aggregated message” and “aggregated payload” it
`proposed in its Preliminary Response. As discussed below and as set forth in
`the Institution Decision, the constructions of the terms involve the
`overlapping issue of a transport layer header.
`1.
`“aggregated message”(claims 1, 3, 7, 12);
`“server message” (claim 18)
`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.” PO Resp. 4. 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,
`
`
`
` 9
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`
`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.
`
`
`Id. at 6 (citing Ex. 1002, 8:1–10:67; Fig. 7).
`Patent Owner contends Figure 7 discloses “only a single message
`header consisting of the transport layer protocol source address, the transport
`layer protocol destination address and the ULP address,” which is then
`“combined with the aggregated payload.” Id.
`Patent Owner then relies on Figure 9 of the Specification. Id.
`Figure 9, annotated by Patent Owner, follows:
`
`
`As annotated and described by Patent Owner, Figure 9 shows “an aggregated
`message” which includes “a message header (blue)[,] a payload (green)[,
`with] multiple payload elements (red) included as part of an aggregated
`
`
`
`
`
` 10
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`payload.” Id. at 7 (citing Ex. 1002, 14:37–52).8 Although Patent Owner
`concedes that “the payload 129 does include multiple Source ULP addresses
`117, 120,” Patent Owner contends that “the Source ULP addresses 117, 120
`are not transport layer headers” because a “ULP source address is part of a
`layer above the transport layer (the Session Layer).” Id. at 9 (citing Ex. 2002
`¶¶ 48–49).
`Further, Patent Owner contends that the Specification “supports Patent
`Owner’s construction.” Id. In particular, the Specification states: “The GMS
`control function 136 will use the destination ULP host address to look up the
`TLP address of the host from the host address map 137,” and “[t]his will be
`used to create a TLP header for the message 123.” Id. (citing Ex. 1002,
`23:20–23 (emphasis included)). Thus, according to Patent Owner, “[t]here is
`. . . no indication in the ’686 Patent that multiple TLP headers are included
`within the aggregated message,” but instead, “[a] single transport layer
`header is used because all aggregated payloads are being transmitted to a
`
`
`8 Contrary to Patent Owner’s argument, the ’686 patent does not describe
`data elements 124–128 as part of transport layer header 123. Rather, it
`indicates that transport header 123 encapsulates those elements and payload
`portion 129. See Ex. 1002, 13:59–66 (“The ULP can be implemented as a
`datagram protocol by encapsulating addresses, message type information and
`the message payload within a datagram of the underlying network transport
`protocol. The general form of the ULP datagram message format is shown in
`FIG. 9 as elements 123, 124, 125, 126, 127, 128 and 129. The transport
`header 123 is the datagram header of the TLP that is encapsulating the ULP
`datagram. The ULP message type field 124 . . . must be present in a ULP
`datagram.” (emphases added)); Ex. 1053 ¶¶ 6–8 (describing encapsulated
`payload and address portions as typical under the OSI, TCP, and IP
`frameworks and citing Dr. Almeroth’s testimony from another proceeding).
`In any case, the outcome here does not depend on what the disclosed
`transport header includes in this particular disclosed example of Figure 9.
`
`
`
` 11
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`same destination host running a same application as other hosts.” Id. at 11
`(citing Ex. 2002 ¶¶ 50–52).
`Petitioner contends that the ordinary meaning of “aggregated message”
`or “server message” does not “require excluding any headers,” but rather, the
`term “message” is “used by the ’686 patent in [its] conventional sense.” Pet.
`Reply 13 (citing Ex. 1053, ¶¶ 5–6; Ex. 1002, 1:28–55). Petitioner contends,
`similarly, “[t]he claims provide sufficient guidance on the meaning of . . .
`‘aggregated message’/‘server message,’” but they “do not support excluding
`any ‘transport layer’ headers.” Id. at 14. Petitioner points out that Patent
`Owner’s “district court construction of ‘aggregating/ aggregated’ likewise
`includes no ‘transport layer’ header requirement.” Id. 13–14 (citing Ex.
`1055, 2–3), 17 (asserting that in prior district court proceedings, Patent
`Owner “never advanced a ‘transport layer message header’ requirement until
`after these proceedings were filed” (citing Ex. 1005, 396–97; Ex. 1006, 234–
`36; Ex. 1052, 108:8–24; Ex. 1054, and Ex. A, 1, 3).9
`
`
`9 Petitioner alleges the ’686 patent creates a distinction between layers and
`levels. See Pet. Reply 18. The ’686 patent references to “Level” protocols in
`Upper Level Protocol (ULP) or Transport Level Protocol (TLP), respectively,
`as associated with a “Session Layer protocol on top of the Transport Layer”
`of the network in the “OSI reference model.” See Ex. 1002, 12:46–50;
`accord id. at 8:38–43. The ’686 patent also refers to “the OSI reference
`model for layers of network protocols.” Id. at 3:45–46. “On top of IP [at
`layer 3] are the layer 4 transport protocols TCP and [“User Datagram
`Protocol”] UDP.” UDP does not guarantee “in-order delivery” of application
`datagrams of a data stream, whereas TCP divides the stream into packets to
`ensure “reliable, in-order delivery.” See id. at 3:46–51. Our claim
`construction and holding does not turn on any alleged distinction between
`level and layer, but we agree with Petitioner that the ’686 patent discusses
`TLP as either IP or TCP/IP. See Pet. Reply 18–19.
`
`
`
` 12
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`
`Petitioner contends that the Specification supports Petitioner’s position
`of not excluding any “transport layer” headers. Pet. Reply 14. According to
`Petitioner, the ’686 patent “explains the Internet Protocol (IP) and
`conventional networking use of the [Open Systems Interconnection] OSI
`reference model for layers of network protocols,” wherein “OSI network
`layers are hierarchical—the packet for each layer (containing a header and
`payload) encapsulates the packets for the layers above.” Id. According to
`Petitioner, in OSI network layers, “an IP packet payload may be an entire
`TCP packet including a TCP header and payload.” Prelim. Reply 4 (citing
`Ex. 1011 (RFC 791), 1).
`Petitioner provides the testimony in previous proceedings by
`Dr. Almeroth, Patent Owner’s declarant, for explanation of encapsulation
`using the OSI model. See Pet. Reply 14–15. As an example, Petitioner
`provides the following diagram by Dr. Almeroth:
`
`
`Pet. Reply 15 (reproducing the above figure from Ex. 1056 ¶ 68). The above
`figure represents encapsulation of higher layers, including Transmission
`
`
`
` 13
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`Control Protocol (“TCP”) segments and headers, as data forming an IP
`datagram. Dr. Almeroth explains as follows:
`This process of adding a layer header to the data from the
`preceding layer is sometimes referred to as “encapsulation”
`because the data and layer header is treated as the data for the
`immediately following layer, which, in turn, adds its own layer
`header to the data from the preceding layer. Each layer is
`generally not aware of which portion of the data from the
`preceding layer constitutes the layer header or the user data.
`
`Ex. 1056 ¶ 68.
`In summary, according to Dr. Almeroth, encapsulation using the OSI
`model involves treating upper level headers as data, and thus, Petitioner
`contends, “‘aggregated message’/‘server message’ could have multiple TCP
`headers.” Pet. Reply 15 (citing 1053 ¶¶ 7–8).
`
`Further, Petitioner contends that Patent Owner impermissibly relies on
`a single embodiment in the ’686 patent “where the server removes Transport
`Level Protocol (TLP) headers from received messages” to support its
`“transport layer” header requirement, although “the claims of the patent are
`not ‘construed as being limited to that embodiment.” Pet. Reply 16 (citing
`PO Resp. 4–11, 13–14; Phillips v. AWH Corp., 415 F.3d 1303, 1323 (Fed.
`Cir. 2005)). In particular, Petitioner contends that the ’686 patent supports
`more than a single embodiment, thereby impacting the breadth of an
`“aggregated message” (and the related term “aggregated payload”). Id.
`
`We note Patent Owner advanced similar arguments prior to institution.
`Here, Patent Owner concedes the claims encompass encapsulated headers, as
`used in the OSI model. See PO Resp. 8 (“Patent Owner’s construction
`position is not that the term ‘aggregated message’ does not encompass
`
`
`
` 14
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`encapsulated headers.”) (citing Inst. Dec. 13)).10 According to Patent Owner,
`“Patent Owner’s construction is that an ‘aggregated message’ or ‘server
`message’ includes only a single transport layer message header.” PO
`Resp. 8–9. Nevertheless, as explained further below and above, and as Patent
`Owner concedes, the ’686 patent supports encapsulating header information
`as data, and thus, as Petitioner contends, “‘aggregated message’/‘server
`message’ could have multiple TCP headers.” Pet. Reply 15.
`In response to Patent Owner’s similar arguments prior to institution,
`the panel determined “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.” Inst. Dec. 15 (citing Prelim. Reply 1–5;
`Ex. 1016, 93; Ex. 1002, Fig. 7). In particular, the panel determined the
`following:
`headers, such as headers 117 and 118, or 120 and 121, appear in
`each payload. See Ex. 1002, 23:11–12 (“Each payload
`[includes] a ULP source address, a data length and the data to be
`sent.”). Even though an embodiment strips out a TLP header
`from a “message,” it looks up a TLP header of the host from
`“host address map 137.” Id. at 23:20–22. The specification
`consistently shows that a payload, even within an aggregated
`payload, may contain header fields. See, e.g., id. at Fig. 9.
`
`Inst. Dec. 12.
`
`
`10 Patent Owner’s concession responds to the panel’s preliminary
`determination in the Institution Decision stating “Patent Owner does not
`dispute, in a clear fashion, Petitioner’s contention that the claims may
`encompass encapsulated headers.” Inst. Dec. 13.
`
`
`
` 15
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`
`Here, Patent Owner does not dispute this preliminary finding but rather
`argues that there is “no indication in the ’686 Patent that multiple TLP
`headers are included within the aggregated message.” PO Resp. 11.
`However, the record supports the preliminary finding, and the parties agree,
`that 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 Ex. 1002, 13:59–62,
`14:38–62, 26:28–45. As such, the ’686 patent supports including any type of
`a header, including TLP headers or other headers in the OSI model, as part of
`the data portion of encapsulated messages.
`As Patent Owner also points out, the Institution Decision also includes
`the following preliminary finding: “The specification describes any data
`reduction as significant only for small packet sizes, and generally attributes
`data reductions due to message aggregation.” See PO Resp.12 (citing Inst.
`Dec. 14; Ex. 1002, 24:23–28). As we noted in the Institution Decision, “the
`challenged claims do not limit the payload size and generally allow for
`different header types according to the Specification,” wherein ‘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,’” and “[t]he Specification therefore does not limit an aggregated
`payload, as claimed, from including headers in general.” Inst. Dec. 14;
`Ex. 1002, 24:12–15, 24:38–47. We note Patent Owner does not urge a
`packet size limitation in its claim construction.
`Patent Owner responds to this preliminary finding by arguing as
`follows:
`
`
`
` 16
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`
`The ‘686 Patent however clearly discusses significant data
`reduction by eliminating transport headers from payloads. The
`‘686 Patent states “[a]ggregation will also reduce the total data
`rate to the hosts since aggregation eliminates the need for
`separate message headers for each payload item. The savings
`will be significant for small payload items since there will be
`only one message header comprising fields 123, 124 and 125
`for multiple payload items.” Ex. 1002, 24:23–28 (emphasis
`added). The ‘686 Patent also states that an aggregated message
`is “longer and contains multiple payloads, but this is a
`significant improvement over received multiple messages with
`the wasted overhead of multiple message headers and
`message processing time.” Ex. 1002, 10:44–47.
`
`Id. at 12.
`
`Patent Owner (id.) and Dr. Almeroth (Ex. 2002 ¶¶ 53–54) focus on
`reduced data rate, but the Specification also 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.” Ex. 1002, 24:12–15 (emphasis added). This
`shows that savings in message rate occurs regardless of whether the data
`packet portion contains encapsulated header information, because no wasted
`overhead occurs in treating the encapsulated header data as data. So this
`message rate savings still occurs even if the encapsulated portion of the
`packet includes TCP header information, because the system processes that
`encapsulated header portion as data, as Dr. Almeroth explains as noted
`above. See Ex. 1056 ¶ 68; Ex. 1058 ¶ 56. The ’686 patent supports this
`finding as it recognizes that “[a]ggregation will be very effective in collecting
`together all of the messages from all of the other hosts into a single message
`
`
`
` 17
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`for each member of the group,” and “[t]his reduces processing . . . since a
`single message will be received rather than many separate messages.”
`Ex. 1002, 24:18–23. In other words, the reduced message rate benefit that
`accrues for a single message occurs regardless of the size of packets (each
`which may or may not include headers) aggregated in the single message.
`See id. The Specification, therefore, does not limit an aggregated message or
`server message, as claimed, from including encapsulated headers as data in a
`single aggregated message (which occurs in the OSI model), including
`transport layer headers encapsulated within the payload.11
`As Petitioner points out, the ’686 patent supports more than a single
`embodiment. Pet. Reply 16. The Specification refers to a preferred
`embodiment as specifying “the TLP protocol is TCP/IP,” and it states that for
`aggregated messages, “the [encapsulated] payload will still contain the source
`host ULP addresses in each [of] the payload items.” Ex. 1002, 26:28–50. In
`general, however, the Specification supports many types of packets, further
`showing that the broad claims must not be limited to stripping TCP or TLP
`headers from a payload: “The wide area network used to transport the ULP
`protocol need not be the Internet or based on IP. Other networks with some
`means for wide area packet or datagram transport are possible including
`ATM networks or a digital cable television network.”
`
`
`11 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 the advantage of data reduction, including other header types within
`the scope of the claim defeats any advantage of excluding a specific type
`from that scope.
`
`
`
` 18
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`Id. at 27:38–43. Consistent with the ’686 patent, a packet message includes
`at least one header, and packet bodies may contain encapsulated packets each
`with their own headers and bodies. See Prelim. Reply 4; Ex. 1016, 93;
`Ex. 1002, 3:28–56, Fig. 7, Fig. 9; Ex. 1011, 1; Ex. 1056 ¶ 68; Ex. 1058 ¶ 56;
`Ex. 1046 (PC NETWORKING HANDBOOK (1996)).12
`On this record, the ’686 Specification supports Petitioner’s argument
`that the claim term “aggregated message” or “server message,” consistent
`with its ordinary and plain meaning, 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. Here, Patent
`Owner’s past claim construction positions support this determination by
`showing, at the least, prior to this inter partes trial, how Patent Owner viewed
`the meaning of this claim term. See Ex. 1005, 396–97; Ex. 1006, 234–36;
`Ex. 1052, 108:8–24; Ex. 1054, and Ex. B, 1.13
`2.
`“aggregated payload” (claims 1, 7, 12);
`“aggregating said payload portions” (claim 3);
`
`
`12 “A packet that contains data and delivery information is a datagram.”
`Ex. 1046, 178. “Packets have two parts: the header and the body.”
`Id. at 179. “The header carries information such as the source and
`destination of a packet.” Id. “The body is the raw data carried by a packet
`or, in many cases, another type of (encapsulate) packet that contains its own
`header and body.” Id. (emphasis added).
`13 Petitioner notes that Patent Owner did not alter its original claim
`construction positions during district court litigation even up to about two
`and a half weeks prior to filing its Preliminary Response here on
`February 15, 2018, but altered its position to include the transport later
`requirements after filing the Preliminary Response. See Pet. Reply 17 (citing
`Ex. 1054, A