PTAB

IPR2016-00727

Activision Blizzard Inc v. Acceleration Bay LLC

Key Events
Petition
petition Intelligence

1. Case Identification

2. Patent Overview

  • Title: Broadcast Channel Within a Computer Network
  • Brief Description: The ’634 patent describes a method for a new participant to join a broadcast channel in a computer network. The method involves using a "portal computer" to identify existing neighbor participants, then establishing connections to form an m-regular network, where each participant is connected to the same number (m) of neighbors.

3. Grounds for Unpatentability

Ground 1: Claims 19-24 are obvious over [Obraczka](https://ai-lab.exparte.com/case/ptab/IPR2016-00727/doc/1224) and the [Obraczka Thesis](https://ai-lab.exparte.com/case/ptab/IPR2016-00727/doc/1225) in view of [Shoubridge](https://ai-lab.exparte.com/case/ptab/IPR2016-00727/doc/1205).

  • Prior Art Relied Upon: Obraczka (a 1996 IEEE paper), Obraczka Thesis (a 1994 Ph.D. Thesis), and Shoubridge (a 1997 IEEE paper).
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner argued that Obraczka and its corresponding Thesis disclose a scalable system for replicating internet data among a group of participants ("replicas"). This system uses a "group master" to manage network topology and a "flooding" protocol for updates. When a new site seeks to join, it contacts an existing member (the claimed "portal computer") and sends a join request, which is flooded through the network. The group master then calculates a new, optimized k-connected logical topology and distributes it. Shoubridge discloses robust, non-routing table based flooding protocols over dynamic networks with specific topologies, namely m-regular, m-connected, and non-complete graphs (e.g., a 4-regular torus).
    • Motivation to Combine: A POSITA would combine the systems because both address efficient and reliable data replication in wide-area networks. Petitioner asserted that a POSITA implementing Obraczka’s dynamic replication system would have been motivated to use Shoubridge’s well-known, robust m-regular network topology and non-routing table flooding protocol to increase reliability, scalability, and efficiency, particularly as the number of network participants grows.
    • Expectation of Success: The combination was presented as straightforward, as both references operate in the same technical field of computer networking and address similar problems of data distribution and network topology management.

Ground 2: Claims 19-22 and 24 are obvious over [DirectPlay](https://ai-lab.exparte.com/case/ptab/IPR2016-00727/doc/1203) in view of Shoubridge.

  • Prior Art Relied Upon: DirectPlay (a 1998 book on Microsoft’s DirectX API) and Shoubridge (a 1997 IEEE paper).
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner contended that DirectPlay, an API for multiplayer games, discloses the claimed "portal computer" concept through its "lobby server." Players use a lobby client to find a lobby server, which provides information on available gaming sessions and other players. Once a session is chosen, the lobby server facilitates connections between players, who then form a peer-to-peer or client-server network. DirectPlay itself does not mandate a specific network topology. Shoubridge provides the missing element by teaching a robust, scalable, m-regular, non-complete network topology suitable for dynamic environments, as described in Ground 1.
    • Motivation to Combine: A POSITA would combine these references to address the scalability challenges of multiplayer gaming. DirectPlay teaches a future of gaming with "hundreds or even thousands of players," which would require a more reliable and efficient network topology than a simple, fully-connected peer-to-peer mesh. A POSITA would have been motivated to implement the robust and scalable m-regular architecture from Shoubridge to improve the reliability and performance of the gaming network taught by DirectPlay.
    • Expectation of Success: Success was expected because DirectPlay was designed as a flexible interface that could work with various underlying network service providers, and Shoubridge provides a well-defined, reliable network topology that directly addresses the scalability and reliability needs identified in DirectPlay.

Ground 3: Claim 23 is obvious over DirectPlay and Shoubridge in further view of [Denes](https://ai-lab.exparte.com/case/ptab/IPR2016-00727/doc/1228).

  • Prior Art Relied Upon: DirectPlay, Shoubridge, and Denes (a 1979 mathematics paper).
  • Core Argument for this Ground:
    • Prior Art Mapping: This ground targets the specific steps of claim 23: "receiving a request to connect to another participant; disconnecting from a neighbor participant; and connecting to the other participant." Petitioner argued the combination of DirectPlay and Shoubridge teaches a system needing to dynamically add participants to an m-regular network. Denes provides the final piece by disclosing a simple mathematical algorithm for maintaining a 2-regular graph structure when adding a new node. Denes's "EC" operation involves disconnecting two existing neighbor nodes and connecting each of them to the new node, directly mapping to the claim limitations.
    • Motivation to Combine: A POSITA, having combined DirectPlay and Shoubridge to create a scalable gaming network, would seek a predictable method for maintaining the network’s m-regular structure as new players join. Denes provides a known, straightforward mathematical principle for accomplishing this task. Petitioner asserted it would have been obvious to apply the well-known teachings of Denes to the network to improve its reliability and maintain its structural integrity during dynamic expansion.

4. Key Claim Construction Positions

  • “m-regular”: Petitioner proposed this term means “each node is connected to exactly m other nodes.”
  • “non-complete graph”: Proposed to mean a “graph in which at least two nodes are not connected to each other.”
  • “m-connected”: Proposed to mean that “dividing the network into two or more separate parts would require the removal of at least m nodes.”
  • “non-routing table based”: Petitioner proposed this means instructions “that are implemented without the use of routing tables.”

5. Relief Requested

  • Petitioner requests institution of an inter partes review and cancellation of claims 19-24 of the ’634 patent as unpatentable under 35 U.S.C. §103.