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. & VALVE CORP.,
`Petitioner,
`
`v.
`
`PALTALK HOLDINGS, INC.,
`Patent Owner.
`_______________
`
`Case IPR2018-001301
`Patent 5,822,523 & 5,822,523 C12
`_______________
`
`
`Before THU A. DANG, KARL D. EASTHOM, and NEIL T. POWELL
`Administrative Patent Judges.
`
`EASTHOM, Administrative Patent Judge.
`
`
`
`DECISION
`Final Written Decision
`35 U.S.C. § 318(a) and 37 C.F.R. § 42.73
`
`
`
`1 The panel joined Petitioner Valve Corp. and Case IPR2018-01241 to the
`instant proceeding. Paper 23.
`
`2 The Petition challenges original claims and claims issued pursuant to an ex
`parte reexamination certificate. See Ex. 1001.
`
`

`

`IPR2018-00130
`Patent 5,822,523
`
`
`I. INTRODUCTION
`
`A. Background
`
`Riot Games, Inc. (“Petitioner”) filed a Petition requesting an inter
`
`partes review of claims 1, 11–15, and 19–30 of U.S. Patent Nos. 5,822,523
`
`and 5,822,523 C1 (Ex. 1001, the “’523 patent”). Paper 1 (“Pet.”). PalTalk
`
`Holdings, Inc. (“Patent Owner”) filed a Preliminary Response. Paper 6
`
`(“Prelim. Resp.”). Pursuant to our authorization (Paper 8, “Order”),
`
`Petitioner filed a Reply to Patent Owner Preliminary Response (Paper 9,
`
`“Pet. Prelim. Reply”) addressing Patent Owner’s claim constructions, and
`
`Patent Owner filed a Preliminary Sur-Reply (Paper 10, “PO Prelim. Sur-
`
`Reply”).
`
`After we instituted trial on challenged claims 1, 11–15, and 19–30
`
`(Paper 11, “Institution Decision” or “Inst. Dec.”), Patent Owner filed a
`
`Response (Paper 22, “PO Resp.”), Petitioner filed a Reply to Patent Owner’s
`
`Response (Paper 26, “Reply”)), and Patent Owner filed a Sur-Reply to
`
`Petitioner’s Reply (Paper 31, “Sur-Reply”). An Oral Hearing transpired on
`
`February 13, 2019. The record includes a transcript of the Oral Hearing.
`
`Paper 36 (“Tr.”).
`
`We have jurisdiction under 35 U.S.C. § 6. This Final Written
`
`Decision issues under 35 U.S.C. § 318(a). For the reasons discussed below,
`
`Petitioner has demonstrated by a preponderance of the evidence that claims
`
`1, 11–15, and 19–30 of the ’523 patent are unpatentable under 35 U.S.C.
`
`§ 103(a).
`
`B. Related Proceedings
`
`Petitioner states that the ’523 patent relates to U.S. Patent Nos.
`
`6,226,686 (the “’686 patent”) and 6,018,766. Pet. 1. Also, ex partes
`
` 1
`
`
`
`
`
`

`

`IPR2018-00130
`Patent 5,822,523
`
`reexamination No. 90/011,036 (Ex. 1006) involved a reexamination of the
`
`’686 patent. Pet. 1. A concurrent request for inter partes review, IPR2018-
`
`00129, challenges claims of the ’523 patent. Pet. 1. Two other concurrent
`
`requests for inter partes reviews, IPR2018-00131 and IPR2018-00132,
`
`involve challenges to claims of the ’686 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., No. 2:09-cv-00274-DF-CE
`
`(E.D. Tex.) (filed Sept. 14, 2009); PalTalk Holdings, Inc. v. Microsoft Corp.,
`
`Case No. 2:06-cv-00367-DF (E.D. Tex.) (filed Sept. 12, 2006); and Mpath
`
`Interactive v. Lipstream Networks, Inc., No. 3:99-cv-04506-WHA (N.D.
`
`Cal.) (filed Oct. 7, 1999). Pet. 1–2.
`
`C. The ’523 Patent
`
`The ’523 patent describes a “group messaging server” and a “method
`
`for deploying interactive applications over a network containing host
`
`computers and group messaging servers.” Ex. 1001, [57]. Figure 5,
`
`reproduced below, illustrates a unicast network over which the interactive
`
`applications may be deployed.
`
` 2
`
`
`
`
`
`

