IPR2018-00131
`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-00131
`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-00131
`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.
`
`PETITIONER HAS FAILED TO DEMONSTRATE A REASONABLE
`LIKELIHOOD OF PREVAILING WITH RESPECT TO ANY OF THE ‘686
`PATENT CLAIMS ......................................................................................................................13
`
`A. PETITIONER HAS NOT SUFFICIENTLY PROVEN THAT RFC 1692, RFC 1459, RFC 791,
`AND RFC 1001 ARE PRIOR PUBLICATIONS TO THE ‘686 PATENT ...............................................13
`
`B. GROUND 1: PETITIONER HAS FAILED TO DEMONSTRATE THAT ALDRED IN VIEW OF
`RFC 1692 RENDERS OBVIOUS CLAIMS 1-4, 7-21, 28-30, 34, 35, 39, 40, 47-49, 53, 54,
`56, 57, 64-66 AND 70 OF THE ‘686 PATENT UNDER 35 U.S.C. § 103 ...........................................20
`
`Petitioner has failed to demonstrate that Aldred in view of RFC 1692 renders
`1.
`obvious Claims 1, 3, 7, 12 and 18 ...................................................................................................20
`a. Petitioner has failed to demonstrate that Aldred discloses, either inherently or
`obviously, messages containing a portion for identifying a message group ...........................20
`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) ......................................................................................................21
`
`ii
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`
`ii. Petitioner has failed to show that Aldred discloses or suggests “maintaining a
`list of message groups” .............................................................................................................26
`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) ................................28
`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) ........................................................................37
`i. Petitioner does not provide a sufficient motivation for combining Aldred and
`RFC 1692 ...................................................................................................................................37
`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 ............................40
`2. Aldred in view of RFC 1692 does not render obvious Claims 29, 48, and 65 ..................47
`3. Aldred in view of RFC 1692 does not render obvious Claims 2, 4, 8-11, 13-17,
`19-21, 28-30, 34, 35, 39, 40, 47-49, 53, 54, 56, 57, 64-66 and 70 ..................................................52
`C. GROUND 2: PETITIONER HAS NOT DEMONSTRATED THAT ALDRED IN VIEW OF RFC
`1692 AND RFC 1459 RENDERS OBVIOUS CLAIMS 31-33, 50-52, AND 67-69 OF THE ‘686
`PATENT UNDER 35 U.S.C. § 103 ..................................................................................................52
`
`IV. CONCLUSION ............................................................................................................................53 
`
`
`
`iii
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`
`TABLE OF AUTHORITIES
`
`Cases
`Blue Coat Sys., Inc. v. Finjan, Inc., IPR2016-01444, Paper 9 (February 16, 2017) .... 14
`Ex parte Levy, 17 USPQ 2d 1461 (Bd. Pat. App. & Inter. 1990) ................................. 22
`Google Inc. v. Art+Com Innovationpool GMBH, IPR2015-00789, Paper 8 at p. 4
`(September 2, 2015) .................................................................................................. 14
`In re Rijckaert, 9 F.3d 1531 (Fed. Cir. 1993) ............................................................... 22
`Int’l Bus. Mach. Corp. v. EnvisionIt, LLC, IPR2017-01246, Paper 7 (October 16,
`2017) ................................................................................................................... 14, 15
`Los Angeles Cnty. Metro. Transp. Auth. v. Transp. Technologies, LLC, IPR2016-
`01633, Paper 22 (November 17, 2017) ..................................................................... 14
`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
`Regulations
`37 C.F.R. § 42.104(b)(4) ................................................................................................. 1
`37 C.F.R. § 42.107 .......................................................................................................... 1
`Other Authorities
`MPEP 2112 ................................................................................................................... 22
`
`iv
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`
`Exhibit 2001:
`
`
`
`LIST OF EXHIBITS
`
`Declaration of Nancy Miracle
`
`
`
`v
`
`

