`
`Filed on behalf of PalTalk Holdings, Inc.
`By: Douglas R. Wilson
`doug. wilson@armondwilson.com
`Michelle E. Armond
`michelle.armond@armondwilson.com
`ARMOND WILSON LLP
`9442 Capital of Texas Hwy North,
`Plaza 1, Suite 500
`Austin, Texas 78759
`Tel: (512) 343-3622
`Fax: (512) 345-2924
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`RIOT GAMES,INC. and
`VALVE CORP.,
`Petitioners,
`
`V.
`
`PALTALK HOLDINGS,INC.,
`Patent Owner.
`
`Case IPR2018-00132!
`Patents 6,226,686 & 6,226,686 Cl
`
`PATENT OWNER’S NOTICE OF APPEAL TO THE
`U.S. COURT OF APPEALS FOR THE FEDERAL CIRCUIT
`
`' Case IPR2018-01243 has been joined with this proceeding.
`
`
`
`Riot Games,Inc. v. PalTalk Holdings, Inc.
`IPR2018-00132, IPR2018-01243
`
`Pursuant to 28 U.S.C. § 1295(a)(4)(A), 35 U.S.C. §§ 141(c), 142, and 319,
`
`37 C.F.R. §§ 90.2(a) and 90.3, and Rule 4(a) of the Federal Rules of Appellate
`
`Procedure, Patent Owner PalTalk Holdings, Inc. (“PalTalk”’) hereby appeals to the
`United States Court of Appeals for the Federal Circuit from the Final Written
`
`Decision (Paper 36) entered on May 14, 2019 (attached hereto as Attachment A),
`
`and from all underlying orders, decisions, rulings, and opinions that are adverse to
`
`PalTalk related thereto and includedtherein.
`
`In .particular, PalTalk identifies
`the following issues on appeal:
`the
`determination that Claims 1, 3, 7, 12, 18, 22-27, 36, 41-46, 55, and 58-63 of US.
`
`Patent Nos. 6,226,686 and 6,226,686 Cl are unpatentable under 35 U.S.C. § 103,
`
`any finding or determination supporting or relating to these issues; and all other
`
`procedural and substantive issues decided adversely to PalTalk in any order,
`decision, ruling, or opinion by the Board in both IPR2018-00132 and IPR2018-
`
`01243.
`
`PalTalk is concurrently providing true and correct copies of this Notice of»
`
`Appeal, along with the required fees, with the Director of the United States Patent
`
`and Trademark Office and the Clerk of the United States Court of Appeals for the
`
`Federal Circuit.
`
`
`
`Riot Games,Inc. v. PalTalk Holdings,Inc.
`IPR2018-00132, IPR2018-01243
`
`June 12, 2019
`
`ARMOND WILSON LLP
`
`/Douglas R. Wilson/_
`Douglas R. Wilson (Reg. No. 54,542)
`
`Counsel for Patent Owner
`PALTALK HOLDINGS, INC.
`
`
`
`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-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 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 | (‘‘Pet.”).
`
`PalTalk Holdings, Inc. (“Patent Owner”) filed a Preliminary Response.
`
`Paper 6 (“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 claims1, 3, 7, 12, 18, 22—27,
`36, 41- 46, 55, and 58-63 are unpatentableunder 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 decision is 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 preponderance of the 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).
`
`B.
`
`Related Proceedings
`
`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.
`
`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 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.” Jd. at [54], [57]. Figure 5, reproduced below,illustrates a unicast
`
`network over which the interactive applications may be deployed.
`
`$9
`
`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 ULPaddressJ, 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 TLPaddress 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 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.
`96
`
`100
`
`Host A Receives
`Host A Sends
`
`LA[Ls[|c]P| LSLA]#[P2|P3[Pa|
`
`Host B Receives
`Host B Sends
`[Leitsjc[re|LS}8|tjPt[Ps|pa|
`
`‘97
`
`101
`
`98
`
`99
`
`102
`
`Host C Sends
`
`Lc]s|G[Ps] epeea
`
`Host C Receives
`
`103
`
`Host D Receives
`Host D Sends
`Lots[s61P4|LS|0|k[Pi[P2|P3|
`
`100
`
`96
`
`Group Server Receives
`oy MALSTST
`10
`pS]8ftft|3|Pa|PB|Ss|G|Pe|
`Ls[cf[et[2|Pa|[P3|
`CsToTKyTyey] *~
`(07
`[Pa]
`99
`
`102:
`
`Group Server Sends
`
`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
`
`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. Jd. 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,
`
`/d. at 10:38—-40.
`respectively, from the messages from hosts 59, 60, and 61.
`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 Payload
`
`
`
`Header Type|Address|Count|Address t Address N
`
`123
`
`124
`
`125
`
`126
`
`127
`
`128
`
`129
`
`117
`
`418
`
`419
`
`120
`
`121
`
`122
`
`1416
`J
`oe
`
`
`
`Massage [Source AP|Data Source ULP! Data
`
`
`
`130
`
`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. 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 definethe payload formatofthe
`ULP datagram. Id. 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 ofthe 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 addressof 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. Claim | is illustrative of the challenged claims, and is
`
`reproduced below:
`
`A methodforfacilitating communications among a
`1.
`plurality of host computers over a network to implement a shared,
`interactive application, comprising the stepsof:
`(1) receiving a create message from oneofthe 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 of the plurality of
`host computers, wherein each of said join messagesspecifies said
`message group;
`(3) receiving host messages from’a second subsetofsaid 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 saidpayload 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 messageto said first subset of
`the plurality of host computers belonging to said message group;
`wherein said aggregated message keepsthe shared,interactive
`application operating consistently on eachofsaidfirst 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):
`
`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).
`6US 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.
`
`II.
`
`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 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
`exceptionsto this generalrule: 1) whena patentee sets out a definition and
`acts as his own lexicographer, or 2) when the patentee disavowsthefull
`scope of a claim term eitherin 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 notrepeat, as an obviousness determination takes into account
`that knowledge.
`
`
`
`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 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 contextofthe [’]686 [p]atent.” Jd.
`
`After determining via a teleconference with the parties that with
`
`respectto three claim terms, Patent Owner’s proposed constructionsin its
`
`Preliminary Response differed from what Patent Ownerprovided in prior
`
`district court litigation (Paper 8, 2-4), we authorizedthe 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
`
`“ageregated 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 andassetforth 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 (Pn, 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 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.” Jd.
`
`Patent Ownerthenrelies on Figure 9 of the Specification. Jd.
`
`Figure 9, annotated by Patent Owner,follows:
`
`;
`a
`
`
`Transport|ULP bsg. [Cast ULP|Adcress|Destiaton Oestnaien Paycad
`Header Type|Add&ess|Coun|Adoresst|°°" Actress N
`
`
`Address N|Length N
`
`118
`WwW
`~d ~
`
`
`Message |Bource ULP|Dato Source ULP| Dats Data
`
`
`Count|]Address 1|Lengrt|SPTPT’
`
`119
`
`WO
`
`(133
`
`132
`
`Figure 9
`
`Asannotated and described by Patent Owner, Figure 9 shows “an aggregated
`
`message” whichincludes“a messageheader(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 “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 addressis part of a
`
`layer abovethe transport layer (the Session Layer).” Jd. at 9 (citing Ex. 2002
`
`qf 48-49).
`
`Further, Patent Ownercontendsthat 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
`
`.. no indication in the ’686 Patent that multiple TLP headers are included
`
`within the aggregated message,” but instead, “[a] single transport layer
`
`headeris used becauseall 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 header of the TLPthatis encapsulating the ULP
`datagram. The ULP messagetypefield 124... must be present in a ULP
`datagram.” (emphases added)); Ex. 1053 fj 6—8 (describing encapsulated
`payload and addressportions as typical under the OSI, TCP, and IP
`frameworksandciting 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.
`
`1]
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`same destination host running a sameapplication as other hosts.” Jd. at 11
`
`(citing Ex. 2002 4 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 patentin [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 advanceda ‘transport layer message header’ requirement until
`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 patentcreatesa 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
`model for layers of network protocols.” Jd. at 3:45—46. “On top ofIP [at
`layer 3] are the layer 4 transport protocols TCP and [“User Datagram
`Protocol”] UDP.” UDP doesnot guarantee “in-order delivery” of application
`datagramsof 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 anyalleged 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 may be 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:
`
`vee AG tO ISO) bytes eee
`
`+ Cthernet frame
`
`agplication data
`
`Pet. Reply 15 (reproducing the abovefigure 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 explainsas follows:
`
`This process of adding a layer headerto 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 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, Petitiorler
`
`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 contendsthat the ’686 patent supports
`
`more than a single embodiment, thereby impacting the breadth of an
`
`“agesregated message” (andthe related term “aggregated payload”). Id.
`
`Wenote Patent Owner advancedsimilar argumentspriorto institution.
`
`Here, Patent Owner concedesthe 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 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 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 Ownerdoes not
`dispute, in a clear fashion, Petitioner’s contention that the claims may
`encompassencapsulated headers.” Inst. Dec. 13.
`
`15
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`Here, Patent Ownerdoes notdispute 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 notlimit the payload size and generally allow for
`
`different header types accordingto 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
`
`299
`
`payload, as claimed, from including headers in general.” Inst. Dec. 145,
`
`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 respondsto 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 itemssince 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, butthis is a
`significant improvement overreceived 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 9] 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 messageto 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 occursin treating the encapsulated headerdata as data. So this
`
`message rate savingsstill 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 7 68; Ex. 1058 56. The ’686 patent supportsthis
`
`finding as it recognizesthat “[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 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.!!
`
`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 typesof packets, further
`
`showing that the broad claims mustnot be limited to stripping TCP or TLP
`
`headers from a payload: “The wide area networkused to transport the ULP
`protocol need not be the Internet or based on IP. Other networks withsome
`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
`withoutarticulating 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,