`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 C1?
`
`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 US.C. § 318(a) and 37 C.F.R. § 42.73
`
`' The panel joined Petitioner Valve Corp. and Case IPR2018-01243to the
`instant proceeding. See Paper 34.
`* The Petition challenges original claims and claims issued pursuant to 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 of claims 1, 3, 7, 12, 18, 22-27, 36, 41— 46, 55, and 58-63 of
`
`US. 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 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 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, we hold that Petitioner has demonstrated by
`
`a preponderanceof 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).
`
`B.
`
`Related Proceedings
`
`Petitioner states that the ’686 patent is related to the following US.
`
`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 May1, 2001, from an applicationfiled
`
`September 28, 1999, and claimspriority to parent application
`
`
`
`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.
`
`59
`
`Figure 5
`
`;
`
`Figure 5 depicts a wide area network with 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 addressJ, 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 GMS 62 has TLP address S. Jd. 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 unicastrouters 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 membersof the message group.”
`
`Id. at 9:5-8.
`
`Figure 7, reproduced below, depicts ULP datagramswith payload
`
`aggregations for implementing an interactive gaming application between the
`
`four hosts in Figure 5.
`96
`
`100
`
`Host A Sends
`
`a| Se
`
`Host A Receives
`
`Host B Receives
`Host B Sends
`AISCA ‘VsTeTiritrs7Pa)
`
`97
`
`101
`
`Host C Receives
`Host C Sends
`
`fefs{sc[prs] \_sTeTsTri[2JPa]
`
`98
`
`102
`
`99
`
`103
`
`Lo}Ss[GfPa|ETSeaa
`
`Host D Receives
`
`Host D Sends
`
`100
`
`96
`
`Grou
`
`Group Server Sends
`,,
`PATHTreTesTra]
`sot
`Ee|8|
`psfefs[Ps[2|Pa|
`102
`98
`
`=|oO|Kk[Pt|P2|Po|
`
`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 ofthe
`
`messagesfrom the hosts has destination TLP address S and ULP address G
`for GMS 62. Id. at 10:28-32. After GMS62 receivesall four of these
`
`messages, it creates four outbound messages 100, 101, 102, and 103. Jd. 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.
`/d. 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 Payoad
`
`
`Hezder Typo|Address|Count|Address 1 Address N
`
`123
`
`424
`
`126
`
`126
`
`127
`
`128
`
`129
`
`Message|Source UP] _,|Seureeulp|DataData
`
`
`
`Count|Address 1|Length t Address N|Lengthue
`
`
`116
`4
`
`117
`
`118
`
`419
`
`120
`
`121
`
`122
`
`131
`
`130
`vi)
`
`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. Jd. 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 element in the payload, and items
`120, 121, and 112 comprise the last payload element in 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 inthe
`first payload element, and item 119 constitutes the actual data. Similarly,
`
`item 120 specifies the ULP address of the source ofthe 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.
`
`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, andis
`
`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 messagesfromafirst subset of the plurality of
`host computers, wherein each of said join messages specifies said
`message group;
`
`(3) receiving host messages from a secondsubsetofsaid 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 subsetof the 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 16924
`§ 103 pee 12, 18, 26, 27, 45, 46, 62,
`
`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
`
`Theparties 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 Accordedto Petition”).
`In district court, claim termscarry 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 wedo not repeat, 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 constructionsfor...
`
`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 termstrack “any interpretation consistent with their plain and
`
`ordinary meaning in the contextof the [’]686 [p]atent.” Jd.
`
`After determining via a teleconference with the parties that with
`
`respect to three claim terms, Patent Owner’s proposed constructionsinits
`
`Preliminary Response differed from what Patent Owner providedin prior
`
`district court litigation (Paper 8, 2-4), we authorized the filing ofa
`
`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
`
`proposedin 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 Ownercontends“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
`
`Ownerrelies 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 (Pay, Pra,
`
`
`
`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 OwnercontendsFigure 7 discloses “only a single message
`
`headerconsisting 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 Ownerthenrelies on Figure 9 of the Specification. Id.
`
`Figure 9, annotated by Patent Owner, follows:
`
`,
`r~ ~
`
`Transport|ULP bsg.|Cort ULF|Adcress|Oestisaton Destnaten Payead
`
`
`
`Header Address|Count|Address 1Type Adsiess Nf
`
`
`
`Addtess N Leman
`Source ULP
`
`ata N
`
`130
`
`(133
`
`132
`
`Figure 9
`
`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.” Jd. at 7 (citing Ex. 1002, 14:37-52).2 Although Patent Owner
`
`concedesthat “the payload 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 abovethe transport layer (the Session Layer).” Jd. at 9 (citing Ex. 2002
`
`{{ 48-49).
`
`Further, Patent Owner contends 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 addressof the host from the host address map 137,” and “[t]his will be
`
`used to create a TLP header for the message 123.” /d. (citing Ex. 1002,
`
`23:20—-23 (emphasis included)). Thus, according to Patent Owner,“[t]hereis
`
`.. no indication in the ’686 Patent that multiple TLP headers are included
`
`within the aggregated message,” but instead, “[a] single transport layer
`
`headeris used because all aggregated payloads are being transmitted to a
`
`§ 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 implementedas 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 shown in
`FIG. 9 as elements 123, 124, 125, 126, 127, 128 and 129. Thetransport
`header 123 is the datagram header of 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 addressportions as 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 headerincludesin this particular disclosed example of Figure9.
`
`11
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`same destination host running a same application as other hosts.” /d. at 11
`
`(citing Ex. 2002 J 50-52).
`
`Petitioner contends that the ordinary meaningof “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, 9] 5—6; Ex. 1002, 1:28-55). Petitioner contends,
`
`similarly, “[t]he claims provide sufficient guidance on the meaningof...
`
`‘aggregated message’/‘server message,” but they “do not support excluding
`any ‘transport layer’ headers.” Jd. 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 advanceda ‘transport layer message header’ requirementuntil
`
`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).?
`
`* 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 networkin 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
`modelfor 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 doesnot 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 doesnot 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 packetfor 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:
`
`owe
`
` ©
`
`user data
`
`_spptictien
`
`Cs: + ee|: ,|hesder
`
`
`
`
`FORT
`_twader|2Fpication dala
` pe
`“TCPsegnSegnient
`
`header Ppication data
`IP batagiain
`
`1, ooo
`
`Ethernet frame
`ttm $6 to 1500 bytea -
`
`Pet. Reply 15 (reproducing the above figure from Ex. 1056 4 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 JP
`
`datagram. Dr. Almeroth explains as follows:
`
`This process of adding a layer header to the data from the
`preceding layer is sometimesreferred 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 userdata.
`
`Ex. 1056 J 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 claimsof 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
`
`“ageregated message”(and the related term “aggregated payload”). Id.
`
`Wenote Patent Owner advanced similar argumentspriorto institution.
`
`Here, Patent Owner concedes the claims encompassencapsulated 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
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`encapsulated headers.”) (citing Inst. Dec. 13)).!° According to Patent Owner,
`
`“Patent Owner’s constructionis 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
`
`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 argumentspriorto institution,
`
`the panel determined “onthis preliminary record, that the Specification and
`
`evidence support an ‘aggregated message’ as including an aggregated
`
`payload andat 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, 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 shows that a payload, even within an aggregated
`payload, may contain headerfields. 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
`encompassencapsulated headers.” Inst. Dec. 13.
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`Here, Patent Ownerdoesnot 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 headersor 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 notedin 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 doesnot 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 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 Patentalso states that an aggregated message
`is “longer and contains multiple payloads, but this is a
`"
`significant improvementover received multiple messages with
`the wasted overhead of multiple message headers and
`message processing time.” Ex. 1002, 10:44-47.
`
`Td. at 12.
`
`Patent Owner(id.) and Dr. Almeroth (Ex. 2002 {J 53-54) focus on
`
`reduced data rate, but the Specification also describes savings based on
`
`aggregation forall packet sizes based on “greatly reduc[ing] the total
`
`messagerate 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 whetherthe data
`
`packet portion contains encapsulated header information, because no wasted
`
`overhead occursin treating the encapsulated header data as data.
`
`Sothis
`
`message rate savings still occurs even if the encapsulated portion of the
`
`packet includes TCP header information, because the system processesthat
`
`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
`
`togetherall of the messages from all of the other hosts into a single message
`
`17
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`for each memberofthe 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 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 headersas datain a
`
`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 thanasingle
`
`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
`showingthat the broad claims must notbe limited to stripping TCP or TLP
`
`headers from a payload: “The wide area network used to transport the ULP
`
`protocol need notbe the Internet or based on IP. Other networks with some
`
`means for wide area packet or datagram transport are possible including
`
`ATM networksor a 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 { 68; Ex. 1058 { 56;
`
`Ex. 1046 (PC NETWORKING HANDBOOK(1996)).!2
`
`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 andat least one headerin addition to any additional
`
`headers that may happento 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 meaningof this 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);
`
`'2°A packet that contains data and delivery informationis a datagram.”
`Ex. 1046, 178. ‘Packets have twoparts: the header and the body.”
`Id. at 179. “The header carries information such as the source and
`destination of a packet.” Jd. “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).
`'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
`requirementsafter filing the Preliminary Response. See Pet. Reply 17 (citing
`Ex. 1054, A-1; Ex. 1055, 2-4).
`
`&
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`“aggregating said payload portion with the
`payload portion ofa second host message”
`
`(claim 18)
`
`Patent Owner contends “aggregated payload”should be construed as
`
`“{a] collection of two or more data items that does not include transport layer
`
`headers.” PO Resp. 13. To support its construction, Patent Owner contends
`
`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 i