`

`IPR2018-00130
`Patent 5,822,523
`
`
`
`
`
`Figure 5 depicts a wide area network with hosts 58, 59, 60, and 61,
`
`and a group messaging server (“GMS”) 62. Id. at 8:61–9:1. Host 58 has
`
`Transport Level Protocol (TLP) address A and Upper Level Protocol (ULP)
`
`address H. Id. at 8:62–63. Host 59 has TLP address C and ULP address J,
`
`host 60 has TLP address B and ULP address I, and host 61 has TLP address
`
`D and ULP address K. Id. at 8:63–65. GMS 62 has TLP address S. Id. at
`
`9:10. The conventional unicast network includes network links 69, 70, 71,
`
`72, 73, 74, 75, 76, and 77, and unicast routers 63, 64, 65, 66, 67, and 68. Id.
`
`at 8:65–9:1. GMS “62 receives messages from the hosts addressed to a
`
`message group and send[s] the contents of the messages to the members of
`
`the message group.” Id. at 9:1–4.
`
` 3
`
`
`
`
`
`

`

`IPR2018-00130
`Patent 5,822,523
`
`
`Figure 7, reproduced below, depicts ULP datagrams with payload
`
`aggregations for implementing an interactive gaming application between
`
`the four hosts in Figure 5.
`
`
`
`
`
`Figure 7 shows GMS (group messaging server) 62 receiving multiple
`
`messages 96, 97, 98, and 99 before sending them to hosts within message
`
`group G. Id. at 9:18–20, 10:24–28. As shown in Figure 7, multiple
`
`messages 96, 97, 98, and 99, each respectively contain payload P1, P2, P3,
`
`and P4, three of which GMS aggregates into a single larger message, 100,
`
`101, 102, or 103. Id. Prior to aggregation, host 58 sends message 96
`
`(shown in Figure 7 as “Host A sends”), host 60 sends message 97, host 59
`
`sends message 98, and host 61 sends message 99, wherein each of the
`
`messages from the hosts has destination TLP address S and ULP address G
`
` 4
`
`
`
`
`
`

`

`IPR2018-00130
`Patent 5,822,523
`
`for GMS 62. Id. at 10:28–32. After GMS 62 receives all four of these
`
`messages, it creates four outbound messages 100, 101, 102, and 103. Id. at
`
`10:29–30. Aggregated message 100 includes source TLP address S and
`
`destination TLP address A as header information encapsulating ULP address
`
`H for host 58 and aggregated payload P2, P3, and P4, respectively, from the
`
`messages from hosts 59, 60, and 61. See id. at 10:34–36, 13:59–66, 14:40–
`
`42, 17:19–21. In a similar manner, aggregated message 101 targets host 60,
`
`aggregated message 102 targets host 59, and aggregated message 103 targets
`
`host 61. Id. at 10:36–37.
`
`Figure 9, reproduced below, depicts a datagram format and address
`
`format for ULP messages.
`
`
`
`
`
`
`
`Figure 9 shows a ULP datagram message comprising elements 123, 124,
`
`125, 126, 127, 128, and 129. Id. at 13:62–64. Transport datagram TLP
`
`header 123 encapsulates the ULP datagram that includes ULP message type
`
`field 124, destination ULP address 125, address count field 126, auxiliary
`
`destination address 127 and 128, and finally payload 129. Id. at 13:59–
`
`14:36. Items 116, 117, 118, 119, 120, 121, and 122 define the payload
`
` 5
`
`
`
`
`
`