`

`IPR2018-00131
`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), and Request for Comments 1459 titled “Internet
`
`Relay Chat Protocol” (“RFC 1459”) (Ex. 1025). 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-00131
`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 Claims 1 and 3 of the ‘686 Patent; 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, because the Petition
`
`ignores the two requirements of the claims 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-00131
`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-00131
`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-00131
`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-00131
`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-00131
`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-00131
`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-00131
`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-00131
`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-00131
`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-00131
`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-00131
`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. PETITIONER HAS FAILED TO DEMONSTRATE A REASONABLE LIKELIHOOD
`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-18. 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
`
`13
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`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’”)).
`
`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
`
`14
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`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
`
`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
`
`15
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`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
`
`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
`
`16
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`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-48.
`
`The Crocker Declaration and the cited exhibits also do not provide any
`
`indication that RFC 1692, specifically, was made available on these hosts. Further
`
`the Crocker Declaration does not provide any evidence that anyone actually
`
`accessed or downloaded RFC 1692. Ex. 1026, ¶ 30. Similar problems are present
`
`in the Crocker Declaration and the relied upon exhibits with respect to RFC 791,
`
`RFC 1001, and RFC 1459. The Crocker Declaration also states that a summary of
`
`RFCs appeared in each issue of the Internet Society’s newsletter, but does not
`
`evidence this statement, such as by providing a copy of such a newsletter. Id. at ¶
`
`24.
`
`Additionally, the Crocker Declaration states that RFC 791, RFC 1001, RFC
`
`1459, and RFC 1692 are currently available at www.rfc-editor.org (“the RFC
`
`Editor’s Website”), and states that Mr. Crocker recently downloaded these RFCs
`
`from the RFC Editor’s Website. Id. at ¶¶ 32, 36, 41, 45. However, the publication
`
`standards provided in the Crocker Declaration, such as RFC 1602, do not mention
`
`the RFC Editor’s Website as a source for retrieving RFCs on or before the critical
`
`17
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`date. Id. at ¶ 32. The Crocker Declaration only states that the “RFC Editor’s
`
`website today is the authoritative source page for RFCs on the Internet.” Id. at ¶
`
`26 (emphasis added). Crocker’s testimony that RFCs are currently available on the
`
`RFC Editor’s Website is not sufficient for Petitioner to establish that RFC 1692, or
`
`RFC 791, RFC 1001, and RFC 1459, were available on the RFC Editor’s Website
`
`on or before the critical date. Id. at 32. The Crocker Declaration also states that
`
`the current RFC Editor’s Website has a search function, but provides no evidence
`
`that the RFC Editor’s Website included a search function on or before the critical
`
`date. Id. at ¶¶ 26-27.
`
`While Mr. Crocker may have been involved with creating RFC 1692 and is
`
`familiar with the RFC writing and submission process as evidenced by the Crocker
`
`Declaration (see Ex. 1026, ¶¶ 16-20, 28-29), the Crocker Declaration provides no
`
`evidence that Mr. Crocker was personally responsible for publishing or otherwise
`
`making available on the Internet RFC 1692, or RFC 791, RFC 1001, and RFC
`
`1459. This task was apparently assigned to someone other than Mr. Crocker and
`
`thus Mr. Crocker’s testimony does not prove that these RFCs were published
`
`according to RFC standards, nor is there any evidence that Mr. Crocker is in a
`
`position to have actual knowledge that, on or before the critical date, the
`
`publication was 1) actually stored on any publically available FTP site, 2) that the
`
`FTP web site was active, 3) that anyone was notified of any FTP link or 4) that
`
`18
`
`

`

`IPR2018-00131
`Patent 6,226,686
`
`anyone actually downloaded the publication. Further, Petitioner has provided no
`
`evidentiary proof of the above or any Declaration from any individual who has
`
`actual knowledge of the above and was in a position of keeper of the records on or
`
`before the critical cate. See Ex. 1026, ¶ 28.
`
`Thus, since the Crocker Declaration does not provide suff