`
`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,
`
`Vv.
`
`PALTALK HOLDINGS, INC., |
`Patent Owner.
`
`Case IPR2018-00131!
`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-01238 has been joined with this proceeding.
`
`
`
`Riot Games,Inc. v. PalTalk Holdings, Inc.
`IPR2018-00131, IPR2018-01238
`
`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 37) 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 included therein.
`
`In particular, PalTalk identifies
`
`the following issues on appeal:
`
`the
`
`determination that Claims 1-4, 7-21, 28-35, 39, 40, 47-54, 56, 57, and 64-70 of
`
`U.S. 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-00131 and IPR2018-
`
`01238.
`
`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-00131, IPR2018-01238
`
`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 37
`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-00131!
`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 U.S.C. § 318(a) and 37 C.F.R. § 42.73
`
`' The paneljoined Petitioner Valve Corp. and Case IPR2018-01238 to the
`instant proceeding. See Paper 34.
`* The Petition challenges original claims and claims issued pursuantto an
`ex parte reexamination.
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`I.
`
`INTRODUCTION
`
`A.
`
`Background
`
`Riot GamesInc. (“Petitioner”) filed a Petition requesting an inter
`partes review of claims 1-4, 7-21, 28-35, 39, 40, 47-54, 56, 57, and 64-70
`
`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 (Paper 8,
`“Order”), Petitioner filed a Reply to the Patent OwnerPreliminary Response
`
`(Paper 9, “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 14, 7—21, 28-35, 39,
`
`40, 47-54, 56, 57, and 64—70 are unpatentable under 35 U.S.C. § 103 based
`
`on the combination of Aldred and RFC 1692 either alone or in combination
`
`with RFC 1459. 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 26 (“Pet.
`
`Reply”). Pursuant to our prior authorization (Paper 27, “Order’), Patent
`
`Ownerfiled a Sur-Reply to Petitioner’s Reply (Paper 31, “PO Sur-Reply”).
`
`Oral argument was conducted on February 13, 2019. A transcript of
`
`that argumentis entered in the record. See Paper 36 (“Tr.”).
`
`We havejurisdiction 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-00131
`Patent 6,226,686
`
`claims 1-4, 7-21, 28-35, 39, 40, 47-54, 56, 57, and 64-70 ofthe 686
`
`patent. For the reasons discussed below, we hold that Petitioner has
`
`demonstrated by a preponderance of the evidence that claims 1-4, 7-21, 28-
`
`35, 39, 40, 47-54, 56, 57, and 64—70 of the ’686 patent are unpatentable
`under 35 U.S.C. § 103(a).
`
`B.
`
`Related Proceedings
`
`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-00132,
`
`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., 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-00131
`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 US5,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
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`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 ULPaddress J, host 60 as
`
`TLP address B and ULP addressI, host 61 has TLP address D and ULP
`
`address K, and GMS 62 has TLP addressS. Jd. at 8:67-9:2. “The network
`
`is a conventional unicast network of networklinks 69, 70, 71, 72, 73, 74, 75,
`
`76, and 77 and unicast routers 63, 64, 65, 66, 67, and 68.” Jd. at 9:2—S.
`
`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.
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`96
`
`100
`
`Hos! A Receives
`Host A Sends
`
`fats {[¢]ri] fs[aATh]P2[3[Pe|
`
`Host 8 Receives
`Host B Sends
`(8Ts[|re|YsTeTt[PtTes[Pa]
`
`97
`
`101
`
`98
`
`102
`
`Host C Receives
`Host C Sends
`pc[Ts1s[Ps|LStc|s[Ps|P2|pa|
`
`Host D Receives
`Host D Sends
`LOTs[eGjr||§jo|Kk|Pt2|8|
`
`99
`
`103
`
`100
`
`96
`
`
`
`101eTEDTLET o7 ~LALS|
`
`Group Server Sends
`
`Group Server Receives
`
`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. /d. 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.
`
`/d. 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
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`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.
`
`1231412810627
`
`128429
`
`SeeaS
`
`M6007
`
`1201112
`
`190.
`
`131
`
`132
`
`Figure 9
`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 message type
`
`field 124, destination ULP address 125, address countfield 126, auxiliary
`
`destination address 127 and 128, andfinally payload 129. Id. at 13:64—
`
`14:37. Items 116, 117, 118, 119, 120, 121, and 122 define the payload
`
`format of the ULP datagram. Jd. at 14:38-39. Item 116 specifies the
`message count and defines the numberof payload elements containedin 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
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`the payload. Jd. at 14:39-48. In particular, item 117 specifies the ULP
`
`address of the source ofthe first payload element, item 118 specifies the data
`
`length for the data in the first payload element, and item 119 constitutes the
`
`actual data. Similarly, item 120 specifies the ULP address of the source of
`
`the last payload element N, item 121 specifies the data length for the data in
`
`the last payload element N, and item 122 constitutes the actual data. Id.
`
`D.
`
`The Challenged Claims
`
`Ofthe challenged claims, claims 1, 3, 7, 12, and 18 are the
`
`independentclaimsat issue. Claim1isillustrative 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 one ofthe plurality
`of host computers, wherein said create message specifies a
`message groupto be created;
`(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 second subset of said
`first subset of the plurality of host computers belongingto 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 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 belongingto said
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`message group; wherein said aggregated message keeps
`tspeche shared, interactive application operating consistently on
`each ofsaid first subset of the plurality of host computers.
`
`Ex. 1002, 27:50—-28:8.
`
`_—_Instituted Grounds of Unpatentability
`E.
`Weinstituted trial on the following specific grounds (Pet. 20, 52):
`
`
`
`Aldred,? and RFC 1692+
`
`
`
`
`
`
`1—4, 7-21, 28-30, 34, 35, 39,
`
`
`40, 47-49, 53, 54, 56, 57,
`64-66, and 70
`
`
`Aldred, RFC 1692, and RFC 1459°| § 103|31-33, 50-52, and 67-69
`
`
`
`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
`
`3 WO 94/11814 (May 26, 1994) “Aldred”; Ex. 1009).
`*Request for Comments (RFC) 1692 (Aug. 1994) (“RFC 1692”; Ex. 1010).
`> Request for Comments (RFC) 1459 (May 1993) (“RFC 1459”; Ex. 1025).
`6 Petitioner superfluously cites the “Knowledge of an Ordinary Artisan,”
`which wedo not repeat, as an obviousness determination takes into account
`that knowledge.
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`involved patent will expire within 18 months from the entry of the Notice of
`
`Filing Date Accordedto Petition”),
`
`In district court, claim terms carry their plain and ordinary meaning as
`would be understood bya personofordinary skill in the art at the time of the
`invention andin 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 general rule: 1) when a patentee sets 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
`
`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“advancedseveral constructionsfor ...
`
`claim elements”in prior district court litigation. See Pet. 5. 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. at 5-6.
`
`After determining via a teleconference with the parties that with
`
`respect to three claim terms, Patent Owner’s proposed constructionsin its
`
`Preliminary Response differed from what Patent Ownerprovidedin 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:
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`“aggregated message,”
`
`29 66
`
`“aggregated payload,” and “payload portion.” Inits
`
`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. 5. 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 (Pri, Pnz2,
`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 7 (citing Ex. 1002, 8:1—-10:67; Fig. 7).
`_
`Patent Owner contendsFigure 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:
`
`“combinedwith the aggregated payload.” Id.
`
`Patent Ownerthenrelies on Figure 9 of the Specification. Jd.
`
`Figure 9, annotated by Patent Owner, follows:
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`126
`125
`}
`JI
`
`Transport|ULP Pisg.|Cost ULF|Aocress|Destraton Oestinsica Payead
`
`
`
`Header Ad&ess|Count|Address 1Type Adéress N aye
`
`
`123
`
`124
`
`127
`
`Address N|LengthN
`
`5
`
`118
`WwW
`a) ~
`|ouree ULP]
`Data
`Address1 Lenght
`
`Message
`Count
`
`11g
`
`Source UIP}
`
`Data
`
`DataN
`
`WW Wi
`
`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 payload.” Jd. at 8 (citing Ex. 1002, 14:37-52).’ Although Patent
`
`7Contrary to Patent Owner’s argument, the ’686 patent does not describe
`data elements 124—128 aspart of the transport layer header. Rather,it
`indicates that the transport header 123 encapsulates those elements and the
`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 shown in 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 messagetypefield
`124.... must be present ina ULP datagram.” (emphases added)); Ex. 1053
`{{ 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
`what the disclosed transport headerincludesin this particular disclosed
`example of Figure 9.
`
`11
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`Ownerconcedesthat “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 above the transport layer (the Session Layer).” Jd. at 9 (citing
`
`Ex. 2002 J] 48-49). That is, the “message header” consists of the “items
`
`highlighted in blue in [annotated] Fig. 9.” Jd. at 10.
`
`Further, Patent Owner contendsthat the Specification “supports
`
`In particular, the Specification states:
`Patent Owner’s construction.” Jd.
`“The GMScontrol 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.” 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 samedestination host running a same application as other hosts.” Jd. at 11
`
`(citing Ex. 2002 qj 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]
`conventionalsense.” 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
`
`‘agegregating/ aggregated’ likewise includes no ‘transport layer’ header
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`requirement.” /d. (citing Ex. 1055, 2-3), 17 (asserting that in prior district
`
`court proceedings, Patent Owner“never advanced a ‘transport layer message
`header’ requirement until after these proceedings were filed”(citing
`Ex. 1005, 396-97; Ex. 1006, 234-36; Ex. 1052, 108:8-24; Ex. 1054, and
`
`Ex. A, 1, 3).8
`
`Petitioner contendsthat 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 modelfor 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 network layers, “an IP packet payload maybe an entire
`
`TCP packet including a TCP header and payload.” Prelim. Reply 4 (citing
`
`Ex. 1011 (RFC 791), 1).
`
`8 Petitioner alleges the ’686 patentcreates 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 patentalso 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 does not 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 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.
`
`13
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`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:
`
`"user data
`
`fea a2 seer AG 10 1SOD bytes 2 oe oe noe
`
`RG
`= ~~
`a0 ==
`a
`fp—$$$ Ethernet frame ——-.----- =
`
`Pet. Reply 15 (reproducing the above figure from Ex. 1056 { 68). The
`
`above figure represents encapsulation of higherlayers, including
`
`Transmission Control Protocol (“TCP”) segments and headers, as data
`
`forming an IP datagram. Dr. Almeroth explains as 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
`header to 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 orthe userdata..
`
`Ex. 1056 4 68.
`
`14
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`In summary, according to Dr. Almeroth, encapsulation using the OSI
`
`model involves treating upper level headers as data, and thus, Petitioner
`
`contends, “‘aggregated message’/‘server message’ could have multiple TCP
`
`headers.” Pet. Reply 15 (citing 1053 {] 7-8).
`
`Further, Petitioner contends that Patent Owner impermissibly relies on
`
`a single 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 claimsofthe 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” (andtherelated term “aggregated payload”). Jd.
`
`Wenote Patent Owner advancedsimilar argumentsprior to
`
`institution. Here, Patent Owner concedes the claims encompass
`
`encapsulated headers, as used in the OSI model. See PO Resp.8 (“Patent
`
`Owner’s construction position is not that the term ‘aggregated message’
`does not encompassencapsulated headers.”) (citing Inst. Dec. 13)).?
`
`According to Patent Owner, “Patent Owner’s constructionis 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 Owner concedes, the ’686 patent supports
`
`* 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-00131
`Patent 6,226,686 |
`
`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 “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 headerofthe 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.
`
`Here, Patent Ownerdoesnotdispute 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
`
`16
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`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 donot 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
`999
`
`hosts,’”
`
`and “[t]he Specification therefore does not limit an aggregated
`
`payload, as claimed, from including headersin general.” Inst. Dec. 13-14;
`
`Ex. 1002, 24:12—15, 24:38-47. We note Patent Ownerdoesnot urge a
`
`packetsize limitation in its claim construction.
`
`Patent Ownerrespondsto this preliminary finding by arguing as
`
`follows:
`
`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 messageis “longer and contains multiple payloads,
`but this is a significant improvement over received multiple
`messages with the wasted overhead of multiple message
`headers and message processing time.” Ex. 1002, 10:44—47.
`
`17
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`Id. 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 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 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 956. 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 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
`
`message rate benefit that accrues for a single message occurs regardless of
`
`the size of packets (each which may or maynotinclude 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 data in a single aggregated message (which occurs
`
`
`
`IPR2018-00131
`Patent 6,226,686
`
`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,” and it states that
`
`for aggregated messages,“the [encapsulated] payload will still contain the
`source host ULP addresses in each [of] the payload items.” Ex. 1002,
`26:28-50. In general, however, the Specification supports many types of
`
`packets, further showingthat 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 ATM networksora digital cable television net-work.”
`
`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 4 56;
`
`Ex. 1046 (PCNETWORKING HANDBOOK(1996))."!
`
`'0The Federal Circuit instructs that simply describing alternative features
`withoutarticulating advantagesor 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 t