Trials@uspto.gov
`Tel: 571-272-7822
`
`Paper11
`Entered: May 15, 2018
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`RIOT GAMES,INC.,
`Petitioner,
`
`Vv.
`
`PALTALK HOLDINGS, INC.,
`Patent Owner.
`
`Case IPR2018-00132
`Patent 6,226,686 & 6,226,686 C1!
`
`Before THU A. DANG and KARL EASTHOM,
`Administrative Patent Judges.
`
`DANG,Administrative Patent Judge.
`
`DECISION
`Institution of Inter Partes Review
`35 US.C. 314(a)
`
`' The Petition challenges original claims and claims issued pursuant to an ex
`parte reexamination.
`
`
`Tel: 571-272-7822
`
`Paper11
`Entered: May 15, 2018
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`RIOT GAMES,INC.,
`Petitioner,
`
`Vv.
`
`PALTALK HOLDINGS, INC.,
`Patent Owner.
`
`Case IPR2018-00132
`Patent 6,226,686 & 6,226,686 C1!
`
`Before THU A. DANG and KARL EASTHOM,
`Administrative Patent Judges.
`
`DANG,Administrative Patent Judge.
`
`DECISION
`Institution of Inter Partes Review
`35 US.C. 314(a)
`
`' The Petition challenges original claims and claims issued pursuant to an ex
`parte reexamination.
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`A.
`
`Background
`
`I.
`
`INTRODUCTION
`
`Riot GamesInc. (“Petitioncr”) filed a Petition requesting an inter
`partes review ofclaims 1, 3, 7, 12, 18, 22-27, 36, 41-46, 55, and 58-63 of
`US. Patent No. 6,226,686 (Ex. 1002,“the ’686 patent”). Paper 1 (“Pet.”).
`
`PalTalk Holdings, Inc. (“Patent Owner”) filed a Preliminary Response.
`
`Paper 6 (“Prelim. Resp.”).
`~ We have jurisdiction under35 U.S.C. § 314, which provides that an
`inter partes review maynotbeinstituted “unless .
`.
`. there is a reasonable
`likelihood that the petitioner would prevail with respect to at least 1 of the
`claims challenged in the petition.” 35 U.S.C. § 314(a); see also 37 C.F.R.
`42.4(a) (“The Board institutes the trial on behalf of the Director.”). Upon
`considering the record before us, we determine that Petitioner has shown a
`reasonablelikelihood that it would prevail in showing the unpatentability of
`
`at least one of the challenged claims. Accordingly, we grantthe Petition.
`
`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 Corporation, No. 16-cv-
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`1239-JFB-SRF (D. Del.) (filed Dec. 16, 2016); PalTalk Holdings, Inc. v.
`Riot Games, Inc., Case No. 1:16-cv-1240-JFB-SRF (D. Del.) (filed Dec. 16,
`
`2016); PalTalk Holdings, Inc. v. Sony Computer Entertainment America,
`Inc. et al., Case No. 2:09-cv-00274-DF-CE (E.D. Tex.) (filed Sept. 14,
`2009); PalTalk Holdings, Inc. v. Microsoft Corporation, Case No, 2:06-cv-
`00367-DF(E.D. Tex.) (filed Sept. 12, 2006); and Mpath Interactive v.
`Lipstream Networks, Inc., et al., Case 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 No.
`08/896,797, filed on July 18, 1997, now US 6,018,766, which in turn isa
`continuation of application No. 08/595,323, filed on February 1, 1996, now
`US 5,822,523. Ex. 1002, at [45], [22], [63].
`The ’686 patent is directed to “server-group messaging,” and
`describes a “method for deploying interactive applications over a network
`containing host computers and group messaging servers.” Jd. at [57].
`Figure 5, reproducedbelow,illustrates a unicast network over which the
`interactive applications may be deployed.
`
`
`
`IPR2018-00132
`
`Patent 6,226,686
`
`Figure 5
`Figure 5 depicts a wide area network with hosts 58, 59, 60, and 61, anda
`group messagingserver (“GMS”) 62. Jd. at 8:65—66. Host 58 has
`Transport Level Protocol (TLP) address A and Upper Level Protocol (ULP)
`address H. Jd. at 8:66-67. Host 59 has TLP address C and ULP addressJ,
`
`host 60 as TLP address B and ULP addressI, host 61 has TLP address D
`
`and ULP address K, and GMS62 has TLP address S. Jd. at 8:67-9:2. “The
`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. GMS62 “receives messages from the hosts addressed to a message
`group andsendsthe contents of the messages to the members of the
`message group.” Jd. 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-00132
`Patent 6,226,686
`
`36
`
`97
`
`Host A Sends
`
`Lats]¢{P|
`
`100
`
`101
`
`eraetta
`
`Host A Receives
`
`:
`
`(8Ts1s|2|apeinatea
`
`Host B Recelves
`
`;
`
`Host B Sends
`
`102
`
`Host C Sends
`” Host C Receives
`Pe[se[Ps|\s[Tesrryre|Ps]
`
`Host D Sends
`Host D Receives
`(ots{sc{rs|‘so[«[Pi[21P3|
`
`103
`
`100
`
`96
`
`401 enane og
`
`Group Server Sends
`
`Group Server Receives
`
`~LALSTs[Pt
`
`oe repsLe[rs]
`2~rsTorTe Ts [elr) *-foTsl[e]]
`103
`$9
`
`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. Id. 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 (shown in 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 GMS62.
`
`Id. at 10:28-32. After GMS 62 receives all four of these messages,it
`
`creates four outbound messages 100, 101, 102, and 103. Td. at 10:33-34.
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`Aggregated message 100 includes destination TLP address A and ULP
`
`address H for host 58 and aggregated payload P2, P3, and P4 respectively
`from the messages from hosts 59, 60, and 61. Jd. at 10:38-40. Aggregated
`message 101 targets host 60, aggregated message 102 targets host 59, and
`
`aggregated message 103 targets host 61. Jd. at 10:41—-42.
`Figure 9, reproduced below, depicts a datagram format and address
`
`format for ULP messages.
`
`Transport|ULP Msg.|Dest.ULP|Address} Destination | Destination Paytosd
`
`
`
`Header Type|Address|Count|Address 4 Address Ni
`
`4123
`
`124
`
`126
`
`126
`
`127
`
`128
`
`129
`
`Date
`[Source Up]
`voce,
`Data
`Message Source LP!
`
`Count|Address 1|Lengiht Address N|Length N.
`
`
`116
`
`7
`
`18
`
`119
`
`120
`
`121
`
`122
`
`130
`
`131
`
`132
`
`Figure 9
`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 countfield 126, auxiliary
`destination address 127 and 128, andfinally payload 129. Jd. at 13:64—
`
`14:37. Items 116, 117, 118, 119, 120, 121, and 122 define the payload
`
`format of the ULP datagram. Id. at 14:38-39. Item 116 specifies the
`message count and defines the number of payload elements containedin the
`pay load. Items 117, 118, and 119 comprisethefirst payload element in the
`payload, and items 120, 121, and 112 comprise the last payload elementin
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`the payload. Jd. at 14:39-48. In particular, item 117 specifies the ULP
`address of the sourceof the first payload element, item 118 specifies the
`data length for the data in the first payload element, and item 119
`constitutes the actual data. Similarly, item 120 specifies the ULP address of
`the source ofthe last payload element N, item 121 specifies the data length
`for the data in the last payload element N,and item 122 constitutes the
`
`actual data. Jd.
`
`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:
`1,
`A method forfacilitating communications amonga 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;
`(2) receiving join messages fromafirst subset ofthe plurality of host
`computers, wherein each ofsaid join messagesspecifies said
`message group;
`(3) receiving host messages from a second subset of said first subset
`of the plurality of host computers belonging to said message group,
`wherein each of said messages contains a payload portion and a
`portion that is used to identify said message group;
`(4) aggregating said payload portions of said host messages received
`from said second subset of the plurality of host computers to create
`an aggregated payload;
`(5) forming an aggregated messageusing 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
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`application operating consistently on eachofsaid first subset of the
`plurality of host computers.
`Ex. 1002, 27:50-28:8.
`
`E.
`
` Asserted Grounds of Unpatentability
`
`Petitioner contends that the challenged claims are unpatentable based
`
`on the following specific grounds (Pet. 21, 51, and 66):
`
`
`
`Reference Basis|Claim Challenged
`
`Aldred,? and RFC 16923
`§ 103
`1, 3,7, 12, 18, 26, 27, 45,46, 62,
`
`
`
`
`
`
`
`Aldred, RFC 1692, and Ulrich*|§ 103 22-27, 41-46, and 58-63
`
`and 63
`
`Aldred, RFC 1692, and Denzer?|§ 103 36, and 55
`
`
`
`
`Petitioner also relies on the testimonies of Dr. Steve R. White and
`
`David H.Crocker.® Exs. 1007, 1026. Patent Ownerrelies on,inter alia, the
`
`testimony of Nancy Miracle. Ex. 2001.
`
`II.
`
`ANALYSIS
`
`A.
`
`Claim Construction
`
`The parties agree that the ’686 patent expired. Pet. 5; Prelim. Resp.
`2. Accordingly, we construe its challenged claims as they would be
`
`2 WO 94/11814 (May 26, 1994) (“Aldred”; Ex. 1009).
`3 Request for Comments (RFC) 1692 (Aug. 1994) (“RFC 1692”; Ex. 1010).
`4 US 5,466,200 (Nov. 14, 1995) “Ulrich”; Ex. 1012).
`SUS 5,307,413 (Apr. 26, 1994) (“Denzer”; Ex. 1014).
`6 Petitioner superfluously cites the “Knowledge of an Ordinary Artisan,”
`which wedonot repeat, as an obviousness determination takes into account
`that knowledge.
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`construed in district court. See 37 C.F.R. § 42.100(b) (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”).
`In district court, claim termscarry their plain and ordinary meaning
`as would be understood by a person ofordinary skill in the art at the time of
`the invention and in the contextof the entire patent disclosure. Phillipsv.
`AWHCorp., 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).
`Petitioner notes Patent Owner“advanced several constructionsfor. .
`
`Inits
`. claim elements”in prior district court litigation. See Pet. 5-6.
`Petition, Petitioner generally contends the “precise scope”ofthe terms need
`not be determined, provided the termstrack “any interpretation consistent
`with their plain and ordinary meaning in the context ofthe [’]686 [p]atent.”
`Id.
`
`In its Preliminary Response, Patent Ownerproposesconstructions for
`several terms. Prelim. Resp. 3-13. After determining via a teleconference
`with the parties that with respect to three claim terms, Patent Owner’s
`proposed constructions differed from whatit providedin prior district court
`litigation (Paper 8), we authorized the filing of a Preliminary Reply by
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`Petitioner (Paper 9 (“Prelim. Reply”)) and a Sur-Reply by Patent Owner
`(Paper 10 (“Sur-Reply”)). The claim termsat issue in this proceeding and
`addressed by thebriefing include “aggregated payload,” “aggregated
`message,”and “payloadportion.” Prelim. Reply 1. As discussed below,in
`general, the Specification, Petition, Preliminary Response, evidence, and
`additional briefing show collectively that the constructionof the three terms
`turns on similar evidence and includes the overlapping issue of a transport
`layer header. Wealso construe the claim term “group messaging server”
`addressed by Patent Owner with respect to claim 12. Prelim. Resp. 3-4.
`1. “aggregated payload”
`Asindicated above, the Petition contends the term “agsregated
`payloads” should carry its “plain and ordinary meaningin the context of the
`°686 patent,” but the Petition does not set forth an explicit claim
`construction. See Pet. 6—7. Patent Owner contends“aggregated payload”
`should be construed as “[a] collection of two or more dataitems that does
`not include transport layer headers.” Prelim. Resp. 11 (emphasis added).
`To support its construction, Patent Owner contendsthat
`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 andare aggregated to be included into a
`single message with a single message headerto besent to a
`host, where the message includes payload portions from the
`messagessent by the hosts.
`Id. at 12.
`. describes
`.
`Patent Ownerexplainsfurther that “the specification .
`that transport layer headers are removed from messagessent to the
`group messaging server.” Id. (citing Ex. 1002, 20:14-30; Ex. 2001 q41 38,
`41). Patent Owneralso contends that the Specification describes removing
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`“payload items from a message queue 143” and then aggregating them after
`accumulating them in an aggregation buffer. See id. (quoting Ex. 1002,
`
`23:53-55) (emphasis omitted).
`The Specification explains that “[t]he effect of aggregation will be to
`greatly reduce the total messagerate received by the hosts,” because “[a]
`single message to a host will... carry multiple payload items received from
`the other hosts.” Ex. 1002, 24:12-15. Another benefit involves reducing
`
`the total data rate, because “aggregation eliminates the need for separate
`message headers for each payload item.” Jd. at 24:24—-25. This results in
`“significant” savings for “small payload items [because] there will be only
`one message header comprisingfields 123, 124, and 125 for multiple
`payload items.” Jd. at 24:26-28.
`In its Preliminary Reply, Petitioner essentially contends “aggregated
`payload”should be construed as “[a] collection of two or more data items.”
`See Pet. Prelim. Reply 1. Petitioner notes that in priorlitigation, Patent
`Ownersubmitted a construction for “aggregating said payload portions”
`without submitting the negative limitation regarding the “transport layer
`header” requirements. See id. at 2 (citing Ex. 1016, 93, 121-22). Petitioner
`contends these “prior positions” undermine Patent Owner’s position in this
`proceeding. See id. Petitioner also argues Patent Owner should be
`judicially estopped from narrowing its claim constructionin this proceeding
`relative to its proposed claim constructionsin priorlitigation. See id. at 2-3
`(asserting Patent Owner“has persuaded a court to acceptits positions”).
`Turning to the specification, Petitioner contendsthat “the ’686 patent
`explainsthat the Internet Protocol (IP) and conventional networking use the
`OSI reference modelfor layers of network protocols.” Jd. at 4 (citing Ex.
`
`10
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`1002, 3:29-54 (citing RFC 791)). Further, according to Petitioner, in OSI
`
`network layers, “an IP packet payload may be an entire TCP packet
`including a TCP headerand payload.” Jd. (citing Ex. 1011 (RFC 791), 1).
`Furthermore, Petitioner contends, the Preliminary Response annotates
`Figure 9, and it showsthat “[t]he aggregated payload includes payload
`elements (red) that comprise the ‘actual data’ of the payload (119 & 122)
`and headerinformation (117, 118, 120, 121), such as a source address and
`length of data in the payload.” Jd. (citing Prelim. Resp. 8; Ex. 1002,Fig.9,
`
`14:38-51).
`In its Preliminary Sur-Reply, Patent Ownerreplies that judicial
`estoppel should not and does notapply, arguing, interalia, that “issues with
`respect to the headers .
`.
`. were not addressedin the prior proceedings,” and
`none ofthe previous claim construction ordersin priorlitigation constitutes
`a final judgement. See PO Prelim. Sur-Reply 1-3. Patent Ownerfurther
`
`replies:
`[t]he annotation of Figure 9 does not concedethat the recited
`terms comprise encapsulated headers, but merely describes that
`the Source ULP Addresses by themselves do not comprise a
`transport layer message headeras described with respectto the
`referenced discussions of the OSI reference model. Jd. The
`transport layer message header includesthe fields 123-128 as
`previously discussed.
`
`PO Prelim. Sur-Reply 4—5 (citing Prelim. Resp. 7-8, Ex. 2001 J 34-36).
`Patent Owner also argues that the Specification describes significant
`savings “for small payload items [because] there will be only one message
`
`header.” Jd. at 5.
`
`Figure 9, annotated by Patent Owner, follows:
`
`11
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`
`124
`5
`126
`?
`ra
`~~
`Tearsport|ULP tan.|Cet. ULF|Anctess|Oeetisation
`eader Type|Adress|Coun|avornsst|°°" *
`
`
`
`
` ws 148
`316
`
`and
`
`
`
`
`Shassege |Kocrce UP|Date HSoucotAP| Oate
`
`
`Count|]Addess1|tengha|USPEES” f] Address. N|LengN
`
`
`
`
`WwW
`
`as
`
`Figure 9
`
`Asannotated and described by Patent Owner, Figure 9 shows a message
`with message header 123-128 (blue), a payload 129 (green) with atleast
`two payloads (red), one having mini-headers 117 and 118 and data portion
`119, and another having mini-headers 120 and 122 and data portion 122.
`
`See Ex. Prelim. Resp. 7-8; 1002, 14:37-50.
`As Patent Ownerargues, Figure 9 of the Specification does not
`include a TLP header in each payload packetof the aggregated payload.
`See Prelim. Resp. 7-8. Nonetheless, as noted above, header, such as
`headers 117 and 118, or 120 and 122, appear in each payload. See Ex.
`
`1002, 23:11-12 (“Each payload item in a message queue will contain a
`ULPsource address, a data length and the data to be sent.”). Even though
`an embodimentstrips out a TLP header from a “message,”it also looksup 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.
`In addition, the preliminary record supports Petitioner’s argument
`that the Specification describes using the OSI model, which appears to
`include encapsulating a TCP header and data as a data portion of a
`
`12
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`datagram. For example, as Petitioner states that the Specification explains
`that “the Internet Protocol (IP) and conventional networking use the OSI
`reference modelfor layers of network protocols.” Pet. Prelim. Reply 4
`
`(citing Ex. 1002, 3:24--50, and noting that portion cites RFC 791). As
`
`Petitioner explains,
`OSI networklayers are hierarchical: an IP packet payload may
`be an entire TCP packet including a TCP header and payload.
`E.g., Ex. 1011 (RFC 791), 1 (“[T]he [IP] module [could] take a
`TCP segment(including the TCP header anduser data) as the
`data portion of an [IP] datagram.”). A “payload portion” could
`thus comprise a TCP header, and an “aggregated
`payload’”/“aggregated message” could have multiple TCP
`headers.
`
`Id.
`
`Furthermore, Petitioner asserts “Patent Owner’s Preliminary
`Response concedesthese [claim] terms can comprise encapsulated
`
`headers.” Jd.
`
`Patent Ownerdoes not dispute, in a clear fashion, Petitioner’s
`contention that the claims may encompass encapsulated headers. See PO
`Prelim. Sur-Reply 4. (“The annotation ofFigure 9 does not concede that
`the recited terms comprise encapsulated headers, but merely describes that
`the Source ULP Addresses by themselves do not comprise a transport layer
`message header as described with respect to the referenced discussions of
`the OSI reference model.” (emphasis added)). In any event, on this
`preliminary record, 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
`supra Section I.C.; Ex. 1002, 13:59-62, 14:38-62.
`
`13
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`Regarding Patent Owner’s argument that excluding a TLP header
`
`creates data reduction, the challenged claims do notlimit the payload size
`
`and generally allow for different header types according to the
`Specification. See, e.g., Ex. 1002, 14:38-47. The Specification describes
`any data reduction assignificant only for small packet sizes, and generally
`attributes data reductions due to message aggregation. Jd. at 24:23—28. In
`other words, 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,” because “[a] single messageto a host
`will be able to carry multiple payload items received from the other hosts
`during the aggregation period.” Jd. at 24:12—-15. The Specification
`therefore does not limit an aggregated payload, as claimed, from including
`headersin general, including transport layer headers.’
`Onthis record, the °686 Specification supports Petitioner’s argument
`that the claim term “aggregated payload,” consistent with its ordinary and
`plain meaning, encompasses a collection of two or more data itemsthat
`may include headerstransported as data. Patent Owner’s past claim
`construction positions support this preliminary determination by showing,
`at the least, how Patent Owner viewed the meaning of various claim terms,
`
`including the three terms discussedherein.
`
`7 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 data reduction, allowing some header types within the
`scope of the claim defeats any advantage of removingaspecific type from
`that scope.
`
`14
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`2.
`
`“aggregated message”
`
`Patent Owner contends “aggregated message” means “[o]ne or more
`messages containinga single transport layer message header,destination
`data, and data items from an aggregated payload.” Prelim. 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 (Pni, Pm,
`Pn3) 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.
`Prelim. Resp. 6—7 (citing Ex. 1002, 8:1-10:67, Fig. 7).
`Similar to its arguments with respect to the “aggregated payload”as
`discussed above, Petitioner respondsthatin priorlitigation, Patent Owner
`submitted a construction for “aggregated message” without submitting the
`“transport layer header” requirements. See Pet. Prelim. Reply 2-3 (citing,
`e.g., Ex. 1016, 93). Petitioneralso relies on the similar evidence and
`reasons addressed above regarding the “aggregated payload,” showing on
`this preliminary record,that the Specification and evidence support an
`“aporegated message”as including an aggregated payloadandat least one
`headerin addition to any that may happen to be within the aggregated
`payload. See id. at 1-5; Ex. 1016, 93; Ex. 1002, Fig. 7. In other words, as
`noted above, a payload may include a header, for example, “a triplet of
`source ULP address, data length and data.” Ex. 1002, 14:40-42 (discussing
`items 117, 118, and 119). Typically, a packet message includesat least one
`header. See Pet. Prelim. Reply 4; Ex. 1016, 93; Ex. 1002, 3:24—52,Fig. 7.
`
`
`
`IPR2018-00132
`. Patent 6,226,686
`
`For the reasons similar to those explained above in construing an
`“ageregated payload,” an “aggregated message” includes a message having
`an aggregated payload and at least one header in addition to any additional
`headers that may happento be within the aggregated payload.
`
`3.
`“payload portion”
`Patent Owner submits a “payload portion” means “[a] portion of the
`original network message (that contains data item(s) conveying
`information) sent to the group messaging server remaining after the
`
`transport layer
`header is removed.” Prelim. Resp. 9-10. Aspart of its showing, Patent
`Owneracknowledgesthat “[a]n agreed construction in [previous] litigation
`for ‘payload portion’ was‘[t]he part of a message that containsdata item(s)
`conveying information.’” Jd. at n.1 (citing Ex. 1032, 2).
`As discussed above in connection with an “aggregated payload” and
`
`an “aggregated message,” Petitioner respondsthatin priorlitigation, Patent
`Ownersubmitted a construction for “payload portion” without submitting
`the “transport layer header” requirements. See Pet. Prelim. Reply 1-3
`(citing, e.g., Ex. 1032, 2). Petitioner also relies on the similar reasons and
`evidence addressed above regarding the “aggregated payload.” See id. at 3—
`
`5.
`
`Patent Owner’s proposed claim construction improperly requires
`functionality related to the group server. In other words, “[a] portion of the
`original network message: .
`. sent to the group messaging server remaining
`after the transport layer header is removed”(Prelim. Resp. 9-10) includes
`header removal steps, presumablyat the server. However, the addition of
`server functionality included in Patent Owner’s proposed construction does
`
`16
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`not embodythe ordinary and customary meaningin light of the claim
`language and specification. As noted above, a payload may include headers
`such as “a triplet of source ULP address, data length and data.” Ex. 1002,
`
`14:40-42 (discussing items 117, 118, and 119).
`
`For additional reasons similar to those explained above with respect
`
`to “aggregated payload” and “aggregated message,” on this preliminary
`record, and tracking language proposed by Patent Ownerin previous
`litigation, a “payload portion” includes “[t]he part of a message that
`contains data item(s) conveying information.” See Ex. 1002, 14:40-42
`
`(discussing items 117, 118, and 119); Ex. 1032, 2.
`4.
`“group messaging server”(claim 12)
`
`Claim 12 recites a method for “providing group messages to a
`plurality of host computers connected to a group messaging server over a
`unicast wide area communication network” comprising a step of
`
`“communicating with the plurality of host computers using the unicast
`network and maintaining a list of message groups, each message group
`
`containing at least one host computer.” Ex. 1002, 29:21—28.
`Patent Ownerproposesthe following construction for “group
`
`messaging server”:
`A server or computer system with a network interface that
`maintains a set of message groups used by the host computers
`to communicate information between themselves. The group
`messaging server must be capable of receiving messages from
`the host computers addressed to a message group and sending
`messages to the host computers that have joined the message
`group. A group messaging server can process messages with
`or without aggregated payloads, and can allow for group
`membership to change very rapidly.
`Prelim. Resp. 3-4.
`
`17
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`Patent Owner contendsthe construction “is consistent with the
`
`disclosure of the 686 patent.” Jd. at 4 (citing Ex. 2001 § 27). Patent
`
`Ownerand Ms. Miracle do not provide any citations to the °686 patentto
`support the proposed construction. Patent Owneralso contendsthat another
`party and Patent Owneragreed to the construction in priorlitigation. Id.
`
`(citing Ex. 1032, 1-2).
`However, the proposed construction improperly incorporates
`unclaimedlimitations from the Specification. The Specification states “[i]n
`
`a preferred embodiment, the [GMS]is a general purpose computer system
`with a networkinterface to connectit to a wide area network.” Ex. 1002,
`
`16:1-3. Figure 10 illustrates a GMS with Item 136, an overall! control
`function for the [GMS], and “NetworkInterface” 135. The GMSincludes
`addresses and groupserver control functionality for hosts. See id., Fig. 10.
`Accordingly, on this preliminary record, the ordinary meaning of a
`GMSinlight of the ’686 patent Specification is a “server” or “general
`purpose computersystem that provides group messaging capability,” as
`
`recited in claim 12.
`
`B.
`
`Asserted Obviousness over Aldred, and RFC 1692; Aldred,
`RFC 1692 and Ulrich; or Aldred, RFC 1692 and Denzer
`
`Petitioner alleges that claims 1, 3, 7, 12, 18, 26, 27, 45, 46, 62, and
`63 would have been obvious over Aldred and RFC 1692 as viewed by the
`knowledge of an ordinaryartisan. Pet. 21-51. Petitioner also alleges that
`claims 22-27, 41-46, and 58-63 would have been obviousoverthe
`combination of Aldred, RFC 1692 in further view of Ulrich; and that claims
`
`36 and 55 would have been obvious over the combination of Aldred, RFC
`
`1692 in further view of Denzer. Pet. 51-69. Patent Ownerraises several
`
`18
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`arguments in response. Prelim. Resp. 13-50. Brief overviews of Aldred,
`
`RFC 1692, Ulrich and Denzerfollow, followed by an analysis of the
`
`parties’ contentions regarding the challenged claims.
`
`1.
`
`Aldred
`
`Aldred,titled, “Collaborative Working in a Network,” published as
`
`an International Application on May 26, 1994 from an application filed on
`November 10, 1993. Ex. 1009, at [54], [43], [22]. Aldred relates to a
`“programmable workstation for collaborative working in a network,” which
`includes a “collaborative application support subsystem for interfacing with
`
`application programs,” wherein the subsystem “is responsive to
`predetermined application program calls to create a logical network model
`of a collaborative environment” that comprises a “sharing set of application
`programs, which share data and resources across nodesandlogical
`dedicated data channels connecting membersofthe sharingset.” Ex. 1009,
`at [57].
`Figures 3 and 4, reproduced below, show a logical network model
`that comprises sharing sets of application programs between various nodes.
`
`CALL MANAGER
`SUPPORT SYSTEM
`
`,
`
`8
`
`r
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`
`
`FIG, 4
`
`
`
`Figure 3 depicts aware applications sharing data and resources
`between nodes A, B, C, D, and E. Jd. at 5-6. Figure 4 depicts the two
`sharing sets resulting from the sharing of the aware applicationsin Figure 3.
`
`Id.
`
`An aware application initiates a share request, naming an application
`sharing set, a target application and a destination node. Jd. at 5. Support
`software passes the request to a call managerat the sending node, which
`then transfers it to the call managerat the destination node. /d. The sharing
`mechanism can be cascaded; for example, two sharing applications can
`initiate a share with a third application naming the same sharing set, with
`the result that all three applications then share with each other. Id.
`Applications in a sharing set establish data communicationlinks with
`each other known as channels. Jd. at 6. As shownin Figures 3 and 4,
`
`various channels link aware applications at nodes A,B, C, and E, and one
`channel links aware applications at nodes D and E. See Figure 3 and 4. In
`particular, various channels link aware application 1 at node A, aware
`application 2 at node B, aware applications 3 and 4 at node C, and aware
`application 8 at node E, whichall belong to the same sharingset. One
`
`20
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`channellinks aware application 7 at node D and aware application 9 at node
`
`E, which belong to the same sharing set. Jd.
`A serializing channel set feature combines data packets from
`different channels, and deliver serialized packets to each application such
`that each receiving port receives the same sequenceof data. Jd. at 7.°
`Throughthis synchronizing features, “data packets on separate channels are
`tied together in time (for example, voice with video), but delivered through
`the individual ports belonging to the channels.” Jd.
`Figure 6, reproduced below, provides an example of a shared
`drawing board usingserializing channel set 59 consisting of channels 57
`
`and 58:
`
` APPLICATION A ogst, 5
`
`Wit
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