`

`IPR2018-00130
`Patent 5,822,523
`
`format of the ULP datagram. Id. at 14:37–40. Item 116 specifies the
`
`message count and defines the number of payload elements contained in the
`
`pay load. Id. at 14:38–40. Items 117, 118, and 119 comprise the first
`
`payload element in the payload, and items 120, 121, and 122 comprise the
`
`last payload element in the payload. Id. at 14:42–47. In particular, item 117
`
`specifies the ULP address of the source of the first payload element, item
`
`118 specifies the data length for the data in the first payload element, and
`
`item 119 constitutes the actual data. Id. at 14:43–46. 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. See id. at 14:46–47.
`
`
`
`The ’523 patent refers to “TLP such as IP (where the message header
`
`contain the source and destination TLP addresses),” with the message
`
`including “destination ULP address G.” Id. at 9:5–11. As indicated above,
`
`the ’523 patent refers to payloads that contain data and addresses: “payload
`
`P2 contain[s] data and source ULP address I,” and “payload P3 contain[s]
`
`data and source ULP address J.” Id. at 9:16–19.
`
`D. Challenged Claim 1
`
`
`
`Claim 1, the sole independent challenged claim, follows:
`
`1. A method for providing group messages to a plurality of host
`computers connected over a unicast wide area communication
`network, comprising the steps of:
`
`
`
`providing a group messaging server coupled to said network, said
`server communicating with said plurality of host computers
`using said unicast network and maintaining a list of message
`groups, each message group containing at least one host
`computer;
`
`
` 6
`
`
`
`
`
`

`

`IPR2018-00130
`Patent 5,822,523
`
`
`sending, by a plurality of host computers belonging to a first
`message group, messages to said server via said unicast network,
`said messages containing a payload portion and a portion for
`identifying said first message group;
`
`
`
`aggregating, by said server in a time interval determined in
`accordance with a predefined criterion, said payload portions of
`said messages to create an aggregated payload;
`
`
`forming an aggregated message using said aggregated payload;
`and
`
`transmitting, by said server via said unicast network, said
`aggregated message to a recipient host computer belonging to
`said first message group.
`
`E. Instituted Grounds of Unpatentability
`
`Petitioner contends that the challenged claims are unpatentable for
`
`obviousness under § 103 based on the following grounds (Pet. 3):
`
`References
`
`Claims Challenged
`
`Aldred3 and RFC 16924
`
`1, 15, and 19–27
`
`Aldred, RFC 1692, and
`Ulrich5
`
`Petitioner also relies on the testimony of Dr. Steve R. White
`
`11–15, 23, and 27–30
`
`(Ex. 1007; Ex. 1053). Patent Owner relies on the testimony of Dr. Kevin C.
`
`Almeroth (Ex. 2002).
`
`
`3 WO 94/11814 (May 26, 1994) (Ex. 1009).
`
`4 Request for Comments (RFC) 1692 (Aug. 1994) (Ex. 1010).
`
`5 U.S. Patent No. 5,466,200 (Nov. 14, 1995) (Ex. 1012).
`
` 7
`
`
`
`
`
`

`

`IPR2018-00130
`Patent 5,822,523
`
`
`II. ANALYSIS
`
`A. Level of Skill
`
`Relying on the declaration of Dr. White, Petitioner asserts that a
`
`person of ordinary skill in the art at the time of the invention would have to
`
`be an individual with “at least a master’s degree (or equivalent course work)
`
`in computer science, computer engineering, or physics, and at least two
`
`years’ experience in networking interactive applications,” or a person with
`
`“at least a bachelor’s degree in computer science, computer engineering, or
`
`physics” who has “approximately four years’ experience in networking
`
`interactive applications, or the equivalent, which would include experience
`
`in network programming.” Pet. 4 (citing Ex. 1007 ¶ 42–43). Patent Owner
`
`does not assess the level of ordinary skill in the art.
`
`We adopt the Petitioner’s and Dr. White’s assessment of the level of
`
`ordinary skill in the art as consistent with the ’523 patent and the asserted
`
`prior art, and apply it to our obviousness evaluation below. Here, the prior
`
`art of record reflects the level of ordinary skill in the art. See Okajima v.
`
`Bourdeau, 261 F.3d 1350, 1355 (Fed. Cir. 2001); In re GPAC Inc., 57 F.3d
`
`1573, 1579 (Fed. Cir. 1995); In re Oelrich, 579 F.2d 86, 91 (CCPA 1978).
`
`B. Claim Construction
`
`The parties agree that the ’523 patent expired. Pet. 5; PO Resp. 1.
`
`Accordingly, we construe the challenged claims as they would be construed
`
`in district court. See 37 C.F.R. § 42.100(b) (2017) (permitting a “district
`
`court-type claim construction approach . . . if a party certifies that the
`
`involved patent will expire within 18 months from the entry of the Notice of
`
`Filing Date Accorded to Petition”).
`
` 8
`
`
`
`
`
`

`

