`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`––––––––––––––––––
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`––––––––––––––––––
`
`RIOT GAMES, INC.,
`Petitioner,
`
`v.
`
`PALTALK HOLDINGS, INC.,
`Patent Owner.
`
`––––––––––––––––––
`
`Case No. IPR2018-00132
`U.S. Patent No. 6,226,686
`Issued: May 1, 2001
`Filed: September 28, 1999
`
`Inventors: Jeffrey J. Rothschild, Daniel J. Samuel, and Marc P. Kwiatkowski
`
`Title: SERVER-GROUP MESSAGING SYSTEM FOR INTERACTIVE
`APPLICATIONS
`
`––––––––––––––––––
`
`PETITION FOR INTER PARTES REVIEW
`
`
`
`
`
`IPR2018-00132
`
`Petition for Inter Partes Review of U.S. Patent No. 6,226,686
`
`TABLE OF CONTENTS
`
`Exhibit List ................................................................................................................ iv
`
`I.
`
`II.
`
`Introduction ...................................................................................................... 1
`
`Compliance with Inter Partes Review Requirements ..................................... 1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Real Party In Interest (§ 42.8(b)(1)) ...................................................... 1
`
`Related Proceedings (§ 42.8(b)(2)) ....................................................... 1
`
`Lead and Backup Counsel (§ 42.8(b)(3)) .............................................. 2
`
`Service Information (§ 42.8(b)(4)) ........................................................ 2
`
`Certification ........................................................................................... 2
`
`Fees ........................................................................................................ 3
`
`Proof of Service ..................................................................................... 3
`
`III.
`
`Identification of Claims Being Challenged (§ 42.104(B)) .............................. 3
`
`IV. The 686 Patent ................................................................................................. 4
`
`
`
`
`
`
`
`
`
`Effective Filing Date ............................................................................. 4
`
`Person of Ordinary Skill in the Art ....................................................... 4
`
`Overview of the 686 Patent ................................................................... 4
`
`Claim Construction ............................................................................... 5
`
`V.
`
`The Prior Art .................................................................................................... 9
`
` Aldred (Ex. 1009) .................................................................................. 9
`
`i.
`
`ii.
`
`Collaborative Working Environment .......................................... 9
`
`Sharing Sets ............................................................................... 11
`
`i
`
`
`
`IPR2018-00132
`
`Petition for Inter Partes Review of U.S. Patent No. 6,226,686
`
`iii. Central Serialisation Point (“CSP”) .......................................... 13
`
`
`
`
`
`RFC 1692 (Ex. 1010) .......................................................................... 15
`
`i.
`
`ii.
`
`Prior Art Status of RFC 1692 .................................................... 15
`
`Transport Multiplexing Protocol............................................... 16
`
`Ulrich (Ex. 1012) ................................................................................. 17
`
` Denzer (Ex. 1014) ............................................................................... 20
`
`VI. Precise Reasons for the Relief Requested ..................................................... 21
`
` Aldred in view of RFC 1692 and the Knowledge of an Ordinary
`Artisan Render Obvious Claims 1, 3, 7, 12, 18, 26, 27, 45, 46, 62, and
`63 ......................................................................................................... 21
`
`i.
`
`Claims 1, 3, 7, and 18 ............................................................... 21
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Preambles (All) ............................................................... 21
`
`Creating a Message Group (Claims 1 and 3) ................. 26
`
`Receiving Join Messages (Claims 1 and 3) .................... 27
`
`Receiving Host Messages (All) ...................................... 28
`
`Payload Portion and Portion for Identifying (All) .......... 29
`
`Aggregating (All)............................................................ 33
`
`Forming (Claims 1 and 18) ............................................ 39
`
`Transmitting (All) ........................................................... 39
`
`Operating Consistently (All) .......................................... 40
`
`ii.
`
`Claim 12 .................................................................................... 41
`
`
`
`Preamble ......................................................................... 41
`
`ii
`
`
`
`IPR2018-00132
`
`Petition for Inter Partes Review of U.S. Patent No. 6,226,686
`
`
`
`
`
`Communicating ............................................................... 46
`
`Remaining Limitations ................................................... 49
`
`i.
`
`ii.
`
`Claims 26, 45, and 62 ............................................................... 50
`
`Claims 27, 46, and 63 ............................................................... 50
`
`Aldred and RFC 1692 in further view of Ulrich and the Knowledge of
`an Ordinary Artisan Renders Obvious Claims 22-27, 41-46, and 58-
`63 ......................................................................................................... 51
`
`i.
`
`ii.
`
`Claims 23, 42, and 59 ............................................................... 51
`
`Claim 22, 41, and 58 ................................................................. 61
`
`iii. Claim 24, 25, 43, 44, 60, and 61 ............................................... 64
`
`iv.
`
`v.
`
`Claims 26, 45, and 62 ............................................................... 65
`
`Claims 27, 46, and 63 ............................................................... 66
`
`Aldred in view of RFC 1692, Denzer, and the Knowledge of an
`Ordinary Artisan Render Obvious Claims 36 and 55 ......................... 66
`
`
`
`
`
`VII. Conclusion ..................................................................................................... 69
`
`Certificate Of Compliance ....................................................................................... 70
`
`Certificate Of Service............................................................................................... 71
`
`
`
`
`
`iii
`
`
`
`IPR2018-00132
`
`Petition for Inter Partes Review of US. Patent No. 6,226,686
`
`EXHIBIT LIST
`
`n Exhibit Description
`US. Patent No. 5,822,523
`
`1001
`
`1002
`
`1003
`
`1004
`
`1005
`
`1006
`
`US. Patent No. 6,226,686
`
`Prosecution File History (523 Patent)
`
`Prosecution File History (686 Patent)
`
`Reexamination File History (523 Patent)
`
`Reexamination File History (686 Patent)
`
`1007
`
`Declaration of Dr. Steve R. White
`
`1008
`
`Curriculum Vitae of Dr. Steve R. White
`
`1009
`
`1010
`
`1011
`
`1012
`
`1013
`
`1014
`
`1015
`
`1016
`
`1017
`
`1018
`
`1019
`
`1020
`
`International Publication No- W0 94/ 1 1814 (Aldred)
`
`Transport Multiplexing Protocol (TMux), RFC 1692 (Aug. 1994)
`
`Internet Protocol, RFC 791 (Sept. 1981)
`
`US. Patent No- 5,466,200 (Ulrich)
`
`US. Patent No- 5206,934 (Naef)
`
`US. Patent No. 5,307,413 (Denzer)
`
`IBM Dictionary of Computing (1994)
`
`Complaint, PaITaIk Holdings, Inc. v. Riot Games, Inc., CA. No. 1:16-
`cv-01240-SLR (Dec- 16, 2016)
`
`John D. Day et al., The 051 Reference Model, 71—12 Proceedings of the
`IEEE 1334 (1983)
`
`Protocol Standard for a NetBIOS Service on a TCP/UDP Transport:
`Concepts and Methods, RFC 1001 (Mar. 1987)
`
`Martin W. Sachs et al., LAN and [/0 Convergence: A Survey of the
`Issues, IEEE Computer (1994)
`
`Enrico Y. P. Hsu et al., Management Gaming on a Computer Mediated
`Conferencing System: A Case of Collaborative Learning through
`Computer Conference, IEEE (1991)
`
`1021
`
`The Internet Standards Process — Revision 2, RFC 1602 (Mar. 1994)
`
`iv
`
`
`
`
`
`
`
`IPR2018-00132
`
`Petition for Inter Partes Review of U.S. Patent No. 6,226,686
`
`Internet Official Protocol Standards, RFC 1720 (Nov. 1994)
`1022
`1023 U.S. Patent No. 5,502,726 (Fischer)
`1024 U.S. Patent No. 5,566,337 (Szymanski)
`1025
`Internet Relay Chat Protocol, RFC 1459 (May 1993)
`1026 Declaration of Dave Crocker
`1027 CV of Dave Crocker
`1028 The Internet Standards Process, RFC 1310 (Mar. 1992)
`1029 The Internet Standards Process – Revision 3, RFC 2026 (Oct. 1996)
`1030 U.S. Patent No. 5,558,339 (Perlman)
`1031 U.S. Patent No. 5,041,963 (Ebersole)
`1032 PR 4-3 Joint Claim Construction Statement, PalTalk Holdings, Inc., v.
`Sony Comp. Entertainment Am. Inc., Case No. 2:09-cv-274-DF, Dkt. No.
`209 (E.D. Tex. Oct. 25, 2010)
`1033 Claim Construction Order, PalTalk Holdings, Inc., v. Microsoft Corp.,
`Case No. 2:06-cv-367-DF (E.D. Tex.)
`1034 Song et al., A Distributed Simulation System for Team Decisionmaking,
`IEEE (1994)
`1035 Weaver et al., Networked Simulations: New Paradigms for Team
`Performance Research, 27(1), BEHAV. RES. METHODS, INSTRUMENTS, &
`COMPUTERS, 12-24 (1995)
`
`
`
`v
`
`
`
`IPR2018-00132
`
`Petition for Inter Partes Review of U.S. Patent No. 6,226,686
`
`I.
`
`Introduction
`
`Petitioner Riot Games, Inc. respectfully requests institution of inter partes
`
`review of claims 1, 3, 7, 12, 18, 22-27, 36, 41-46, 55, and 58-63 of U.S. Patent No.
`
`6,226,686 (“the 686 Patent”) (Ex. 1002).
`
`II. Compliance with Inter Partes Review Requirements
`
` Real Party In Interest (§ 42.8(b)(1))
`
`The real party in interest of this petition pursuant to 37 CFR § 42.8(b)(1) is
`
`Riot Games, Inc.
`
` Related Proceedings (§ 42.8(b)(2))
`
`The 686 Patent is related to the following U.S. Patents: 5,822,523 (“523
`
`Patent”) and 6,018,766. The 523 Patent was involved in ex partes reexamination
`
`No. 90/011,033 (Ex. 1005). The 686 Patent was involved in ex partes
`
`reexamination No. 90/011,036 (Ex. 1006).
`
`The 523 and 686 Patents are subject to the following requests for inter
`
`partes review: IPR2018-00129 (523 Patent), IPR2018-00130 (523 Patent),
`
`IPR2018-00131 (686 Patent), and IPR2018-00132 (686 Patent).
`
`The 523 and 686 Patents are or were involved in the following district court
`
`proceedings: PalTalk Holdings, Inc. v. Valve Corporation, Case No.16-cv-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
`
`1
`
`
`
`IPR2018-00132
`
`Petition for Inter Partes Review of U.S. Patent No. 6,226,686
`
`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).
`
` Lead and Backup Counsel (§ 42.8(b)(3))
`
`Lead Counsel is Joseph A. Micallef (Reg. No. 39,772), jmicallef
`
`@sidley.com, (202) 736-8492. Backup Lead Counsel is Scott M. Border (pro hac
`
`vice to be requested), sborder@sidley.com, (202) 736-8818, and Samuel A. Dillon
`
`(Reg. No. 65,197), samuel.dillon@sidley.com.
`
`
`
`Service Information (§ 42.8(b)(4))
`
`Petitioner consents to electronic service by email to Riot PalTalk
`
`@sidley.com. Mail or hand delivery service on Petitioner may be made to: Sidley
`
`Austin 1501 K Street, N.W., Washington, D.C. 20005. The fax number for lead
`
`and backup counsel is (202) 736-8711.
`
` Certification
`
`Petitioner certifies it is not barred or estopped from requesting review of the
`
`686 Patent, which has not been the subject of a prior IPR by Petitioner or its
`
`privies. This petition is filed within one year of the service date of a complaint
`
`alleging infringement. See Ex. 1016, 1. Neither Petitioner nor its privies have
`
`2
`
`
`
`IPR2018-00132
`
`Petition for Inter Partes Review of U.S. Patent No. 6,226,686
`
`filed a civil action challenging the validity of any 686 Patent claim. Petitioner
`
`therefore certifies this patent is available for review.
`
`
`
`Fees
`
`The director is authorized to charge fees to Deposit Account No. 50-1597.
`
`
`
`Proof of Service
`
`A Certificate of Service is included at the end of this petition.
`
`III.
`
`Identification of Claims Being Challenged (§ 42.104(B))
`
`Trial is requested on all grounds and arguments, which address Patent
`
`Owner’s possible counterarguments by proposing grounds that more closely satisfy
`
`certain limitations. These grounds are non-redundant, “rational, narrowly targeted,
`
`and not burdensome.” Great West Cas. Co. v. Transpacific IP I Ltd., IPR2015-
`
`01912, Paper 10 at 17-18 (P.T.A.B. Mar. 22, 2016). The challenged claims are
`
`obvious under 35 U.S.C. § 103 as follows.
`
`(1) Claims 1, 3, 7, 12, 18, 26, 27, 45, 46, 62, and 63 are
`obvious over Aldred (Ex. 1009) in view of RFC 1692 (Ex. 1010), and
`the Knowledge of an Ordinary Artisan;
`
`(2) Claims 22-27, 41-46, and 58-63 are obvious over Aldred
`in view of RFC 1692, Ulrich (Ex. 1012), and the Knowledge of an
`Ordinary Artisan; and
`
`(3) Claims 36 and 55 are obvious over Aldred in view of
`RFC 1692, Denzer (Ex. 1014), and the Knowledge of an Ordinary
`Artisan.
`
`3
`
`
`
`IPR2018-00132
`
`Petition for Inter Partes Review of U.S. Patent No. 6,226,686
`
`Due to the number of claims, the remaining dependent claims are challenged
`
`in IPR2018-00131.
`
`IV. The 686 Patent
`
` Effective Filing Date
`
`The 686 Patent was filed September 28, 1999, and claims priority to the 523
`
`Patent (Ex. 1001), filed on February 1, 1996, which Petitioner assumes to be the
`
`686 Patent’s effective filing date.
`
`
`
`Person of Ordinary Skill in the Art
`
`A person of ordinary skill in the art in the field of the 686 Patent in 1995
`
`(“Ordinary Artisan”) would have had either (1) at least a master’s degree (or
`
`equivalent course work) in computer science, computer engineering, or physics,
`
`and at least two years’ experience in networking interactive applications, or (2) at
`
`least a bachelor‘s degree in computer science, computer engineering, or physics,
`
`and approximately four years’ experience in networked interactive applications, or
`
`the equivalent, which would include experience in network programming. Decl. of
`
`Dr. Steve R. White (Ex. 1007), ¶¶42-43.
`
` Overview of the 686 Patent
`
`The 686 Patent describes networked collaborative (i.e., multi-person)
`
`computer applications. Ex. 1002, 1:19-27, 1:62-2:37; 2:51-3:26, 8:26-30, 10:6-23.
`
`It describes routing messages between host computers for shared, interactive
`
`4
`
`
`
`IPR2018-00132
`
`Petition for Inter Partes Review of U.S. Patent No. 6,226,686
`
`applications deployed over networks such as the Internet. Id., 12:38-42, 26:28-29.
`
`It purports to improve interactive network applications by introducing a “group
`
`messaging server.” Id., Abstract. Figure 5 shows group messaging server 62 and
`
`host computers 58-61 connected by routers and links. Id., 8:65-9:8.
`
`
`
`Id., Fig. 5. Instead of sending three separate updates to the other hosts, the 686
`
`Patent proposes that host 58 could send one message to the group messaging server
`
`62, which would aggregate that message with other host messages and forward the
`
`aggregated messages to each host. See, e.g., id., 10:24-26; Ex. 1007, ¶¶36-40.
`
` Claim Construction
`
`The 686 Patent has expired, so its claims should be interpreted based on a
`
`district court-type claim construction approach. 37 CFR § 42.100(b). In District
`
`5
`
`
`
`IPR2018-00132
`
`Petition for Inter Partes Review of US. Patent No. 6,226,686
`
`Court, Patent Owner has advanced several constructions for the claim elements
`
`identified below. Petitioner considers certain constructions in its analysis, but an
`
`Ordinary Artisan would find these elements satisfied by the prior art under any
`
`interpretation consistent with their plain and ordinary meaning in the context of the
`
`686 Patent. Because their precise scope is irrelevant to this proceeding, the Board
`
`need not expressly construe the terms. See Vivid Techs., Inc. v. Am. Sci. & Eng ’g,
`
`Inc., 200 F.3d 795, 803 (Fed. Cir. 1999).
`
`Claim Term
`
`Patent Owner’s Identified Construction
`
`“aggregating/aggregated”
`
`“To collect two or more data items together as
`
`(Claim 1, 3, 7, 12, 18)
`
`a unit, however, where each data item retains
`
`its identity and may be extracted from the
`
`unit.” Ex. 1016, 93.
`
`“shared, interactive
`
`“Software operating on multiple host
`
`application” (Claims 1, 3, 7,
`
`computers that provides for sufficient
`
`12, 18)
`
`interaction to allow users of the hosts to share
`
`an application or experience.”
`
`Id., 118.
`
`“group messaging server”
`
`“A server or computer system with a network
`
`(Claims 1, 3, 7, 12, 18)
`
`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
`
`6
`
`
`
`
`
`
`
`IPR2018-00132
`
`Petition for Inter Partes Review of US. Patent No. 6,226,686
`
`Claim Term
`
`Patent Owner’s Identified Construction
`
`
`
`“wherein/whereby said
`
`aggregated/server message
`
`keeps the shared interactive
`
`application operating
`
`consistently” (Claims 1, 3, 5,
`
`18)
`
`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. “ Id., 89.
`
`“Wherein the aggregated/server message
`
`maintains a consistent state for the
`
`shared, interactive application operating
`
`on multiple host computers-” Ex. 1033,
`
`38.
`
`
`
`
`
`Patent Owner made numerous arguments during reexamination relating to
`
`the scope of certain claim elements of the 686 Patent. E.g., Ex. 1006, 226, 231,
`
`244-245, 247, 255. These arguments are irrelevant to Petitioner’s patentability
`
`challenges because of the similarity of the cited prior art combinations below and
`
`Patent Owner’s description of the 686 Patent’s exemplary system. For example,
`
`after distinguishing the “centralized” architecture of the prior art at issue in the
`
`reexamination, (e.g., id., 217-220), Patent Owner depicted a model system of the
`
`686 Patent:
`
`
`
`IPR2018-00132
`
`Petition for Inter Partes Review of U.S. Patent No. 6,226,686
`
`
`
`Id., 223. This “model architecture”—allegedly embodying the 686 Patent—is the
`
`same architecture disclosed by the Central Serialisation Point embodiment of the
`
`Aldred reference, as described in detail below. Patent Owner’s arguments in
`
`reexamination are therefore irrelevant because they do not distinguish the prior art
`
`relied on here. See Vivid Techs., 200 F.3d at 803.
`
`8
`
`
`
`IPR2018-00132
`
`Petition for Inter Partes Review of U.S. Patent No. 6,226,686
`
`V. The Prior Art
` Aldred (Ex. 1009)
`
`International Publication No. WO 94/11814 to Aldred et al. (“Aldred”) (Ex.
`
`1009) was published on May 26, 1994, and is prior art under 35 U.S.C. § 102(b).
`
`Aldred was not cited during the prosecution or reexamination of the 686 Patent.
`
`i.
`Collaborative Working Environment
`Aldred discloses a collaborative working environment for a network of
`
`workstations that supports “broad spectrum of collaborative applications.” Ex.
`
`1009, 1-2. A support layer on each workstation allows applications to “create …
`
`sharing sets of application programs, which share data and resources within and
`
`across nodes.” Id., 2. Exemplary applications include mirroring application
`
`windows “as a snapshot or continuously,” a chalkboard with “a common drawing
`
`area … accessible to all users,” and a chat program where “each participant sees all
`
`the exchanged messages, and in the same sequence.” Id., 27-28. Aldred’s
`
`“interface is set at as high a level as possible” without “imposing any significant
`
`restraints on the range of application models that may be implemented. Id. This
`
`permits collaboration “between different computer platforms” “over varied
`
`communications networks” using “relevant communication and data standards.”
`
`Id., 30; Ex. 1007, ¶¶51-53.
`
`9
`
`
`
`IPR2018-00132
`
`Petition for Inter Partes Review of U.S. Patent No. 6,226,686
`
`Figure 1 illustrates workstations 10 and 12, or nodes, connected by a
`
`network, such as a Local Area Network (LAN) or Wide Area Network (WAN).
`
`Ex. 1009, 2; Ex. 1015, 392, 744; Ex. 1007, ¶¶54-56.
`
`Ex. 1009, Fig. 1; 20-21.
`
`
`
`Networked nodes can utilize different network topologies. Figure 3 depicts
`
`an example where Node A is connected to Node B, which is connected to Nodes C
`
`
`
`and E:
`
`10
`
`
`
`IPR2018-00132
`
`Petition for Inter Partes Review of U.S. Patent No. 6,226,686
`
`
`
`Id., Fig. 3. Applications on these nodes form a sharing set, as described below, and
`
`communicate using Aldred’s scheme. Id., 5-6; Ex. 1007, ¶57.
`
`ii.
`Sharing Sets
`Sharing Sets represent a collection of interactive applications that mutually
`
`share their data. Ex. 1009, 5. Applications create Sharing Sets by issuing sharing
`
`requests “naming an application sharing set, a target application and a destination
`
`node,” which is transferred “to the call manager at the destination node.” Id.
`
`Applications can dynamically join or merge existing Sharing Sets, and can “cease
`
`sharing at any time, withdrawing from a sharing set.” Id., 6. Numerous API
`
`commands and events are provided. Id., 31-39; Ex. 1007, ¶58.
`
`Applications communicate using communication links called “channels.”
`
`Ex. 1009, 6. Channels allow, e.g., Application A to send data to Application B:
`
`11
`
`
`
`IPR2018-00132
`
`Petition for Inter Partes Review of U.S. Patent No. 6,226,686
`
`
`
`Id., 6, Fig. 5. The ends of channels are known as ports. Id., 6. Aldred discloses
`
`four types of channels: standard, merged, synchronous, and serialised. Id., 7.
`
`“Standard channels are the default case; the other types are used in conjunction
`
`with collections of channels, known as channel sets.” Id. “The use of channels is
`
`restricted to applications within the same application sharing set.” Id., 16.
`
`One sharing set is illustrated in Figure 3, annotated below:
`
`
`
`12
`
`
`
`IPR2018-00132
`
`Petition for Inter Partes Review of U.S. Patent No. 6,226,686
`
`Id., Fig. 3; Ex. 1007, ¶¶59-60. The arrangement of Figure 3 results in two Sharing
`
`Sets, the first including applications 1A, 2B, 3C, 4C, and 8E, and the second
`
`including applications 7D and 9E. Ex. 1009, 6, Figs. 3-4.
`
`iii.
`Central Serialisation Point (“CSP”)
`One structure that Aldred’s applications can use to maintain consistency is a
`
`serialised channel set, where data packets are “combined from different channels,
`
`serialised, and delivered to each application such that each receiving port receives
`
`the same sequence of data.” Ex. 1009, 7. This involves collecting “all events in a
`
`central point, followed by the broadcast of each event to all the destinations for that
`
`event.” Id., 9. One example involves two users drawing on a common surface.
`
`Id., 7. Each application transmits drawing orders to common serialising channel
`
`set 59, and each receives the same sequence of drawing orders in response. Id., 2-
`
`6, 51, Figs. 1, 3; Ex. 1007, ¶61.
`
`Each Sharing Set’s serialised channel set is updated automatically as
`
`applications join and leave. Id., 8, 49-51. Applications wishing to join create a
`
`local channel set and join the sharing set, and “the additional channels required
`
`will be created automatically. Id., 8. Figure 19 illustrates one example—
`
`Application B sends a message (orange) to the serialised channel set, which is sent
`
`to every member of that serialised channel set, e.g., Applications A, B, and C
`
`(green):
`
`13
`
`
`
`IPR2018-00132
`
`Petition for Inter Partes Review of U.S. Patent No. 6,226,686
`
`
`
`Id., Fig. 19 (annotated); Ex. 1007, ¶¶62-64.
`
`“Serialisation can be implemented at a single central point with all data
`
`being sent there for serialisation and subsequent distribution ….” Ex. 1009, 9
`
`(emphasis added). In the context of Aldred (see id., 2-6, Figs. 1, 3), this Central
`
`Serialisation Point (“CSP”) is part of the support system of one of the participating
`
`nodes. Id., Figs. 2, 9; Ex. 1007, ¶¶65-66. The CSP would “maintain a serialising
`
`queue for the channel in which the data items to be serialised are loaded from the
`
`sending ports and held in the order in which it is desired to transmit them to all
`
`receiving ports.” Ex. 1009, 51. It is maintained and updated automatically: “New
`
`members may easily be added to the group with the necessary data channels being
`
`established and serialised automatically by the underlying system.” Id., 50, Fig.
`
`14
`
`
`
`IPR2018-00132
`
`Petition for Inter Partes Review of U.S. Patent No. 6,226,686
`
`22. Join requests and leave requests would modify this channel set in the same
`
`way as any other node in Aldred’s scheme. Id., 5, 31-39; Ex. 1007, ¶67.
`
` RFC 1692 (Ex. 1010)
`
`RFC 1692, titled “Transport Multiplexing Protocol (TMux),” was published
`
`in August, 1994, and is prior art under 35 U.S.C. §§ 102(a)-(b). Ex. 1010, 1. RFC
`
`1692 was cited during the 686 Patent’s reexamination, but was not at issue or
`
`otherwise discussed by Patent Owner or the Examiner.
`
`i.
`Prior Art Status of RFC 1692
`Request for Comments (RFCs) are well-known publications relating to the
`
`development of the Internet and Internet-related technologies. Decl. of David
`
`Crocker (Ex. 1026), ¶¶11-14. RFCs are developed through open processes and are
`
`“widely considered by the Internet technical community to be the official
`
`documents for the standards that govern the design, use, and management of core
`
`Internet services.” Id., ¶¶12, 15-18. Once published, RFCs are “widely distributed
`
`without any restrictions” through mailing lists, anonymous FTP, official
`
`summaries, and newsletters. Id., ¶¶19-24. The RFC Editor has maintained an
`
`official repository website since the early 1990s that was freely accessible with no
`
`login, password, or membership requirement. Id., ¶¶25-27. As Mr. Crocker
`
`explains, “[a]nyone working in … Internet or Internet-connected systems would
`
`have been aware of [RFCs], would have considered RFCs widely publicly
`
`15
`
`
`
`IPR2018-00132
`
`Petition for Inter Partes Review of U.S. Patent No. 6,226,686
`
`accessible, and would have known where and how to find copies of RFCs.” Id.,
`
`¶12; Ex. 1010, 1 (“Distribution … is unlimited.”); Ex. 1007, ¶69.
`
`RFCs include their publication date on their cover, generally in the top right
`
`corner. Ex. 1026, ¶20. In RFC 1692’s case, that date indicates RFC 1692 was
`
`published in August, 1994. This is corroborated by Mr. Crocker, one of RFC
`
`1692’s authors, who explains it was “released for public distribution on the
`
`Internet” in August, 1994 via “anonymous FTP and web access,” and “[a]nyone
`
`involved with the Internet technical community” in 1995 “would have known
`
`where and how to obtain a copy ….” Id., ¶¶28-31; Ex. 1022; Ex. 1007, ¶¶69-70.
`
`ii.
`Transport Multiplexing Protocol
`RFC 1692 discloses the “Transport Multiplexing Protocol (TMux),” an
`
`extension to the Internet Protocol. Ex. 1010, 1-2, 6, 10 (citing RFC 791, Ex.
`
`1011). TMux “allows multiple short transport segments, independent of
`
`application type, to be combined between a server and host pair.” Id., 1.
`
`“[N]etwork and host load could be greatly reduced if traffic from multiple users,
`
`destined for the same host, could be sent in the same packet.” Id., 2. “TMux is
`
`designed to improve network utilization and reduce the interrupt load on hosts
`
`which conduct multiple sessions involving many short packets … by multiplexing
`
`transport traffic onto a single IP datagram [2], thereby resulting in fewer, larger
`
`packets. Id. Multiplexed messages are constructed by combining packets payloads
`
`16
`
`
`
`IPR2018-00132
`
`Petition for Inter Partes Review of U.S. Patent No. 6,226,686
`
`until a timer expires. Id., 6. RFC 1692 focuses on the specific case of “a server
`
`and host pair,” id., 1, but states more generally that “network and host load could
`
`be greatly reduced if traffic from multiple users, destined for the same host, cold be
`
`sent in the same packet,” id., 2. This therefore contemplates multiplexing at
`
`intermediate points before transmission a common destination host. Ex. 1007,
`
`¶¶71-76.
`
` Ulrich (Ex. 1012)
`
`U.S. Patent No. 5,466,200 to Ulrich et al. (Ex. 1012) was filed February 1,
`
`1994, published November 14, 1995, and is a continuation-in-part of App. No.
`
`08/012,305, filed February 2, 1993. Ulrich is prior art to the 686 Patent under at
`
`least 35 U.S.C. § 102(a), (e). Ulrich was cited during the reexamination of the 686
`
`Patent, but was not at issue or otherwise discussed by Patent Owner or the
`
`Examiner.
`
`Ulrich discloses a networked interactive software system for playing games
`
`in a virtual world, Ex. 1012, 1:63-2:7, that supports “a variety of simulated
`
`environments,” and “may provide new worlds for the user to explore or even allow
`
`the user to travel across the solar system.” Id., 2:41-55. Ulrich’s preferred
`
`embodiment specifically adapts this game for use with multiple exercise machines,
`
`which can be interconnected “such that the users of the exercise machines can
`
`interact with each other as teammates or competitors in a variety of athletic events
`
`17
`
`
`
`IPR2018-00132
`
`Petition for Inter Partes Review of U.S. Patent No. 6,226,686
`
`including basketball games, baseball games, football games, bicycle races, and
`
`swimming races.” Id., 2:8-18. Ulrich’s exemplary exercise device is an exercise
`
`cycle, shown in Figures 1-6, but Ulrich explains that the exercise machine “can be
`
`any other type of exercise machine which: (i) allows a user to exercise some part of
`
`her (or his) body; (ii) allows a user to indicate a desired direction of motion (i.e.,
`
`steer); and (iii) includes a computer or processor to allow interconnection and
`
`communication with other such exercise machines.” Id., 7:48-55. The exercise
`
`apparatus is used as an input device for a local processer running and displaying an
`
`interactive simulated environment. Id., 2:19-40; Ex. 1007, ¶¶78-79.
`
`When two or more of Ulrich’s apparatuses are networked together, “the
`
`computers can communicate and share information and allow the users to navigate
`
`freely in the same simulated environment and to interact as teammates or
`
`competitors.” Ex. 1012, 7:35-42. Apparatuses can be connected via “any type of
`
`two-way transmission channel,” including an Ethernet network, id., 7:64-8:13, and
`
`more than two machines can be networked together, id., 7:45-48. Once connected,
`
`“the network connection allows the users to exercise in the same simulated
`
`environment.” Id., 8:14-17. Ulrich explains that each machine executes a local
`
`copy of the simulation and is responsible for providing updates to the other
`
`networked machines: “During the simulation, the same environment database is
`
`stored and executed on each machine. Each computer is responsible for updating
`
`18
`
`
`
`IPR2018-00132
`
`Petition for Inter Partes Review of U.S. Patent No. 6,226,686
`
`the environment so that its user sees herself (or himself) in relation to all other
`
`networked users. … each computer [] execute[s] the same environment ….” Id.,
`
`8:26-41; Ex. 1007, ¶80.
`
`Ulrich’s different networking topologies include an embodiment with a
`
`central hub that “controls communications between two or more exercise apparatus
`
`(‘nodes’) by receiving information from all nodes and directing information to all
`
`of, or to a subset of all of, the nodes.” Id., 3:45-49.
`
`
`
`Id., Fig 8; Ex. 1007, ¶81.
`
`Ulrich explains this central hub receives all location updates from the
`
`participating machines and transmits updates to apparatuses “in the same general
`
`area of the simulated environment.” Ex. 1012, 8:64-9:10. This process involves
`
`receiving an “update (e.g., of a particular networked user’s position, direction, etc.
`
`19
`
`
`
`IPR2018-00132
`
`Petition for Inter Partes Review of U.S. Patent No. 6,226,686
`
`in the simulated environment),” then “records the new state” in “database 172
`
`which contains the location, etc. data on all users in the environment.” Id., 11:31-
`
`49. “The new state information is then added … to the outgoing message queue”
`
`and the hub “determines which group of users should receive the message … by
`
`referencing the object database 172.” Id., 11:49-54. The hub then “addresses the
`
`outgoing message to the individual networked machines which need to receive the
`
`message ….” Id., 11:54-60. This