PTAB

IPR2018-01238

Valve Corp v. PalTalk Holdings Inc

Log In
Key Events
Petition
petition

1. Case Identification

2. Patent Overview

  • Title: Server-Group Messaging System for Interactive Applications
  • Brief Description: The ’686 patent describes a system for routing messages between host computers in networked, multi-person computer applications. It purports to improve performance by using a "group messaging server" to receive messages from multiple hosts, aggregate them, and transmit the aggregated message to other hosts in the group.

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 (International Publication No. 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 a network of workstations supporting applications like shared chalkboards and chat programs. Aldred teaches using "sharing sets" to group applications and a "Central Serialisation Point" (CSP) to maintain consistency. Petitioner asserted this CSP is the claimed "group messaging server," as it collects all events (messages) from member nodes at a central point and broadcasts them to ensure each member receives the same sequence of data. While Aldred discloses serializing and queueing messages, Petitioner contended it does not explicitly teach "aggregating" message payloads. RFC 1692 was introduced to supply this limitation, as it describes a Transport Multiplexing Protocol (TMux) designed to improve network efficiency by combining multiple short transport segments into a single, larger packet before transmission. The combination of Aldred's CSP architecture with RFC 1692's multiplexing function renders the key claims obvious.
    • Motivation to Combine: A person of ordinary skill in the art (POSITA) would combine Aldred with RFC 1692 to improve network performance. RFC 1692 is explicitly designed to reduce network load for applications that generate many small packets, a characteristic of the real-time collaborative applications described in Aldred (e.g., drawing orders, user input events). Aldred's system is built to work with standard network protocols like TCP/IP, and RFC 1692 is a known extension to the IP protocol. Therefore, applying RFC 1692's multiplexing technique to Aldred's system was a predictable solution to a known problem.
    • Expectation of Success: A POSITA would have had a high expectation of success. The combination involves applying a known network optimization protocol (RFC 1692) to a compatible system architecture (Aldred) to achieve the predictable result of improved network efficiency.

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 upon the combination of Aldred and RFC 1692 from Ground 1 and adds RFC 1459 to address dependent claims that require querying a server about message groups. Specifically, these claims add limitations for a server receiving a control message to query message groups, members, or attributes, and providing a list in response. Petitioner asserted that while Aldred discloses API queries, it does not explicitly teach querying a central server for a list of available "sharing sets." RFC 1459, which describes the Internet Relay Chat (IRC) protocol, was a well-known system where clients could query a central server for a list of available channels (analogous to message groups) and their members.
    • Motivation to Combine: A POSITA would be motivated to incorporate the querying functionality of RFC 1459 into the Aldred/RFC 1692 system to improve its usability and functionality. This modification would allow users to discover and join existing sharing sets dynamically, rather than needing prior knowledge of them. Aldred itself suggests a goal of avoiding the need for applications to "keep track of status information," which is precisely what a central query mechanism as taught by RFC 1459 would achieve.
    • Expectation of Success: Adding a query-response feature to a client-server system like Aldred's CSP was a well-understood and routine modification in 1995. RFC 1459 provided a known, successful template for implementing such functionality in a networked group communication context, ensuring a high expectation of success.

4. Key Claim Construction Positions

  • Petitioner argued that since the ’686 patent has expired, its claims should be interpreted using a district court-type approach. Petitioner primarily relied on the Patent Owner's own proposed constructions from related district court litigation for key terms, asserting the prior art rendered the claims obvious even under those constructions.
  • "aggregating/aggregated": Petitioner adopted Patent Owner's construction: "To collect two or more data items together as a unit, however, where each data item retains its identity and may be extracted from the unit." Petitioner argued that the multiplexing taught by RFC 1692, where multiple transport segments are combined into a single packet but remain distinct and reconstructable, directly meets this construction.

5. Relief Requested

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