Riot Games Inc v. PalTalk Holdings Inc

1. Case Identification

• Case #: IPR2018-00131
• Patent #: 6,226,686
• Filed: November 2, 2017
• Petitioner(s): Riot Games, Inc.
• Patent Owner(s): Paltalk Holdings, Inc.
• Challenged Claims: 1-4, 7-21, 28-35, 39, 40, 47-54, 56, 57, 64-70

2. Patent Overview

• Title: SERVER-GROUP MESSAGING SYSTEM FOR INTERACTIVE APPLICATIONS
• Brief Description: The ’686 patent describes a system for managing communications in networked, multi-person interactive applications. It purports to improve performance by using a central "group messaging server" to receive messages from multiple host computers, aggregate them, and distribute them to members of a message group to maintain a consistent state.

3. Grounds for Unpatentability

Ground 1: Obviousness over Aldred and RFC 1692 - 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 in view of RFC 1692.

• Prior Art Relied Upon: Aldred (WO 94/11814) and RFC 1692 (Transport Multiplexing Protocol, Aug. 1994).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner argued that Aldred discloses a collaborative working environment for networked workstations that supports a broad spectrum of interactive applications. Aldred’s system uses a “Central Serialisation Point” (CSP) on one of the network nodes to collect all events for a given “Sharing Set” (a group of collaborating applications), serialize them, and broadcast them to all members to maintain consistency. Petitioner asserted this CSP/Sharing Set architecture directly maps to the ’686 patent’s claimed “group messaging server” and “message group.” Specific limitations were allegedly met by Aldred’s disclosure of share_app requests, which function as “create message” and “join message” commands to establish and join Sharing Sets. The CSP’s function of receiving messages from various applications in the set maps to the “receiving host messages” limitation. While Aldred discloses serializing and sending packets, Petitioner contended it does not explicitly teach aggregating multiple payloads into a single larger packet. This “aggregating” limitation was allegedly met by RFC 1692, which teaches a Transport Multiplexing Protocol (TMux) designed to improve network efficiency by combining multiple short transport segments into a single IP datagram before transmission.
  • Motivation to Combine: A POSITA would combine RFC 1692 with Aldred to improve network performance. Aldred’s system, which handles events like drawing orders and user inputs, would naturally generate many small packets. RFC 1692 is explicitly designed to reduce network and host load in such situations. Petitioner noted that Aldred itself suggests data multiplexing can be implemented below the application layer, and its architecture is agnostic to the underlying transport protocol, making the integration of an IP-level enhancement like TMux a predictable and logical step.
  • Expectation of Success: A POSITA would have had a high expectation of success. Aldred’s system was designed to operate over standard networks like TCP/IP, and RFC 1692 is a compatible extension of the IP protocol. Combining them would involve using the TMux-enhanced IP protocol for Aldred’s transport mechanism, a task well within the skill of a POSITA that would predictably result in the aggregation of Aldred's serialized messages.

Ground 2: Obviousness over Aldred, RFC 1692, and RFC 1459 - Claims 31-33, 50-52, and 67-69 are obvious over Aldred in view of RFC 1692 and RFC 1459.

• Prior Art Relied Upon: Aldred (WO 94/11814), RFC 1692, and RFC 1459 (Internet Relay Chat Protocol, May 1993).
• Core Argument for this Ground:
  • Prior Art Mapping: This ground builds on the combination of Aldred and RFC 1692 to address dependent claims requiring a server to handle control messages that query for information about message groups (e.g., lists of groups, members, or attributes). Petitioner argued that while Aldred provides local APIs for applications, it does not explicitly teach a client querying a remote central server for such information. This functionality was allegedly taught by RFC 1459, the Internet Relay Chat (IRC) protocol. RFC 1459 describes a client-server system where clients can send specific commands, such as a LIST command, to a central server to query for and receive lists of available channels (analogous to message groups) and their members. Petitioner argued this directly teaches the claimed limitations of querying a server for a list of message groups and receiving that list in response.
  • Motivation to Combine: A POSITA would be motivated to add the query functionality of RFC 1459 to the Aldred/RFC 1692 system to enhance its efficiency and usability. Aldred itself identifies the problem of applications needing to track status information. RFC 1459 provides a well-known solution by allowing clients to query a central point for status on demand, reducing the need for constant broadcast updates. This would also allow users to discover new "Sharing Sets" they might wish to join, improving the overall utility of Aldred’s collaborative environment.
  • Expectation of Success: Adding a query-response mechanism to a client-server system like that disclosed in Aldred is a conventional design choice. A POSITA would have reasonably expected that implementing RFC 1459’s well-understood query commands within Aldred’s framework would successfully allow clients to retrieve information from the CSP without disrupting the system’s primary messaging functions.

4. Key Claim Construction Positions

• Petitioner contended that the challenged claims are obvious under any reasonable construction, including those advanced by the Patent Owner in co-pending litigation, making formal construction by the Board unnecessary.
• For “group messaging server,” Petitioner argued that Aldred's CSP—a central node that collects, serializes, and broadcasts messages to a "Sharing Set"—meets all elements of the Patent Owner's proposed multi-part construction, including maintaining message groups and managing membership.
• For “aggregating,” Petitioner argued the combination with RFC 1692's TMux protocol—which combines multiple data items into a single unit for transmission where each item retains its identity via mini-headers—satisfies the Patent Owner's construction of the term.
• For "shared, interactive application," Petitioner asserted that Aldred's examples of shared drawing surfaces, mirrored windows, and chat programs meet the Patent Owner's construction of software operating on multiple hosts to allow users to share an experience.

5. Relief Requested

• Petitioner requested the institution of an inter partes review and the cancellation of claims 1-4, 7-21, 28-35, 39, 40, 47-54, 56, 57, and 64-70 of the ’686 patent as unpatentable under 35 U.S.C. §103.