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,
`
`Vv.
`
`PALTALK HOLDINGS, INC.,
`Patent Owner.
`
`Case IPR2018-00132'
`Patent 6,226,686 & 6,226,686 Cl?
`
`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
`
`' The panel joined Petitioner Valve Corp. and Case IPR2018-01243 to the
`instant proceeding. See Paper 34.
`* The Petition challenges original claims and claims issued pursuantto an
`ex parte reexamination.
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`I.
`
`INTRODUCTION
`
`A.
`
`Background
`
`Riot GamesInc. (“Petitioner’’) filed a Petition requesting an inter
`
`partes review ofclaims 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.
`
`Paper6 (“Prelim. Resp.”). Pursuant to our prior authorization (Paper8,
`
`“Order’’), Petitioner filed a Reply to the Patent Owner Preliminary Response
`
`(Paper9, “Reply to Prelim. Resp.”) as to the issue of Patent Owner’s claim
`
`constructions, and Patent Ownerfiled a Preliminary Sur-Reply (Paper 10,
`
`“Prelim. Sur-Reply”).
`
`Weinstituted trial to determine whetherclaims1, 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 oftrial, Patent Ownerfiled 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 Ownerthen 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
`
`Ownerfiled a Sur-Reply to Petitioner’s Reply (Paper 30, “PO Sur-Reply”).
`
`Oral argument was conducted on February 13, 2019.
`
`Wehavejurisdiction under 35 U.S.C. § 6. This decisionis a Final
`
`Written Decision under 35 U.S.C. § 318(a) as to the patentability of
`
`