`IPR2018-00130
`Patent 5,822,523
`
`
`In district court, claim terms carry their plain and ordinary meaning as
`
`would be understood by a person of ordinary skill in the art at the time of the
`
`invention and in the context of the entire patent disclosure. Phillips v. AWH
`
`Corp., 415 F.3d 1303, 1313 (Fed. Cir. 2005) (en banc). “There are only two
`
`exceptions to this general rule: 1) when a patentee sets out a definition and
`
`acts as his own lexicographer, or 2) when the patentee disavows the full
`
`scope of a claim term either in the specification or during prosecution.”
`
`Thorner v. Sony Comput. Entm’t Am. LLC, 669 F.3d 1362, 1365 (Fed. Cir.
`
`2012). Only terms in controversy must be construed and only to the extent
`
`necessary to resolve the controversy. Vivid Techs., Inc. v. Am. Sci. & Eng’g,
`
`Inc., 200 F.3d 795, 803 (Fed. Cir. 1999); Nidec Motor Corp. v. Zhongshan
`
`Broad Ocean Motor Co., 868 F.3d 1013, 1017 (Fed. Cir. 2017) (applying
`
`Vivid Techs. in the context of an inter partes review).
`
`Petitioner notes Patent Owner “advanced several constructions for the
`
`claim elements” in prior district court litigation. See Pet. 5. Petitioner
`
`contends the “precise scope” of the terms need not be determined, provided
`
`the terms track “any interpretation consistent with their plain and ordinary
`
`meaning in the context of the [’]523 [p]atent.” Id. at 6.
`
`After determining via a teleconference with the parties that with
`
`respect to three claim terms, Patent Owner’s proposed constructions in its
`
`Preliminary Response differed from what Patent Owner initially provided in
`
`prior district court litigation, we authorized the filing of a Preliminary Reply
`
`by Petitioner and a Sur-Reply by Patent Owner to address three terms:
`
`“aggregated payload,” “aggregated message,” and “payload portion.” Paper
`
`8. In its Patent Owner Response, Patent Owner maintains the constructions
`
`it proposed in its Preliminary Response. As discussed below and as set forth
`
` 9
`
`
`
`
`
`

`

`IPR2018-00130
`Patent 5,822,523
`
`in the Institution Decision, the construction of the three terms involves the
`
`overlapping issue of a transport layer header.6
`
`1. “aggregated payload”
`
`The Petition contends the term “aggregated payload,” as recited in
`
`claim 1, should carry its plain and ordinary meaning consistent with the ’523
`
`patent. See Pet. 5–6. According to Petitioner, an “aggregated payload”
`
`should be construed as “[a] collection of two or more data items.” See Pet.
`
`Prelim. Reply 1; Reply 11–12. 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 (emphasis
`
`added). 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 into an aggregated
`payload. The 14 aggregated payload is included in a single
`aggregated message with a single transport layer message
`header. As explained above in Section II.A., the specification of
`the ‘523 Patent describes that transport layer headers are
`removed from messages sent to the group messaging server.
`
`Id. at 13–14 (citing Ex. 1001, 20:14–30; Ex. 2002 ¶ 56).
`
`As noted above, Petitioner contends that “aggregated payload” should
`
`be construed as “[a] collection of two or more data items.” See Pet. Prelim.
`
`Reply 1; Reply 11–12. Petitioner notes that in prior litigation, Patent Owner
`
`
`6 The parties do not challenge our initial claim construction of the term
`“group messaging server” (“GMS”) as recited in claim 1. See Inst. Dec. 18–
`20. For the reasons set forth in the Institution Decision, we construe a GMS
`as “a server or general purpose computer system that provides group
`messaging capability.” See id.
`
`
`
`
`
`10
`
`

