Sportradar AG v. SportsCastr Inc

1. Case Identification

• Case #: IPR2025-00275
• Patent #: 11,039,218
• Filed: December 11, 2024
• Petitioner(s): Sportradar AG
• Patent Owner(s): SportsCastr Inc., (D/B/A PANDA INTERACTIVE)
• Challenged Claims: 16-30

2. Patent Overview

• Title: Server and Memory Storage Architecture for Live Event Streaming
• Brief Description: The ’218 patent relates to a server architecture for providing viewers with a live audio/visual feed of an event (e.g., a sporting event) and a separate, synchronized event data feed (e.g., real-time scores) over distinct communication channels to reduce latency.

3. Grounds for Unpatentability

Ground 1: Obviousness over Ellis in view of Spivey - Claims 16-30 are obvious over Ellis in view of Spivey.

• Prior Art Relied Upon: Ellis (Application # 2014/0229992) and Spivey (Application # 2016/0036910).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner argued that Ellis disclosed the core functionality of the ’218 patent: a system that delivers a primary video stream (e.g., a sports broadcast) and a separate stream of supplemental, real-time data (e.g., scores, game summaries) to user equipment over distinct communication paths. However, Petitioner contended that Ellis did not explicitly disclose a socket server architecture for delivering the supplemental data. Spivey allegedly remedied this deficiency by teaching a system specifically designed to reduce latency in real-time data delivery using a websocket connection managed by a "Message Queue Server Device" (socket server) and a "Live Data Server Device" (control server).
  • Motivation to Combine: A Person of Ordinary Skill in the Art (POSITA) would combine the references to improve the performance of Ellis's system. A POSITA would have recognized the known problem of latency in data delivery and would have looked to known solutions like the websocket server architecture taught by Spivey. Implementing Spivey's low-latency data delivery backend into Ellis's general content delivery framework was argued to be a simple substitution of known elements to achieve predictable results.
  • Expectation of Success: A POSA would have had a reasonable expectation of success because both references address the same technical field of real-time content delivery, and Spivey’s socket server was designed to be compatible with standard internet protocols, making its integration into a system like Ellis’s straightforward.

Ground 2: Anticipation by Herzog - Claims 21-22 and 27-28 are anticipated by Herzog.

• Prior Art Relied Upon: Herzog (Application # 2015/0163379).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner asserted that Herzog disclosed every element of independent claim 21. Herzog described a system for streaming live events (using an "Indianapolis Car Race" as an example) that provides multiple video/audio streams and separate "meta-data" streams (e.g., car speed, lap number) to a user's mobile device. The video was streamed using HLS over one communication path, while the metadata was provided over a separate HTTPS path. Petitioner argued this system inherently required transmitting instructions to a client device to request and render the content, thus teaching a system for rendering sporting event information based on digital content received via separate communication channels, as claimed.

Ground 3: Obviousness over Herzog in view of Spivey - Claims 16-20, 23-24, and 29 are obvious over Herzog in view of Spivey.

• Prior Art Relied Upon: Herzog (Application # 2015/0163379) and Spivey (Application # 2016/0036910).

• Core Argument for this Ground:

  • Prior Art Mapping: This ground is presented as an alternative to Ground 1. Petitioner argued that Herzog provided the foundational system of delivering separate live video and metadata streams. However, to the extent Herzog's use of standard HTTPS for data delivery did not explicitly teach the claimed "socket server" with a dedicated "event socket," Spivey supplied this missing element. Spivey taught using a websocket-based socket server (its "MQSD") to provide real-time data with very low latency, which was a known alternative to the HTTP-based methods used in Herzog.
  • Motivation to Combine: A POSITA would combine Herzog with Spivey to improve Herzog’s data delivery latency. A POSITA seeking to enhance the real-time performance of Herzog's system would have been motivated to replace or supplement its data delivery mechanism with Spivey's superior websocket architecture. This was presented as a predictable design choice to solve the known problem of latency.
  • Expectation of Success: A POSA would have expected success because Spivey's system was designed for broad applicability in digital content delivery systems like Herzog's. Combining the two involved applying a known technique (websockets) to a known system (Herzog's live streaming architecture) to yield the predictable result of reduced latency.

• Additional Grounds: Petitioner asserted that claims 25-26 and 30 are obvious over Herzog in view of Ellis, arguing Ellis's teachings on interactive content and real-time chat would have been obviously integrated into Herzog's system.

4. Arguments Regarding Discretionary Denial

• Petitioner argued that the Board should not exercise discretionary denial. Under the Fintiv factors, Petitioner asserted that it filed a stipulation to not pursue the same grounds or any grounds that could have reasonably been raised in this inter partes review (IPR) in the parallel district court litigation, weighing strongly against denial.
• Petitioner also argued against denial under 35 U.S.C. §325(d), contending that the Examiner did not substantively consider the primary reference, Ellis, during prosecution. Furthermore, the key combinations of prior art (e.g., Ellis with Spivey, Herzog with Spivey) were never before the Examiner, and therefore the Office committed a material error by not having the opportunity to evaluate them.

5. Relief Requested

• Petitioner requests institution of IPR and cancellation of claims 16-30 of the ’218 patent as unpatentable.