`

`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, weholdthat Petitioner has demonstrated by
`a preponderance ofthe evidencethat 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 patentis 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.
`
`C.
`
`The '686 Patent
`
`The ’686 patent issued on May 1, 2001, from an application filed
`
`September 28, 1999, and claimspriority to parent application
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`No. 08/896,797,filed on July 18, 1997, now US6,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.” Jd. at [54], [57]. Figure 5, reproduced below,illustrates a unicast
`
`network over whichthe interactive applications may be deployed.
`
`$9
`
`Figure 5
`
`Figure 5 depicts a wide area networkwith hosts 58, 59, 60, and 61, anda
`
`group messaging server (“GMS”) 62. Jd. 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
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`TLP address B and ULP addressI, host 61 has TLP address D and ULP
`
`address K, and GMS62 has TLP address S. Jd. at 8:67-9:2. “The networkis
`
`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.” Jd 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 membersof 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.
`96
`
`100
`
`YaTs[se]?|erat
`
`Host A Receives
`
`Host A Sends
`
`97
`
`98
`
`101
`
`Host B Receives
`Host B Sends
`eS SsBs|
`
`102
`
`Host C Receives
`Host C Sends
`
`YeTs[Ts[rs] Lsfe[ye[pi]pe|Pa|
`
`99
`
`103
`
`afer LS{0[|K[Pt]P2{Ps|
`
`Host D Receives
`
`Host D Sends
`
`100
`
`96
`
`101 ETELELAT 97
`
`Group Server Sends
`
`Group Server Receives
`
`~LALS_
`
`|8|LS]8jtppt]ps|Pa|
`Lsje]s[pi]pe|Pe|jp¢Js||Ps|
`102
`98
`|s[ToTK[Pt]2|Ps|fo}ss]6]Pa|
`
`103
`
`99
`
`Figure 7
`
`Figure 7 shows GMS(“Group Server’) 62 receiving multiple messages 96,
`
`97, 98, and 99 before sending them to hosts within message group G.
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`Id. at 9, 18-20, 10:24—28. As shownin Figure 7, multiple messages 96, 97,
`98, and 99, each respectively contain payload P1, P2, P3, and P4, to be
`aggregated into a single larger message, 100, 101, 102, or 103. Jd. Host 58
`sends message 96 (shownin Figure 7 as “Host A sends’), host 60 sends
`
`message 97 (shownin Figure 7 as “Host B sends”), host 59 sends
`message 98 (shownin Figure 7 as “Host C sends”), and host 61 sends
`message 99 (shownin Figure 7 as “Host D sends”), wherein each of the
`
`messages from the hosts has destination TLP address S and ULP address G
`
`for GMS 62. Jd. at 10:28-32. After GMS 62 receivesall four of these
`
`messages, it creates four outbound messages 100, 101, 102, and 103.
`
`/d. at
`
`10:33-34. Aggregated message 100 includes destination TLP address A and
`
`ULPaddress H for host 58 and aggregated payload P2, P3, and P4,
`
`respectively, from the messages from hosts 59, 60, and 61. Jd. at 10:38—-40.
`
`Aggregated message 101 targets host 60, aggregated message 102 targets
`
`host 59, and aggregated message 103 targets host 61. Jd. at 10:41-42.
`
`Figure 9, reproduced below, depicts a datagram format and address
`
`format for ULP messages.
`
`Transport|ULP Msg.|Dest. ULP |Address|Destination | Destination Paytoad
`
`
`
`Header Typo|Address|Count|Address 1 Address N
`
`123
`
`124
`
`125
`
`426
`
`127
`
`128
`
`129
`
`120
`~
`
`
`Message|Source\lP} Source ULP|DataData
`
`Count|Address 4|Lengtht|"°°|"°°" Address N|Length N
`
`416
`
`117
`
`118
`
`4119
`
`121
`
`122
`
`4130
`
`131
`
`132
`
`Figure 9
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`Figure 9 shows a ULP datagram message comprising elements 123, 124, 125,
`
`126, 127, 128, and 129.
`
`/d. at 13:62—64. Transport datagram TLP header
`
`123 encapsulates the ULP datagram that includes ULP messagetypefield
`
`124, destination ULP address 125, address countfield 126, auxiliary
`
`destination address 127 and 128, and finally payload 129. Jd. at 13:64—-14:37.
`
`Items 116, 117, 118, 119, 120, 121, and 122 define the payload format of the
`
`ULPdatagram. /d. at 14:38-39. Item 116 specifies the message count and
`defines the numberof payload elements contained in the payload. Items 117,
`
`118, and 119 comprise the first payload elementin the payload, and items
`
`120, 121, and 112 comprise the last payload elementin the payload. Jd. 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. Jd.
`
`D.
`
`The Challenged Claims
`
`Of the challenged claims, claims 1, 3, 7, 12, and 18 are the independent
`
`claims at issue. Claim1is illustrative of the challenged claims, and is
`
`reproduced below:
`
`A methodforfacilitating communications among a
`1.
`plurality of host computers over a network to implementa shared,
`interactive application, comprising the stepsof:
`(1) receiving a create message from one ofthe plurality of host
`computers, wherein said create message specifies a message group to
`be created;
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`(2) receiving join messages fromafirst subset ofthe plurality of
`host computers, wherein each ofsaid join messages specifies said
`message group;
`(3) receiving host messages from a second subsetofsaidfirst
`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 payloadportions of said host messages
`received from said second subsetofthe plurality of host computers to
`create an aggregated payload;
`
`(5) forming an aggregated message using said aggregated
`payload; and
`(6) transmitting said aggregated messageto said first subset of
`the plurality of host computers belonging to said message group;
`wherein said aggregated message keeps the shared, interactive
`application operating consistently on each ofsaid first subset of the
`plurality of host computers.
`
`Ex. 1002, 27:50—-28:8.
`
`E.__Instituted Grounds of Unpatentability
`
`Weinstituted trial on the following specific grounds (Pet. 21, 51, and
`
`66):
`
`Reference Basis|Claim(s) Challenged
`
`Aldred,’ and RFC 1692+
`§ 103
`1,3, 7, 12, 18, 26, 27, 45, 46,62,
`
`and 63
`
`
`
`
`
`
`Aldred, RFC 1692, and Ulrich? § 103|22-27, 41-46, and 58-63
`
`
`
`Aldred, RFC 1692, and Denzer® § 103|36, and 55
`
`3 WO 94/11814 (May 26, 1994) (“‘Aldred’”; Ex. 1009).
`“Request for Comments (RFC) 1692 (Aug. 1994) (“RFC 1692”; Ex. 1010).
`> US 5,466,200 (Nov. 14, 1995) (“Ulrich”; Ex. 1012).
`,
`®US 5,307,413 (Apr. 26, 1994) (“Denzer”; Ex. 1014).
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`Petitioner also relies on the testimonies of Dr. Steve R. White.’
`
`Exs. 1007, 1053. Patent Ownerrelies on the testimony of Dr. Kevin C.
`
`Almeroth. Ex. 2002.
`
`Il.
`
`ANALYSIS
`
`A,
`
`Claim Construction
`
`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 ofthe Notice ofFiling
`Date Accordedto Petition”).
`
`In district court, claim terms carry their plain and ordinary meaning as
`
`would be understoodbya person ofordinary 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 patenteesets out a definition and
`
`acts as his own lexicographer, or 2) when the patentee disavowsthe full
`
`scope of a claim term either in the specification or during prosecution.”
`
`Thorner v. Sony Comput. Entm’t Am. LLC, 669 F.3d 1362, 1365 (Fed. Cir.
`
`2012). Only terms in controversy must be construed and only to the extent
`
`necessary to resolve the controversy. Vivid Techs., Inc. v. Am. Sci. & Eng’g,
`Inc., 200 F.3d 795, 803 (Fed. Cir. 1999); Nidec Motor Corp. v. Zhongshan
`
`Petitioner superfluously cites the “Knowledge of an Ordinary Artisan,”
`which wedonotrepeat, as an obviousness determination takes into account
`that knowledge.
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`Broad Ocean MotorCo., 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 priordistrict court litigation. See Pet. 5-6. Petitioner
`
`generally contends the “‘precise scope” of the terms need not be determined,
`
`provided the termstrack “any interpretation consistent with their plain and
`
`ordinary meaningin the context of the [’]686 [p]atent.” Jd.
`
`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 Ownerprovided 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:
`99°66
`
`“agoregated 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 andasset forth in
`
`the Institution Decision, the constructions of the terms involve the
`
`overlapping issue of a transport layer header.
`
`“aggregated message’’(claims 1, 3, 7, 12);
`1.
`“server message” (claim 18)
`
`Patent Owner contends “aggregated message” means “[o]ne or more
`
`messages containinga single transport layer message header, destination
`
`data, and data items from an aggregated payload.” PO Resp. 4. Patent
`
`Ownerrelies on Figure 7 of the Specification as providing an example:
`
`Eachof the messages 100, 101, 102 and 103 received by a
`host from a server includes the aggregated payloads (Pu, Pnz,
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`P,,3) in each message and a headerportion consisting of a
`transport layer protocol source address (S) of the server, a
`transport layer protocol destination address (A, B, C or D) for
`the destination host and a destination upper layer protocol (ULP)
`address (H,I, J or K) for the destination host.
`
`Id. at 6 (citing Ex. 1002, 8:1-10:67; Fig. 7).
`
`Patent Ownercontends 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,” whichis then
`
`“combined with the aggregated payload.” /d.
`
`Patent Ownerthen relies on Figure 9 of the Specification. Jd.
`
`Figure 9, annotated by Patent Owner, follows:
`
`127
`126
`~
`Transport|ULP bsg.|Cart ULF|Aderess|Oestisaten Destinasca Paytcad
`
`
`Header|Type|Address|Coun:|Asaresst Adéress N a
`
`
`124
`
`125
`
`123
`
`Address N|LenghN
`
`118
`VW
`r~?
`~
`Message |Borce ULP|Dato SouceULP|]Data DataN
`
`
`
`Count|]Address!|lenytht
`
`VW
`
`5
`
`130133
`
`132
`
`Figure 9
`Asannotated 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.” Jd. at 7 (citing Ex. 1002, 14:37-52).8 Although Patent Owner
`concedesthat “thepayload 129 does include multiple Source ULP addresses
`117, 120,” Patent Owner contendsthat “the Source ULP addresses 117, 120
`
`are not transport layer headers” because a “ULP source addressis part of a
`
`layer above the transport layer (the Session Layer).” Jd. at 9 (citing Ex. 2002
`
`{J 48-49).
`
`Further, Patent Ownercontends that the Specification “supports Patent
`
`Owner’s construction.” Jd.
`
`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.” Jd. (citing Ex. 1002,
`
`23:20—-23 (emphasis included)). Thus, according to Patent Owner, “[t]here is
`
`. ho 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 ofthe underlying network transport
`protocol. The general form of the ULP datagram message format is shownin
`FIG. 9 as elements 123, 124, 125, 126, 127, 128 and 129. The transport
`header 123 is the datagram headerof the TLP that is encapsulating the ULP
`datagram. The ULP messagetype field 124... must be present in a ULP
`datagram.” (emphases added)); Ex. 1053 {J 6-8 (describing encapsulated
`payload and addressportionsas typical under the OSI, TCP, and IP
`frameworksand citing Dr. Almeroth’s testimony from another proceeding).
`In any case, the outcome here does not depend on whatthe disclosed
`transport header includesin this particular disclosed example of Figure 9.
`
`11
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`same destination host running a sameapplication as other hosts.” Jd. at 11
`
`(citing Ex. 2002 FJ 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, J] 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.” /d. at 14. Petitioner points out that Patent
`
`Owner’s “district court construction of ‘aggregating/ aggregated’ likewise
`
`includes no ‘transport layer’ header requirement.” Jd. 13—14 (citing Ex.
`
`1055, 2-3), 17 (asserting that in prior district court proceedings, Patent
`
`Owner“never advanced a ‘transport layer message header’ requirementuntil
`
`after these proceedings werefiled”(citing Ex. 1005, 396-97; Ex. 1006, 234—
`36; Ex. 1052, 108:8-24; Ex. 1054, and Ex.A, 1, 3).?
`
`* 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.” Jd. 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
`TLPas 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.” Jd. According to
`
`Petitioner, in OSI networklayers, “an IP packet payload maybe anentire
`
`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:
`
`treplication] ‘
`
`[ettertetnace
`
`wa————=> TCP segment
`
`T
`
`staner
`
`OR
`|
`header
`|
`applicationdala
`
`
` ‘
`
`
`IPclatagran
`
`faa Ethernet frame
`fe | =-= 4G t0 1500 bytes -
`
`application dala
`
`
`Pet. Reply 15 (reproducing the above figure from Ex. 1056 J 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 headeris treated as the data for the
`immediately following layer, which, in turn, adds its own layer
`headerto the data from the preceding layer. Each layeris
`generally not aware of which portion of the data from the
`preceding layer constitutes the layer headeror 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 4 7-8).
`
`Further, Petitioner contends that Patent Owner impermissibly relies on
`
`a single embodimentin 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
`
`“agoregated message” (and the related term “aggregated payload”). Jd.
`
`Wenote Patent Owner advanced similar argumentspriorto 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)).'° According to Patent Owner,
`
`“Patent Owner’s construction is that an ‘aggregated message’ or ‘server
`
`message’ includesonly a single transport layer message header.” PO
`
`Resp. 8-9. Nevertheless, as explained further below and above, and as Patent
`
`Ownerconcedes, 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 argumentsprior to institution,
`
`the panel determined “on this preliminary record, that the Specification and
`
`evidence support an ‘aggregated message’ as including an aggregated
`
`payload andat least one headerin 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, appearin
`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 embodimentstrips out a TLP header
`from a “message,” it looks up a TLP headerof the host from
`“host address map 137.” Jd. at 23:20-22. The specification
`consistently showsthat a payload, even within an aggregated
`payload, may contain headerfields. See, e.g., id. at Fig. 9.
`
`Inst. Dec. 12.
`
`'0 Patent Owner’s concession respondsto 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 doesnotdispute this preliminary finding but rather
`arguesthat 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 payloadsthat 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 Owneralso 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 accordingto the Specification,” wherein ‘the
`
`Specification generally describes savings based on aggregationforall 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 Ownerrespondsto this preliminary finding by arguing as
`
`follows:
`
`16
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`The ‘686 Patent howeverclearly 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 headersfor 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 Patentalso states that an aggregated message
`is “longer and contains multiple payloads, butthis is a
`significant improvementover 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
`
`showsthat 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 savingsstill occurs even if the encapsulated portion of the
`
`packet includes TCP header information, because the system processesthat
`
`encapsulated headerportion as data, as Dr. Almeroth explains as noted
`
`above. See Ex. 1056 J 68; Ex. 1058 9 56. The ’686 patent supportsthis
`
`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
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`for each memberofthe group,” and “/t/his reduces processing... since a
`
`single messagewill be received rather than many separate messages.”
`
`Ex. 1002, 24:18—23. In other words, the reduced messagerate benefit that
`
`accrues for a single message occurs regardless of the size of packets (each
`
`which may or maynot 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 ina
`
`single aggregated message (which occurs in the OSI model), including
`
`transport layer headers encapsulated within the payload.!!
`
`AsPetitioner points out, the °686 patent supports more than a single
`
`embodiment. Pet. Reply 16. The Specification refers to a preferred
`embodimentas specifying “the TLP protocol is TCP/IP,” andit 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 mustnot 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
`
`ATMnetworksora digital cable television network.”
`
`'! 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 J 68; Ex. 1058 4 56;
`
`Ex. 1046 (PC NETWORKING HANDBOOK(1996)).”
`Onthis 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 headerin 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 ofthis claim term. See Ex. 1005, 396-97; Ex. 1006, 234-36;
`
`Ex. 1052, 108:8—24; Ex. 1054, and Ex. B, 1."
`
`“aggregated payload” (claims 1, 7, 12);
`2.
`“aggregating said payloadportions” (claim 3);
`
`12packet 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.” Jd. “The bodyis 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).
`'3 Petitioner notes that Patent Ownerdid notalter its original claim
`construction positions during district court litigation even up to about two
`and a half weekspriorto 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-1; Ex. 1055, 2-4).
`
`19
`
`

`

`IPR2018-00132
`Patent 6,226,686
`
`“aggregating said payload portion with the
`payloadportion ofa second host message”’
`
`(claim 18)
`
`Patent Owner contends “aggregated payload” should be construed as
`
`“Ta] collection of two or more data items that does not include transport layer
`
`headers.” PO Resp. 13. To support its construction, Patent Owner contends
`