`

`IPR2018-00130
`Patent 5,822,523
`
`submitted a construction for “aggregating . . . said payload portions” without
`
`submitting the negative limitation regarding the “transport layer header”
`
`requirements. See Pet. Prelim. Reply 2 (citing Ex. 1016, 93, 121–22).
`
`Petitioner contends these “prior positions” undermine Patent Owner’s
`
`position in this proceeding. See id.; Reply 13 (asserting Patent Owner’s
`
`“district court construction of ‘aggregating/aggregated’ . . . includes no
`
`‘transport layer header’ requirement” (citing Ex.1055, 2–3)), 16 (asserting
`
`that in prior district court proceedings, Patent Owner “never advanced a
`
`‘transport layer message header’ requirement until after these [inter partes]
`
`proceedings were filed” (citing Ex. 1005, 396–97; Ex. 1006, 234–36; Ex.
`
`1052, 108:8–24; Ex. 1054, Ex. A, 1, 3)).7
`
`Turning to the specification, Petitioner contends that “the ’523 patent
`
`explains that the Internet Protocol (IP) and conventional networking use the
`
`OSI [Open System Interconnection] reference model for layers of network
`
`protocols.” Pet. Prelim. Reply 4 (citing Ex. 1001, 3:24–50 (citing RFC
`
`791)). According further to Petitioner, in OSI network layers, “an IP packet
`
`payload may be an entire TCP [‘Transmission Control Protocol’] packet
`
`including a TCP header and payload.” Id. (citing Ex. 1011 (RFC 791), 1).
`
`
`7 Petitioner alleges the ’523 patent creates a distinction between layers and
`levels. See Reply 17. The ’523 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.
`1001, 12:46–50; accord id. at 8:34–41. The ’523 patent also refers to “the
`OSI reference model for layers of network protocols.” Id. at 3:27. Our
`claim construction and holding do not turn on any alleged distinction
`between level and layer, but we agree with Petitioner that the ’523 patent
`discusses TLP as either IP or TCP/IP. See id. at 17–18.
`
`
`
`
`11
`
`

`

`IPR2018-00130
`Patent 5,822,523
`
`The ’523 patent refers to using “TLP such as IP.” Ex. 1001, 9:6. In the
`
`“Summary of the Invention,” the ’523 patent states “[i]n the OSI reference
`
`model the ULP can be thought of as a session layer protocol built on top of a
`
`transport or applications layer protocol.” Id. at 8:37–39. The ’523 patent
`
`similarly relates ULP and TLP to the OSI model:
`
`The protocol is called the Upper Level Protocol (ULP) since
`it is layered above the existing net(cid:173)work Transport Level
`Protocol (TLP). In the OSI reference model the protocol can
`be described as a Session Layer protocol on top of the
`Transport Layer of the network.
`Ex. 1001, 12:46–51.
`
`Petitioner explains further that “OSI network layers are hierarchical—
`
`the packet for each layer (containing a header and payload) encapsulates the
`
`packets for the layers above: thus, an IP packet payload may contain an
`
`entire TCP packet including a TCP header and payload.” Reply 13; see also
`
`Pet. Prelim. Reply 4 (similar explanation). Petitioner contends that
`
`testimony in previous proceedings by Dr. Almeroth, Patent Owner’s
`
`declarant, supports Petitioner. See Reply 13–14. As an example, Petitioner
`
`provides the following diagram by Dr. Almeroth:
`
`
`
`
`12
`
`

