PTAB

IPR2019-00056

Apple Inc. v. UNILOC 2017 LLC

Log In

1. Case Identification

2. Patent Overview

  • Title: Controlling Reconfiguration of an Electronic Device
  • Brief Description: The ’088 patent describes a system and method for managing software or hardware updates on an electronic device. The system controls reconfiguration by comparing a requested component and the device's current components against a list of known acceptable or unacceptable configurations to approve or deny the request.

3. Grounds for Unpatentability

Ground 1: Obviousness over Cole, MacInnis, and Elgressy - Claims 1-21 are obvious over Cole in view of MacInnis and Elgressy.

  • Prior Art Relied Upon: Cole (Patent 5,752,042), MacInnis (WO 97/30549), and Elgressy (Patent 6,449,723).
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner argued that Cole discloses the core of the invention: a selection server that receives a request from a client, determines required code updates, and compares the client’s system information (e.g., BIOS level, motherboard ID) against a database of system requirements. This database functions as the claimed "list of known acceptable configurations." To address a narrow interpretation from prosecution history, Petitioner added MacInnis, which explicitly teaches a user requesting a specific software module (e.g., a video game) and checking its compatibility against a table. Elgressy was introduced to explicitly teach the use of both a list of allowed resources (an acceptable list) and a list of prohibited resources (an unacceptable list) to enhance security and control, mapping directly to claims requiring both types of lists.
    • Motivation to Combine: A POSITA would combine Cole with MacInnis to improve efficiency by checking compatibility only for a user-selected update, rather than all possible updates in a database. A POSITA would further incorporate Elgressy's dual-list security model into the Cole/MacInnis system to provide greater versatility and security, such as preventing the installation of insecure but otherwise compatible software or handling complex dependency updates.
    • Expectation of Success: Petitioner asserted that combining these known software techniques—user-selection, database lookups, and security policies—was conventional and would be accomplished with a high chance of success.

Ground 2: Obviousness over Pitzel, Cole, and Elgressy - Claims 1-21 are obvious over Pitzel in view of Cole and Elgressy.

  • Prior Art Relied Upon: Pitzel (Patent 7,062,765), Cole (Patent 5,752,042), and Elgressy (Patent 6,449,723).
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner contended that Pitzel serves as an alternative primary reference that teaches the claimed invention. Pitzel describes a component server that receives an upgrade request from a client, analyzes "client conditions" (e.g., existing software/hardware), and determines an appropriate version of a requested component. Pitzel also discloses identifying and providing additional necessary components (dependencies). Petitioner argued this process inherently involves comparing the requested/determined components and the client's current components with known compatibility information. To the extent Pitzel might not explicitly disclose a "list" in the form of a database table, Cole was cited for its clear teaching of using such a table for determining component compatibility. Elgressy was again used to supply the teaching of using both acceptable and unacceptable lists for security and control.
    • Motivation to Combine: A POSITA would be motivated to modify Pitzel's system to use the efficient database table structure taught by Cole for organizing and querying compatibility requirements, given the similar objectives of both systems. The motivation to incorporate Elgressy was the same as in Ground 1: to improve the system’s versatility in handling upgrade requests and to address security concerns by explicitly allowing or disallowing components based on security policies, not just technical compatibility.
    • Expectation of Success: Modifying Pitzel's system with the conventional database techniques of Cole and the well-known security list concepts from Elgressy would have been straightforward for a POSITA with a high expectation of success.

4. Key Claim Construction Positions

  • "list": Petitioner argued the term "list" should be interpreted broadly, consistent with the patent’s explicit definition, to mean "any stored representation of information indicative of component compatibility." This construction is critical because it allows the logic and data structures within the prior art (e.g., Cole's database table, Pitzel's upgrade handler logic) to be considered a "list," even if not explicitly labeled as such. Petitioner noted this construction should apply under either the Broadest Reasonable Interpretation or the Phillips standard.

5. Relief Requested

  • Petitioner requests institution of an inter partes review and cancellation of claims 1-21 of Patent 6,467,088 as unpatentable.