`Patent 6,226,686
`
`
`
`
`
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`_______________
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`_______________
`
`
`RIOT GAMES, INC.,
`Petitioner,
`
`v.
`
`PALTALK HOLDINGS, INC.,
`Patent Owner.
`
`_______________
`
`
`Case IPR2018-00132
`Patent 6,226,686
`_______________
`
`
`
`PATENT OWNER’S PRELIMINARY RESPONSE
`TO PETITION FOR INTER PARTES REVIEW
`OF U.S. PATENT NO. 6,226,686
`
`
`
`i
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`
`I.
`
`II.
`
`A.
`
`B.
`
`C.
`
`D.
`
`E.
`
`F.
`
`TABLE OF CONTENTS
`INTRODUCTION..........................................................................................................................1
`
`CLAIM CONSTRUCTION ..........................................................................................................2
`
`“GROUP MESSAGING SERVER” (CLAIM 12) ...................................................................................3
`
`“MESSAGE GROUP” (CLAIMS 1, 3, 7, 12, AND 18) ..........................................................................4
`
`“PORTION THAT IS USED TO IDENTIFY SAID MESSAGE GROUP” (CLAIMS 1, 3, 7 AND 18)
`AND “PORTION THAT IS USED TO IDENTIFY SAID FIRST MESSAGE GROUP” (CLAIM 12) ..............5
`
`“AGGREGATED MESSAGE” (CLAIMS 1, 3, 7, 12) AND “SERVER MESSAGE” (CLAIM 18) ...............5
`
`“PAYLOAD PORTION” (CLAIM 1, 3, 7, 12 AND 18) .........................................................................9
`
`“AGGREGATED PAYLOAD” (CLAIMS 1, 7, 12); “AGGREGATING SAID PAYLOAD
`PORTIONS” (CLAIM 3) AND “AGGREGATING SAID PAYLOAD PORTION WITH THE
`PAYLOAD PORTION OF A SECOND HOST MESSAGE” (CLAIM 18) .................................................11
`
`III. THE BOARD IS RESPECTFULLY URGED TO DENY INSTITUTION OF THE
`PETITION WITH RESPECT TO AT LEAST CLAIMS 3 AND 7 PURSUANT TO
`35 U.S.C. § 325(D) ........................................................................................................................13
`
`IV.
`
`PETITIONER HAS FAILED TO DEMONSTRATE A REASONABLE
`LIKELIHOOD OF PREVAILING WITH RESPECT TO ANY OF THE ‘686
`PATENT CLAIMS ......................................................................................................................14
`
`A. PETITIONER HAS NOT SUFFICIENTLY PROVEN THAT RFC 1692, RFC 1459, RFC 791,
`AND RFC 1001 ARE PRIOR PUBLICATIONS TO THE ‘686 PATENT ...............................................15
`
`B. GROUND 1: PETITIONER HAS FAILED TO DEMONSTRATE THAT ALDRED IN VIEW OF
`RFC 1692 RENDERS OBVIOUS CLAIMS 1, 3, 7, 12, 18, 26, 27, 45, 46, 62, AND 63 OF THE
`‘686 PATENT UNDER 35 U.S.C. § 103 ..........................................................................................21
`
`Petitioner has failed to demonstrate that Aldred in view of RFC 1692 renders
`1.
`obvious Claims 1, 3, 7, 12 and 18 ...................................................................................................21
`a. Petitioner has failed to demonstrate that Aldred discloses, either inherently or
`obviously, messages containing a portion for identifying a message group ...........................21
`
`ii
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`
`i. Petitioner has failed to show that Aldred discloses or suggests “messages
`contains . . . a portion that is used to identify said message group” (Claims 1, 3, 7
`and 18); and “messages contains . . . a portion that is used to identify said first
`message group” (Claim 12) ......................................................................................................22
`ii. Petitioner has failed to show that Aldred discloses or suggests “maintaining a
`list of message groups” .............................................................................................................27
`b. Petitioner has failed to demonstrate that RFC 1692 discloses or suggests
`“aggregating said payload portions of said host messages . . . to create an aggregated
`payload” (Claim 1 and 3); “aggregating said payload portions of said messages . . .
`to create an aggregated payload” (Claim 7 and 12); and “aggregating said payload
`portion with the payload portion of a second host message” (Claim 18) ................................29
`c. Petitioner has failed to demonstrate that RFC 1692 discloses or suggests
`“forming an aggregated message using said aggregated payload” (Claims 1, 12);
`“create an aggregated message” (Claim 3); “said aggregated message” (Claim 7);
`and “forming a server message . . .” (Claim 18) ........................................................................38
`i. Petitioner does not provide a sufficient motivation for combining Aldred and
`RFC 1692 ...................................................................................................................................38
`ii. The combination of Aldred and RFC 1692 does not disclose “forming an
`aggregated message using said aggregated payload” as recited in Claim 1, 12 and
`18 or creating and aggregated message as referenced in Claims 3 and 7 ............................41
`2. Aldred in view of RFC 1692 does not render obvious Claims 26, 27, 45, 46, 62
`and 63 ...............................................................................................................................................48
`C. GROUND 2: PETITIONER HAS NOT DEMONSTRATED THAT ALDRED IN VIEW OF RFC
`1692 AND ULRICH RENDERS OBVIOUS CLAIMS 22-27, 41-46, AND 58-63 OF THE ‘686
`PATENT UNDER 35 U.S.C. § 103 ..................................................................................................49
`
`D. GROUND 3: PETITIONER HAS NOT DEMONSTRATED THAT ALDRED IN VIEW OF RFC
`1692 AND DENZER RENDERS OBVIOUS CLAIMS 36 AND 55 OF THE ‘686 PATENT UNDER
`35 U.S.C. § 103 .............................................................................................................................49
`
`V.
`
`CONCLUSION ............................................................................................................................50
`
`
`
`iii
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`
`TABLE OF AUTHORITIES
`
`Cases
`Blue Coat Sys., Inc. v. Finjan, Inc., IPR2016-01444, Paper 9 (February 16, 2017) .... 16
`Conopco, Inc. v. The Proctor & Gamble Co., No. IPR2014-00506, Paper No. 17 ...... 14
`Ex parte Levy, 17 USPQ 2d 1461 (Bd. Pat. App. & Inter. 1990) ................................. 23
`Google Inc. v. Art+Com Innovationpool GMBH, IPR2015-00789, Paper 8 at p. 4
`(September 2, 2015) .................................................................................................. 15
`In re Rijckaert, 9 F.3d 1531 (Fed. Cir. 1993) ............................................................... 23
`Int’l Bus. Mach. Corp. v. EnvisionIt, LLC, IPR2017-01246, Paper 7 (October 16,
`2017) ................................................................................................................... 16, 17
`Los Angeles Cnty. Metro. Transp. Auth. v. Transp. Technologies, LLC, IPR2016-
`01633, Paper 22 (November 17, 2017) ..................................................................... 16
`Phillips v. AWH Corp., 415 F.3d 1303, 1314 (Fed. Cir. 2005) .................................. 2, 3
`Statutes
`35 U.S.C. § 312(a)(3) ...................................................................................................... 1
`35 U.S.C. § 313 ............................................................................................................... 1
`35 U.S.C. § 325(d) ......................................................................................................... 13
`Regulations
`37 C.F.R. § 42.104(b)(4) ................................................................................................. 1
`37 C.F.R. § 42.107 .......................................................................................................... 1
`Other Authorities
`MPEP 2112 ................................................................................................................... 23
`
`iv
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`
`Exhibit 2001:
`
`
`
`LIST OF EXHIBITS
`
`Declaration of Nancy Miracle
`
`
`
`v
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`I.
`
`INTRODUCTION
`
`Patent Owner PalTalk Holdings, Inc. (“PalTalk” or “Patent Owner”)
`
`respectfully submits this Preliminary Response in accordance with 35 U.S.C. § 313
`
`and 37 C.F.R. § 42.107, responding to the Petition for Inter Partes Review filed by
`
`Riot Games, Inc. (“Petitioner”) concerning U.S. Patent No. 6,226,686 (“the ‘686
`
`Patent”) and requests that the Board deny institution of this inter partes review
`
`proceeding because Petitioner has not demonstrated a reasonable likelihood of
`
`prevailing with respect to any of the claims of the ‘686 Patent.
`
`Petitioner uses several references
`
`in
`
`its alleged grounds, namely,
`
`International Publication No. WO 94/11814 to Aldred et. al. (“Aldred”) (Ex.
`
`1009), Request for Comments 1692 titled “Transport Multiplexing Protocol
`
`(TMux) (“RFC 1692”) (Ex. 1010), U.S. Patent No. 5,466,200 to Ulrich et al.
`
`(“Ulrich”) (Ex. 1012), and U.S. Patent No. 5,307,413 to Denzer (“Denzer”) (Ex.
`
`1014). However, the Petition fails to comply with several rules and regulations
`
`regarding the content of petitions. In certain circumstances, the Petition fails to
`
`provide support for key elements in a claim, violating the particularity
`
`requirements of 35 U.S.C. § 312(a)(3) and 37 C.F.R. § 42.104(b)(4). In particular:
`
`1)
`
`Petitioner has failed to demonstrate that RFC 1692 (Ex. 1010) and
`
`RFC 1459 (Ex. 1025) are prior publications to the ‘686 Patent;
`
`2)
`
`Petitioner has failed to demonstrate that the cited references disclose
`
`1
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`
`or suggest “receiving . . . messages . . . wherein each of said messages
`
`contain . . . a portion that is used to identify said message . . . group,” as
`
`required by Claims 1, 3, 7, 12 and 18 of the ‘686 Patent;
`
`3)
`
`Petitioner has failed to demonstrate that the cited references disclose
`
`or suggest “aggregating said payload portions of said messages” and “to
`
`create an aggregated message,” using the aggregated payload portions as
`
`required by Claim 1 of the ‘686 Patent, because the Petition ignores the two
`
`requirements of Claims 1, 3; the steps of “aggregating said payload portions
`
`of said messages” and “forming said aggregated message using said
`
`aggregated payload” of Claim 7 and 12 and the steps of “forming a server
`
`message . . .” and “aggregating said payload portion with the payload
`
`portion of a second host message” of Claim 18 to aggregate the payload
`
`portions of received messages to create an aggregated payload and THEN
`
`create an aggregated message using said aggregated payload.
`
`Therefore, Petitioner has not met their burden of demonstrating a reasonable
`
`likelihood of prevailing in proving unpatentability of any of the ‘686 Patent claims.
`
`II. CLAIM CONSTRUCTION
`
`The ‘686 Patent has expired. Therefore, the claims should be given their
`
`ordinary and accustomed meaning as understood by one of ordinary skill in the art
`
`consistent with the standard expressed in Phillips v. AWH Corp., 415 F.3d 1303,
`
`2
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`1312–13 (Fed. Cir. 2005) (en banc). The ordinary meaning of a term may be
`
`evidenced by a variety of sources, including “the words of the claims themselves,
`
`the remainder of the specification, the prosecution history, and extrinsic evidence
`
`concerning relevant scientific principles, the meaning of technical terms, and the
`
`state of the art.” Phillips v. AWH Corp., 415 F.3d 1303, 1314 (Fed. Cir. 2005) (en
`
`banc) (citation omitted).
`
`At this preliminary stage, Patent Owner does not concede that any claim
`
`construction proposed by Petitioner is correct in whole or in part. Nor are Patent
`
`Owner’s proposed constructions necessarily complete or exhaustive. Rather,
`
`Patent Owner’s proposed constructions and arguments herein with respect to claim
`
`construction are merely meant to highlight specific issues that may assist the Board
`
`in determining whether or not the Petition should be denied.
`
`A.
`
`“group messaging server” (Claim 12)
`
`Patent Owner’s Proposed Construction
`
`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
`
`3
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`can process messages with or without aggregated payloads, and can allow for
`
`group membership to change very rapidly.
`
`The above construction was agreed to between the parties in a previous
`
`district court case involving Patent Owner and Sony Computer Entertainment
`
`America, Inc., et al. Ex. 1032 at 1. This interpretation is consistent with the
`
`disclosure of the ‘686 Patent. Ex. 2001, ¶ 27. Therefore, Patent Owner proposes
`
`that the Board adopt this construction for “group messaging server,” especially
`
`since Petitioner relies on this construction in the Petition. Pet. at 6-7.
`
`B.
`
`“message group” (Claims 1, 3, 7, 12, and 18)
`
`Patent Owner’s Proposed Construction
`
`A collection of one or more host computers that (1) have joined a particular group
`
`and (2) receive group messages addressed to that particular group.
`
`
`The above construction was agreed to between the parties in a previous
`
`district court case involving Patent Owner and Sony Computer Entertainment
`
`America, Inc., et al. Ex. 1032 at 1-2. This interpretation is consistent with the
`
`disclosure of the ‘686 Patent. Ex. 2001, ¶ 28. Therefore, Patent Owner proposes
`
`that the Board adopt this construction for “message group.”
`
`
`
`
`
`4
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`
`C.
`
`“portion that is used to identify said message group” (Claims 1, 3,
`7 and 18) and “portion that is used to identify said first message
`group” (Claim 12)
`
`Patent Owner’s Proposed Construction
`
`Any part of a message, sent by a host computer to a group messaging server, that
`
`identifies the message group of a receiving host computer.
`
`
`The above construction was agreed to between the parties in a previous
`
`district court case involving Patent Owner and Sony Computer Entertainment
`
`America, Inc., et al. Ex. 1032 at 2. This interpretation is consistent with the
`
`disclosure of the ‘686 Patent. Ex. 2001, ¶ 29. Therefore, Patent Owner proposes
`
`that the Board adopt this construction for “portion for identifying said first
`
`message group.”
`
`D.
`
`“aggregated message” (Claims 1, 3, 7, 12) and “server message”
`(Claim 18)
`
`Patent Owner’s Proposed Construction
`
`One or more messages containing a single transport layer message header,
`
`destination data, and data items from an aggregated payload.
`
` A
`
` proper understanding of Claims 1, 3, 7, 12 and 18 of the ‘686 patent
`
`requires construction of the term “an aggregated message” and “a server message”
`
`from the steps of “forming an aggregated message using said aggregated payload”
`
`5
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`of Claims 1 and 12; “aggregating . . . to create an aggregated message” of Claim 3;
`
`“transmitting said aggregated message” of Claim 7 and “forming a server
`
`message” of Claim 18. Patent Owner submits that the aggregated message or
`
`server message of the claims include a message that includes a single message
`
`header and an aggregated payload that does not include additional headers. This
`
`interpretation is consistent with the disclosure of the ‘686 patent. Ex. 2001, ¶ 30.
`
`Figure 7, below, of the ‘686 Patent illustrates the messages transmitted by
`
`the Group Messaging Server.
`
`
`
`6
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`
`Each of the messages 100, 101, 102 and 103 received by a host from a server
`
`includes the aggregated payloads (Pn1, Pn2, Pn3) in each message and a header
`
`portion 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. Ex. 1002, col. 8, col. 9, col. 10, Fig 7. As can be seen from the
`
`disclosure of Fig. 7 and the associated discussion thereof, only a single message
`
`header consisting of the transport layer protocol source address, the transport layer
`
`protocol destination address and the ULP address is utilized. This single message
`
`header is then combined with the aggregated payload generated by the previous
`
`aggregating step.
`
`More detail of the datagram structure is provided with respect to Figure 9 of
`
`the ‘686 Patent, as shown in Patent Owner’s annotated Figure 9 below.
`
`7
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`
`
`
`As shown above, 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. Ex. 1002, col. 14:48-50. An upper
`
`layer protocol (ULP) message comprises the transport header 123, the ULP
`
`message type field 124, the destination ULP address 125, the address count field
`
`126, the auxiliary destination addresses 127, 128 and the payload 129. Id. at
`
`13:60-14:50, Fig. 9. The fields 123, 124, 125, 126, 127 and 128 constitute the
`
`message header. Ex. 2001, ¶ 35. The structure of the payload 129 is illustrated in
`
`8
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`the center portion of the figure. The “payload format . . . is defined by items 116,
`
`117, 118, 119, 120, 121, and 122.” Ex. 1002 at 14:37-40. The claims require, in a
`
`first and separate step, aggregating the payload portions to “create an aggregated
`
`payload,” which is shown by the payload portion 129, and items 116-122 of FIG.
`
`9. Ex. 2001, ¶ 35. Each of the payload elements include the source ULP address
`
`117 of the transmitted payload element, the data length 118 of the payload element
`
`and the actual data 119. Ex. 1002 at 14:37-50.
`
`The ‘686 Patent describes that “[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.” Id. at 24:23-28. Thus, the aggregated message as
`
`disclosed by the ‘686 Patent includes a single message header and an aggregated
`
`payload that does not include additional message headers. Ex. 2002, ¶ 36.
`
`Therefore, Patent Owner proposes adoption of this claim construction for
`
`“aggregated message.”
`
`E. “payload portion” (Claim 1, 3, 7, 12 and 18)
`
`Patent Owner’s Proposed Construction
`
`A portion of the original network message (that contains data item(s) conveying
`
`9
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`information) sent to the group messaging server remaining after the transport layer
`
`header is removed.
`
` A
`
` proper understanding of Claims 1, 3, 7, 12 and 18 of the ‘686 Patent
`
`requires construction of the term “payload portion.” Patent Owner submits that the
`
`payload portion of Claims 1, 3, 7, 12 and 18 is a portion of the original network
`
`message (that contains data item(s) conveying information)1 sent to the group
`
`messaging server remaining after the transport layer header is removed. This
`
`interpretation is consistent with the disclosure of the ‘686 Patent. Ex. 2001, ¶ 37.
`
`The above Section II.D regarding the Patent Owner’s construction for
`
`“aggregated message” describes that messages including a payload portion, such as
`
`messages 96, 97, 98, and 99 in FIG. 7, are received by the group messaging server.
`
`The ‘686 Patent further describes that the payload portions of these items are
`
`removed by the group messaging server. The ‘686 Patent states:
`
`The host sends the send message onto the network with TLP header
`addressing the data . . . The GMS receives the message and the GMS
`control function 136 determines that it is a send message datagram
`and looks up the implicit destination address in its implicit ULP
`
`
`1 An agreed construction in the Sony litigation for “payload portion” was “The part
`
`of a message that contains data item(s) conveying information.” Ex. 1032 at 2.
`
`10
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`
`address list 138 . . . If the address is valid, the GMS control function
`removes the TLP header from the datagram and sends the ULP
`portion to the ULP server process corresponding to the destination
`implicit ULP address . . . The ULP server process 140 will extract the
`single payload item from the message 117, 118, and 119 and place the
`payload item in each of the message queues 143.
`
`Ex. 1002 at 20:14-30 (emphasis added); Ex. 2001, ¶ 38. Therefore, Patent Owner
`
`proposes adoption of this claim construction for “payload portion.”
`
`F.
`
`“aggregated payload” (Claims 1, 7, 12); “aggregating said payload
`portions” (Claim 3) and “aggregating said payload portion with
`the payload portion of a second host message” (Claim 18)
`
`Patent Owner’s Proposed Construction
`
`A collection of two or more data items that does not include transport layer
`
`headers.
`
` A
`
` proper understanding of Claims 1, 3, 7, 12 and 18 of the ‘686 patent
`
`requires construction of the term “aggregated payload.” Patent Owner submits that
`
`the aggregated payload of Claims 1, 7 and 12 or the aggregated payload created by
`
`the aggregation steps of Claims 3 and 18 is a collection of two or more data items
`
`that does not include transport layer headers. This interpretation is consistent with
`
`the disclosure of the ‘686 Patent. Ex. 2001, ¶ 40.
`
`
`
`The above Sections II.D and II.E regarding the Patent Owner’s construction
`
`for “aggregated message” and “payload portion,” respectively, describe that
`
`11
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`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 to be included into a single message with a single message header to be
`
`sent to a host, where the message includes payload portions from the messages sent
`
`by the hosts. As explained above in Section II.D, the specification of the ‘686
`
`Patent describes that transport layer headers are removed from messages sent to the
`
`group messaging server. Ex. 1002 at 20:14-30; Ex. 2001, ¶¶ 38, 41.
`
`The process of creating the aggregated payload is further described by the
`
`‘686 Patent at 23:50-24:52. The ‘686 Patent states:
`
`[t]he ULP server process 140 removes payload items from a message
`queue 143 for a host and accumulates them in an aggregation buffer
`149 . . . At the end of the aggregation period, the each host
`aggregation buffer may hold multiple payload items. The host
`aggregation buffer will hold a message count of the payload items
`followed by the multiple payload items. The contents of a host
`aggregation buffer along with
`the ULP host address of
`the
`corresponding host are sent to the GMS control function 136 where it
`will be used to create a ULP receive message sent to the destination
`host . . . The payload in this case will have a message count 116 set by
`the message count value from the host aggregation buffer. The
`payload will contain all of the payload items from the host
`aggregation buffer.
`
`12
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`
`The effect of aggregation will be to greatly reduce the total message
`rate received by the hosts. A single message to a host will be able to
`carry multiple payload items received from the other hosts during the
`aggregation period.
`
`Ex. 1002 at 23:53-24:15 (emphasis added).
`
`
`
`Thus, an aggregated payload as described in the ‘686 Patent is collection of
`
`two or more data items that does not include transport layer headers. Ex. 2001, ¶¶
`
`41-43. Therefore, Patent Owner proposes adoption of this claim construction for
`
`“aggregated payload.”
`
`III. THE BOARD IS RESPECTFULLY URGED TO DENY INSTITUTION OF THE
`PETITION WITH RESPECT TO AT LEAST CLAIMS 3 AND 7 PURSUANT TO 35
`U.S.C. § 325(d)
`
`Petitioner filed another Petition for inter partes review of the ‘686 patent on
`
`November 2, 2017, which was designated as Petition No. IPR2018-00131. The
`
`instant Petition No. IPR2018-00132 was also filed on November 2, 2017.
`
`However, Patent Owner believes that certain arguments provided by Petitioner
`
`regarding particular claims discussed below are duplicitous and could have been
`
`argued in the Petition in IPR2018-00131, especially considering that Petitioner
`
`uses the same art for these claims.
`
`Under 35 U.S.C. § 325(d), the Board “has broad discretion to deny a petition
`
`that raises substantially the same prior art or arguments previously presented to the
`
`Office.” Conopco, Inc. v. The Proctor & Gamble Co., No. IPR2014-00506, Paper
`
`13
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`No. 17, at page 6. The Petition in IPR2018-00131 was filed with respect to Claims
`
`1-4, 7-21, 28-34, 35, 39, 40, 47-53, 54, 56, 57, and 64-70. IPR2018-00131, Paper
`
`1 at 3. The prior art presented in the IPR2018-00131 Petition included Aldred
`
`(International Publication No. W0 94/11814) (Ex. 1009), and RFC 1692 (Transport
`
`Multiplexing Protocol (TMux)) (Ex. 1010). See IPR2018-00131, Paper 1, at 3.
`
`Petitioner used Aldred and RFC 1692 as a 35 U.S.C. § 103 combination
`
`against most of the claims including independent Claims 1, 3, 7, 12, and 18. Id.
`
`Here, Petitioner again uses these references, and provides substantially similar
`
`arguments as in the IPR2018-00131 Petition with respect to independent Claims 1,
`
`3, 7, 12, and 18. Pet. at 3.
`
`With respect to Claims 3 and 7 Petitioner in the IPR2018-00131 Petition
`
`alleges that the combination of Aldred and RFC 1692 renders Claim 1 obvious for
`
`reasons identical to those in the Petition in this proceeding. Pet. at 21-41;
`
`IPR2018-00131, Paper 1, at 18-38. Additionally, while the dependent claims of
`
`Claims 3 and 7 are challenged in IPR2018-00131, here, Claims 3 and 7 are
`
`challenged alone without challenging their dependent claims. Therefore, Patent
`
`Owner urges the Board to deny institution of at least Claims3 and 7 in this
`
`proceeding so that the parties and the Board are not burdened with considering
`
`Claims 3 and 7 in both inter partes review proceedings.
`
`IV. PETITIONER HAS FAILED TO DEMONSTRATE A REASONABLE LIKELIHOOD
`
`14
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`
`OF PREVAILING WITH RESPECT TO ANY OF THE ‘686 PATENT CLAIMS
`
`A.
`
`Petitioner has not sufficiently proven that RFC 1692, RFC 1459,
`RFC 791, and RFC 1001 are prior publications to the ‘686 Patent
`
`Petitioner does not provide sufficient evidence that, on or before the
`
`critical date, RFC 791, RFC 1001, RFC 1459, and/or RFC 1692 were actually
`
`available online, that these RFCs were actually accessed or downloaded, or
`
`whether and how any alleged retrieval source was indexed or cataloged.
`
`Petitioner relies on the Declaration of David H. Crocker (Ex. 1026) (“the
`
`Crocker Declaration”) as evidence that RFC 791, RFC 1001, RFC 1459, and RFC
`
`1692 are prior publications under 35 U.S.C. §§ 102(a)-(b). Pet. at 15-17. The
`
`Crocker Declaration explains Mr. Crocker’s role with the Internet Engineering
`
`Task Force, his status as an author of RFC 1692, and the general standard practices
`
`for RFC submissions and publications. See Ex. 1026.
`
`However, the burden is on Petitioner to sufficiently establish that a reference
`
`is a prior art publication. Google Inc. v. Art+Com Innovationpool GMBH,
`
`IPR2015-00789, Paper 8 at p. 4 (September 2, 2015) (quoting In re Wyer, 655 F.2d
`
`221, 227 (CCPA 1981) (“[t]he party seeking to introduce the reference ‘should
`
`produce sufficient proof of its dissemination or that it has otherwise been available
`
`and accessible to persons concerned with the art to which the document relates and
`
`thus most likely to avail themselves of its contents’”)).
`
`15
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`
`The PTAB has previously noted
`
`the
`
`importance of sufficiently
`
`demonstrating that a reference relied upon is a prior art reference. See Int’l Bus.
`
`Mach. Corp. v. EnvisionIt, LLC, IPR2017-01246, Paper 7 (October 16, 2017); Los
`
`Angeles Cnty. Metro. Transp. Auth. v. Transp. Technologies, LLC, IPR2016-
`
`01633, Paper 22 (November 17, 2017); Blue Coat Sys., Inc. v. Finjan, Inc.,
`
`IPR2016-01444, Paper 9 (February 16, 2017).
`
`In particular, “public accessibility” has been called the touchstone in
`
`determining whether a reference constitutes a “printed publication.” EnvisionIt,
`
`IPR2017-01246, Paper 7, at 14 (citing Kyocera Wireless Corp. v. Int’l Trade
`
`Comm’n, 545 F.3d 1340, 1350 (Fed. Cir. 2008) (quoting In Re Hall, 781 F.2d 897,
`
`899 (Fed. Cir. 1986)). In EnvisionIt, the Board notes that evidentiary matters
`
`concerning Internet publications used as references are similar in nature to that of
`
`references stored in libraries, where “competent evidence of the general library
`
`practice” coupled with evidence that the reference “was sufficiently indexed or
`
`cataloged” is generally sought. IPR 2017-01246, Paper 7, at 14 (citing In Re Hall,
`
`781 F.2d at 899); (also citing Blue Calypso, LLC v. Groupon, Inc., 815 F.3d 1331,
`
`1348 (Fed. Cir. 2016)). The Board in EnvisionIt, indicates that, “just as indexing
`
`plays a significant role in evaluating whether a reference in a library is publicly
`
`accessible,” indexing, such as via search engines, is an important consideration
`
`when determining whether a reference on a given webpage is “publicly
`
`16
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`accessible.” IPR2017-01246, Paper 7, at 14-15 (quoting Blue Calypso, 815 F.3d at
`
`1349).
`
`In EnvisionIt, the Board determined that a reference alleged as being
`
`published on a website prior to the critical date was not a prior publication where,
`
`in part, there was no evidence that anyone actually accessed or downloaded the
`
`document, despite evidence that there were 750 comments posted on the page
`
`where the alleged reference was posted. IPR2017-01246, Paper 7, at 15. The
`
`Board based its decision on that there was no evidence of whether and how the
`
`website was indexed or cataloged. Id. at 16.
`
`Here, Petitioner has not sufficiently shown that RFC 791, RFC 1001, RFC
`
`1459, and RFC 1692 were “publicly accessible” before the critical date. The
`
`Crocker Declaration explains that the Internet Standards Process, detailing the
`
`standards for the RFC submission and the publication process, was formally
`
`documented in March of 1992. Ex. 1026 at ¶ 16. The Crocker Declaration states
`
`that the process was revised in March of 1994 as RFC 1602 and again in October
`
`1996 as RFC 2026. Id. at ¶ 16. With respect to RFC 1692 specifically, since the
`
`alleged publication date of RFC 1692 is August 1994, the standards used at that
`
`time according to the Crocker Declaration would be contained in RFC 1602 (Ex.
`
`1021).
`
`RFC 1602 mentions that “RFCs are available for anonymous FTP from a
`
`17
`
`
`
`IPR2018-00132
`Patent 6,226,686
`
`number of Internet hosts,” but RFC 1602 does not list these hosts. Ex. 1021 at 8.
`
`While the Crocker Declaration states that those involved with the Internet technical
`
`community would have known where and how to obtain a copy of RFC 1692 via
`
`anonymous FTP hosts, the Crocker Declaration does not provide any evidence as
`
`to what these hosts were or where they could be found in 1994. Ex. 1026 at ¶ 30.
`
`File Transfer Protocol (FTP) is a network protocol used in the transfer of
`
`digital files between a client and a server. An FTP host on the Internet in 1994-
`
`1996 would have required 1) a specific URL and filename in order to locate a
`
`specific place on the web and, without the specific URL and filename, it would
`
`have been difficult to locate the FTP host or information stored thereon, and 2) the
`
`information had to be actually stored at that location for retrieval. At the time of
`
`application – the critical date, current browser technology and search engines were
`
`not available and a POSITA could not just enter an RFC number into a search
`
`engine to find the RFC. Even if there were a URL and the name of the file that
`
`could be located, it is still necessary to have the desired information stored at that
`
`location, as a location defined by an FTP site does not guarantee that “any” data or
`
`information is stored there. Ex. 2001, ¶¶ 47-4