`

`IPR2018-00130
`Patent 5,822,523
`
`
`
`Id. at 14 (reproducing the above figure from Ex. 1056 ¶ 68). The above
`
`figure represents encapsulation of higher layers, including TCP segments
`
`and headers, as data forming an IP datagram. Dr. Almeroth explains as
`
`
`
`follows:
`
`This process of adding a layer header to the data from the
`preceding layer is sometimes referred to as “encapsulation”
`because the data and layer header is treated as the data for the
`immediately following layer, which, in turn, adds its own layer
`header to the data from the preceding layer. Each layer is
`generally not aware of which portion of the data from the
`preceding layer constitutes the layer header or the user data; as
`such, each layer treats the data it receives from the preceding
`layer as some generic payload.
`
`Ex. 1056 ¶ 68 (emphases added).
`
`As another example, Petitioner provides the following diagram
`
`submitted by Dr. Almeroth in a declaration in another proceeding:
`
`
`
`
`13
`
`

`

`IPR2018-00130
`Patent 5,822,523
`
`
`
`Reply 14 (reproducing the above figure from Ex. 1058 ¶ 56). The above
`
`figure, presented by Dr. Almeroth in a declaration for another proceeding,
`
`similarly represents encapsulation of headers from upper level layers that
`
`lower layers treat as data. See Ex. 1058 ¶ 57 (“Encapsulation appends
`
`additional headers for other lower level layers in the OSI model to the
`
`application layer data. The image above illustrates this by the addition of
`
`“H” blocks (i.e., headers) to the left of the application message at each lower
`
`OSI level.”). In summary, according to Dr. Almeroth, encapsulation using
`
`the OSI model involves treating upper level headers and other data as data.
`
`Petitioner also relies on similar teachings in RFC 791, which states
`
`that the IP module that a TCP module calls could “take a TCP segment
`
`(including the TCP header and user data) as the data portion of an [IP
`
`datagram].” Reply 14 (quoting Ex. 1011, 1). As background information,
`
`
`
`
`14
`
`

`

`IPR2018-00130
`Patent 5,822,523
`
`the ’523 patent refers to RFC-791 as discussing how TCP “ensures reliable,
`
`in order delivery,” of packets in the OSI model. See Ex. 1001, 3:26–47.
`
`Patent Owner concedes the claims encompass encapsulated headers,
`
`as used in the OSI model. See PO Resp. 8 (“Patent Owner’s construction
`
`position is not that the term ‘aggregated message’ does not encompass
`
`encapsulated headers.”) (citing Inst. Dec. 14–15)).8 According to Patent
`
`Owner, “Patent Owner’s construction is that an ‘aggregated message’
`
`includes only a single transport layer message header.” Id. at 8–9.
`
`Nevertheless, as explained further below and above, and as Patent Owner
`
`concedes, the ’523 patent supports encapsulating header information as data.
`
`
`
`Patent Owner annotates Figure 9 of the ’523 patent as follows:
`
`
`8 Patent Owner’s concession responds to the panel’s preliminary
`determination in the Institution Decision stating “Patent Owner does not
`dispute, in a clear fashion, Petitioner’s contention that the claims may
`encompass encapsulated headers.” Inst. Dec. 13.
`
`
`
`
`
`
`15
`
`

`

`IPR2018-00130
`Patent 5,822,523
`
`
`PO Resp. 7.
`
`
`
`
`
`As annotated and described by Patent Owner, Figure 9 shows “the
`
`overall structure of an aggregated message includes a message header (blue)
`
`a payload (green), and multiple payload elements (red) included as part of an
`
`aggregated payload.” Id. (citing Ex. 1001, 14:37–52). Patent Owner
`
`contends “[t]he fields 123, 124, 125, 126, 127 and 128 constitute the
`
`message header” with “the transport header 123” of “[a]n upper layer
`
`protocol (ULP) message.” Id. (citing Ex. 2002 ¶ 47). Patent Owner’s
`
`characterization conflates transport header 123 and encapsulated ULP
`
`header portions 124–128. Encapsulated portions 124–128 do not form part
`
`of the “message header,” contrary to Patent Owner’s characterization. In
`
`other words, the specification sates“[t]he transport header 123 is the
`
`datagram header of the TLP that is encapsulating the ULP datagram. The
`
`ULP message type field 124 . . . . must be present in a ULP datagram.” Ex.
`
`1001, 13:64–14:3 (emphasis added).9 In any event, Patent Owner states
`
`“[e]ach of the aggregated payload elements include the source ULP address
`
`
`9 See Ex. 1001, 13:59–66 (“The ULP can be implemented as a datagram
`protocol by encapsulating addresses, message type information and the
`message payload within a datagram of the underlying network transport
`protocol. The general form of the ULP datagram message format is shown
`in FIG. 9 as elements 123, 124, 125, 126, 127, 128 and 129. The transport
`header 123 is the datagram header of the TLP that is encapsulating the ULP
`datagram. The ULP message type field 124 . . . must be present in a ULP
`datagram.” (emphases added)); Ex. 1053 ¶¶ 6–8 (describing encapsulated
`payload and address portions as typical under the OSI, TCP, and IP
`frameworks and citing Dr. Almeroth’s testimony from another proceeding).
`In any case, the outcome here does not depend on what the disclosed
`transport header includes in this particular disclosed example of Figure 9.
`
`
`
`
`16
`
`

`

