`
`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-00131
`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-00131
`
`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-00131
`
`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
`
`RFC 1459 (Ex. 1025) .......................................................................... 17
`
`VI. Precise Reasons for the Relief Requested ..................................................... 18
`
` Aldred in view of RFC 1692 and the Knowledge of an Ordinary
`Artisan Render Obvious Claims 1-4, 7-21, 28-30, 34, 35, 39, 40, 47-
`49, 53, 54, 56, 57, 64-66, and 70 ......................................................... 18
`
`i.
`
`Claims 1, 3, 7, and 18 ............................................................... 18
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Preambles (All) ............................................................... 18
`
`Creating a Message Group (Claims 1 and 3) ................. 23
`
`Receiving Join Messages (Claims 1 and 3) .................... 24
`
`Receiving Host Messages (All) ...................................... 25
`
`Payload Portion and Portion for Identifying (All) .......... 26
`
`Aggregating (All)............................................................ 30
`
`Forming (Claims 1 and 18) ............................................ 36
`
`Transmitting (All) ........................................................... 36
`
`Operating Consistently (All) .......................................... 37
`
`ii.
`
`Claim 12 .................................................................................... 38
`
`
`
`
`
`Preamble ......................................................................... 38
`
`Communicating ............................................................... 43
`ii
`
`
`
`IPR2018-00131
`
`Petition for Inter Partes Review of U.S. Patent No. 6,226,686
`
`
`
`Remaining Limitations ................................................... 46
`
`iii. Claims 2, 4, 8, 13, and 19 ......................................................... 47
`
`iv.
`
`v.
`
`vi.
`
`Claims 9 and 15 ......................................................................... 48
`
`Claims 10 and 16....................................................................... 49
`
`Claims 11 and 17....................................................................... 50
`
`vii. Claim 14 .................................................................................... 52
`
`viii. Claims 20, 21, 39, 40, 56, and 57 ............................................. 54
`
`ix.
`
`x.
`
`xi.
`
`Claims 28, 47, and 64 ............................................................... 55
`
`Claims 29, 48, and 65 ............................................................... 55
`
`Claims 30, 49, and 66 ............................................................... 58
`
`xii. Claims 34, 53, and 70 ............................................................... 59
`
`xiii. Claims 35 and 54....................................................................... 61
`
`
`
`Aldred in view of RFC 1692 and RFC 1459 and the Knowledge of
`One of Ordinary Skill in the Art Renders Obvious Claims 31-33, 50-
`52, and 67-69 ....................................................................................... 61
`
`i.
`
`ii.
`
`Claims 31, 50, and 67 ............................................................... 61
`
`Claims 32, 51, and 68 ............................................................... 67
`
`iii. Claims 33, 52, and 69 ............................................................... 68
`
`VII. Conclusion ..................................................................................................... 69
`
`Certificate Of Compliance ....................................................................................... 70
`
`Certificate Of Service............................................................................................... 71
`
`
`
`
`
`iii
`
`
`
`IPR2018-00131
`
`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-00131
`
`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-00131
`
`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-4, 7-21, 28-35, 39, 40, 47-54, 56, 57, and 64-70 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-00131
`
`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-00131
`
`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-4, 7-21, 28-30, 34, 35, 39, 40, 47-49, 53, 54,
`56, 57, 64-66, and 70 are obvious over Aldred (Ex. 1009) in view of
`RFC 1692 (Ex. 1010), and the Knowledge of an Ordinary Artisan; and
`
`(2) Claims 31-33, 50-52, and 67-69 are obvious over Aldred
`in view of RFC 1692, RFC 1459 (Ex. 1025), and the Knowledge of an
`Ordinary Artisan.
`
`Due to the number of claims, the remaining dependent claims are challenged
`
`in IPR2018-00132.
`
`3
`
`
`
`IPR2018-00131
`
`Petition for Inter Partes Review of U.S. Patent No. 6,226,686
`
`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
`
`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
`
`4
`
`
`
`IPR2018-00131
`
`Petition for Inter Partes Review of U.S. Patent No. 6,226,686
`
`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
`
`Court, Patent Owner has advanced several constructions for the claim elements
`
`identified below. Petitioner considers certain constructions in its analysis, but an
`
`5
`
`
`
`IPR2018-00131
`
`Petition for Inter Partes Review of US. Patent No. 6,226,686
`
`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
`
`addressed to a message group and sending
`
`messages to the host computers that have
`
`
`
`
`
`
`
`IPR2018-00131
`
`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)
`
`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-00131
`
`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-00131
`
`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-00131
`
`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-00131
`
`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-00131
`
`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-00131
`
`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-00131
`
`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-00131
`
`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-00131
`
`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-00131
`
`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.
`
` RFC 1459 (Ex. 1025)
`
`Request for Comments 1459 (“RFC 1459”) is titled “Internet Relay Chat
`
`Protocol,” and was published in May of 1993, and therefore prior art under 35
`
`U.S.C. §§ 102(a)-(b). Ex. 1025, 1. As explained above, RFC publications were
`
`widely distributed and made available to the interested public as of the date on
`
`their face. Ex. 1026, ¶¶19-24; Ex. 1007, ¶69. Mr. Crocker explains he was
`
`personally familiar with RFC 1459 and can “confirm that it was widely publicly
`
`available during [] 1993-1995,” such as through anonymous FTP, and would have
`
`been accessible to “[a]nyone involved with the Internet technical community
`
`during the 1993-1995 time period.” Ex. 1026, ¶¶42-45.
`
`RFC 1459 discloses IRC, a teleconferencing system “well-suited to running
`
`on many machines in a distributed fashion.” Ex. 1025, 4; Ex. 1007, ¶87. “A
`
`typical setup involves a single process (the server) forming a central point for
`
`clients (or other servers) to connect to, performing the required message
`
`17
`
`
`
`IPR2018-00131
`
`Petition for Inter Partes Review of U.S. Patent No. 6,226,686
`
`delivery/multiplexing and other functions.” Ex. 1025, 4. IRC revolves around a
`
`“channel,” which is a “named group of one or more clients which will all receive
`
`messages addressed to that channel.” Id., 5-6. IRC supports numerous client
`
`commands to query a server for information about the server or the channels it
`
`maintains. Id., 19-31.
`
`VI. Precise Reasons for the Relief Requested
` Aldred in view of RFC 1692 and the Knowledge of an Ordinary
`Artisan Render Obvious Claims 1-4, 7-21, 28-30, 34, 35, 39, 40, 47-
`49, 53, 54, 56, 57, 64-66, and 70
`
`i.
`
`Claims 1, 3, 7, and 18
` Preambles (All)
`
`Claims 1, 3, 7, and 18 recite “A method for facilitating communications
`
`among a plurality of host computers over a network to implement a shared,
`
`interactive application.”
`
`Aldred discloses a “plurality of host computers” in the form of a network of
`
`workstations, or nodes, operating in a collaborative work environment. Ex. 1009,
`
`1-2. This collaborative architecture is capable of supporting a “broad range of
`
`collaborative applications,” and “[t]he interface is set at as high a level as possible,
`
`consistent with not imposing any significant restraints on the range of application
`
`models that may be implemented.” Id., 28; Ex. 1007, ¶91.
`
`18
`
`
`
`IPR2018-00131
`
`Petition for Inter Partes Review of U.S. Patent No. 6,226,686
`
`Aldred discloses a “shared, interactive application” when applications in a
`
`sharing set operate together. Aldred executes the same software on multiple host
`
`computers and allows users of those computers to maintain their consistency across
`
`a network. See, e.g., Ex. 1009, 1, 2, 5, 7, 27-29. Ex. 1007, ¶93. For example,
`
`Aldred explains that these “sharing sets of application[s]” (“Sharing Set(s)”)
`
`represent a collection of applications that mutually share their data. Ex. 1009, 5;
`
`Ex. 1007, ¶¶92-93. A Sharing Set in Aldred can use a “serialised channel set” to
`
`maintain consistency between applications. Id. For example, Aldred describes
`
`using data serialisation to maintain the consistency between two users
`
`collaborating on a shared drawing surface application such that “the sequence
`
`processed at A and B is identical.” Ex. 1009, 7, Fig. 6. Other related examples
`
`include “continuously” mirrored application windows, a chalkboard where the
`
`“foreground plane can be used for interactive annotation,” and a chat program
`
`where “each participant sees all the exchanged messages, and in the same
`
`sequence.” Id., 27-28; Ex. 1007, ¶92.
`
`Aldred’s disclosure of these shared applications would meet the construction
`
`of “a shared, interactive application” identified by Patent Owner: “software
`
`operating on multiple host computers that provides for sufficient interaction to
`
`allow users of the hosts to share an application or experience.” Ex. 1016, 118.
`
`Ald