PTAB

IPR2016-01712

Samsung Electronics Co Ltd v. TiVo Inc

Log In
Key Events
Petition
petition Intelligence

1. Case Identification

2. Patent Overview

  • Title: Multimedia Time Warping System
  • Brief Description: The ’389 patent describes a system for the real-time capture, storage, and display of multimedia broadcast signals. The system uses an object-oriented architecture comprising a source object, a transform object, and a sink object to manage data flow from a physical source to a display, with the transform object providing automatic, self-regulating flow control over the other objects.

3. Grounds for Unpatentability

Ground 1: Anticipation - Claims 31 and 61 are anticipated under 35 U.S.C. §102 by Platform SDK.

  • Prior Art Relied Upon: Microsoft Platform Software Development Kit (published January 1998) ("Platform SDK").
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner argued that Platform SDK, a software development kit for Microsoft’s DirectShow and Broadcast Architecture, disclosed every element of claims 31 and 61. The petition mapped the claimed software "objects" to corresponding "filters" in Platform SDK's DirectShow architecture: the claimed "source object" corresponds to Platform SDK's source filter (e.g., an audio/video capture filter); the "transform object" corresponds to the transform filter; and the "sink object" corresponds to the renderer filter. A user application that accesses the system's programming interfaces serves as the claimed "control object." Petitioner asserted that this architecture, managed by a "filter graph manager," performs all the functions recited in the claims, including extracting data from a physical source, storing and retrieving data streams, and outputting to a decoder for display.
    • Key Aspects: A central contention was that Platform SDK taught the key limitation of "automatic flow control," which had been a basis for patentability in a prior reexamination. Petitioner argued that Platform SDK’s transform filter, in conjunction with the filter graph manager, provides this "intelligent" control. It achieves this by managing buffer allocation, rejecting input to stop data flow from the source filter, and passing quality control messages upstream, thereby "self-regulating" the source and sink filters as claimed.

Ground 2: Obviousness - Claims 31 and 61 are obvious under 35 U.S.C. §103 over Platform SDK.

  • Prior Art Relied Upon: Platform SDK.
  • Core Argument for this Ground:
    • Prior Art Mapping: This ground was presented as an alternative to Ground 1. Petitioner argued that if any element was not explicitly disclosed in a single, unified embodiment within Platform SDK, all claimed features were nonetheless taught within its various sections. For instance, the hardware descriptions in the "Broadcast Architecture Programmer's Guide" and the software filter architecture in the "Microsoft DirectShow SDK" section collectively teach the entire claimed system. Petitioner contended that the combination of these known, modular elements to arrive at the claimed invention would have been obvious.
    • Motivation to Combine: The primary motivation asserted was that Platform SDK itself directed a person of ordinary skill in the art (POSITA) to combine its components. The Broadcast Architecture section explicitly states that it "relies on...Microsoft DirectShow" and cross-references the DirectShow section for implementation details. The petition emphasized that the entire DirectShow API was designed around connecting "many independent filter programs together" in a "flexible and capable architecture." Therefore, a POSITA would combine the hardware capabilities described in one part of the SDK with the modular software filters described in another part to create a functional broadcast client.
    • Expectation of Success: A POSITA would have had a high expectation of success because combining these modular software components from a single, integrated development kit was their intended use and would predictably result in a functioning multimedia processing system without requiring any undue experimentation.

4. Key Claim Construction Positions

  • "Object" (source, transform, sink, control): Petitioner adopted constructions from prior litigation, defining an "object" as "a collection of data and operations." The specific functions of each object (e.g., the source object "extracts video and audio data from a physical data source") were incorporated into their respective definitions, aligning the claim scope with the functional descriptions in the patent.
  • "automatically flow controlled": Petitioner argued for a broad construction of this term to mean "self-regulated," consistent with district court rulings and the patent's own description. This construction was critical because it allowed Petitioner to map the term to various flow control mechanisms in Platform SDK, such as buffer management, data rejection, and the use of quality control messages, rather than being limited to a single specific implementation. The petition noted that the patent owner had previously argued that this term means the source and sink objects are "flow controlled by the transform object," a standard the petitioner argued Platform SDK met.

5. Relief Requested

  • Petitioner requested the institution of an inter partes review and the cancellation of claims 31 and 61 of the ’389 patent as unpatentable.