`IPR2018-00130
`Patent 5,822,523
`
`117, 120 of the transmitted payload element, the data length 118, 121 of the
`
`payload element and the actual data 119, 122.” Id. at 8 citing (Ex. 1001,
`
`14:37–50).
`
`
`
`Patent Owner advanced similar arguments prior to institution, and the
`
`panel determined the following:
`
`As Patent Owner argues, Figure 9 of the specification does
`not include a TLP header in each payload packet of the
`aggregated payload. See Prelim. Resp. 7–8. Nonetheless, as
`noted above, headers, such as headers 117 and 118, or 120 and
`12[1], appear in each payload. See Ex. 1001, 23:11–12 (“Each
`payload item in a message queue will contain a ULP source
`address, a data length and the data to be sent.”). Even though an
`embodiment strips out a TLP header from a “message,” it also
`looks up a TLP header of the host from “host address map 137.”
`Id. at 23:20–22. The specification consistently shows that a
`payload, even within an aggregated payload, may contain header
`fields. See, e.g., id. at Fig. 9.
`
`Inst. Dec. 13–14.
`
`Patent Owner does not dispute the preliminary finding set forth in the
`
`Institution Decision that “[t]he specification consistently shows that a
`
`payload, even within an aggregated payload, may contain header fields.” Id.
`
`at 14; see PO Resp. 8–9. Rather, Patent Owner argues that “[t]here is thus
`
`no indication in the ‘523 Patent that multiple TLP headers are included
`
`within the aggregated message.” PO Resp. 11.
`
`The record supports the preliminary finding, and the parties agree, that
`
`the ’523 patent discloses using a TLP header with a datagram protocol to
`
`encapsulate messages and/or payloads that include headers (e.g., address
`
`information, message type), as discussed above, and as similarly occurs in
`
`the OSI model. See Ex. 1001, 13:59–62, 14:37–61, 26:28–45; PO Resp. 8–
`
`9; Reply 13–15. As such, and as discussed further below, the ’523 patent
`
`
`
`
`17
`
`

`

`IPR2018-00130
`Patent 5,822,523
`
`generally 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.
`
`Nevertheless, Patent Owner argues that the ’523 patent does not
`
`support encapsulated TLP headers because excluding a TLP header creates
`
`data reduction according to the ’523 patent. See PO Resp. 12 (citing Inst.
`
`Dec. 15; Ex. 1001, 24:23–28). Patent Owner repeats the following
`
`preliminary finding from the Institution Decision: “The specification
`
`describes any data reduction as significant only for small packet sizes, and
`
`generally attributes data reductions due to message aggregation.” PO Resp.
`
`12 (quoting Inst. Dec. 14 (citing Ex. 1001, 24:23–28)).
`
`Patent Owner responds to this preliminary finding by arguing as
`
`follows:
`
`The ‘523 Patent however clearly discusses significant data
`reduction by eliminating transport headers from payloads. The
`‘523 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. 1001, 24:23–28 (emphasis
`added). The ‘523 Patent also states that an aggregated message
`is “longer and contains multiple payloads, but this is a significant
`improvement over received multiple messages with the wasted
`overhead of multiple message headers and message processing
`time.” Ex. 1001, 10:40–44.
`
`Id. at 12.
`
`Patent Owner (id. at 12–13) and Dr. Almeroth (Ex. 2002 ¶¶ 53–54)
`
`focus on reduced data rates, but the specification also describes savings
`
`based on aggregation for all packet sizes based on “greatly reduc[ing] the
`
`
`
`
`18
`
`

`

`IPR2018-00130
`Patent 5,822,523
`
`total message rate received by the hosts,” because “[a] single message to a
`
`host will be able to carry multiple payload items received from the other
`
`hosts during the aggregation period.” Ex. 1001, 24:12–15 (emphasis added).
`
`This shows that savings in message rate occurs regardless of whether the
`
`data packet portion contains encapsulated header information, because no
`
`wasted overhead occurs in treating the encapsulated header data as data. So
`
`this message rate savings still occurs even if the encapsulated portion of the
`
`packet includes TCP header information, because the system processes that
`
`encapsulated header portion as data, as Dr. Almeroth generally explains in
`
`prior proceedings as noted above. See Ex. 1056 ¶ 68; Ex. 1058 ¶ 56. The
`
`’523 patent supports this finding as it recognizes that “[a]ggregation will be
`
`very effective in collecting together all of the messages from all of the other
`
`hosts into a single message for each member of the group,” and “[t]his
`
`reduces processing . . . since a single message will be received rather than
`
`many separate messages.” Ex. 1001, 24:18–23 (emphasis added). The
`
`specification, therefore, does not limit an aggregated payload or aggregated
`
`messages, as claimed, from including encapsulated headers as data in a
`
`single aggregated message (which also similarly occurs in the OSI model),
`
`including transport layer headers encapsulated within the payload.10
`
`
`10 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.
`
`
`
`
`
`
`19
`
`

`

`IPR2018-00130
`Patent 5,822,523
`
`
`Regarding the data rate, it will increase if a packet includes more
`
`data, as Patent Owner argues. See PO Resp. 12. Patent Owner contends that
`
`“significant data reduction [occurs] by eliminating transport headers from
`
`payloads.” Id. But as we initially determined in the Institution Decision,
`
`and as the specification states, “the savings will be significant [only] for
`
`small payload items since there will be only one message header comprising
`
`fields 123, 124, and 125.” Ex. 1001, 24:25–28 (emphasis added); see Inst.
`
`Dec. 15 (citing Ex. 1001, 24:23–28). As we also noted in the Institution
`
`Decision, the challenged claims do not limit the payload size. See Inst. Dec.
`
`15. The reduced message rate benefit described above that accrues for a
`
`single message occurs regardless of the packet sizes aggregated in the single
`
`message. See Ex. 1001, 24:18–23. So the specification still confers a
`
`message rate benefit without necessarily limiting the claims to cover only
`
`small packets based on a small packet data rate benefit. Moreover, Patent
`
`Owner does not urge a packet size limitation in its claim construction.
`
`The specification also generally allows for different header and packet
`
`types and layers following the OSI model according to the specification.
`
`See, e.g., Ex. 1001, 3:41–52, 8:22–37, 12:42–54, 14:37–46, 26:28–45. As
`
`an example, the specification refers to a preferred embodiment as specifying
`
`“the TLP protocol is TCP/IP,” and it states that for aggregated messages,
`
`“the [encapsulated] payload will still contain the source host ULP addresses
`
`in each [of] the payload items.” Id. at 26:28–50. In general, however, the
`
`specification supports many types of packets, further showing that the broad
`
`claims must not be limited to stripping TCP or TLP headers from a payload:
`
`“The wide area network used to transport the ULP protocol need not be the
`
`Internet or based on IP. Other networks with some means for wide area
`
`
`
`
`20
`
`

`

`IPR2018-00130
`Patent 5,822,523
`
`packet or datagram transport are possible including ATM networks or a
`
`digital cable television net(cid:173)work.” Id. at 27:38–43.
`
`
`
`On this record, the ’523 specification supports Petitioner’s argument
`
`that the claim term “aggregated payload,” consist