PTAB

IPR2019-00056

Apple Inc v. Uniloc 2017 LLC

Log In
Key Events
Petition
petition

1. Case Identification

2. Patent Overview

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

3. Grounds for Unpatentability

Ground 1: 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 taught the core invention: a selection server that controls device reconfiguration by checking for appropriate software updates. Cole’s server receives system information from a client, compares it against a database (a "list") of code updates and their system requirements ("known acceptable configurations"), and then indicates approval (by providing download information) or denial (by eliminating the update from consideration). Petitioner asserted MacInnis was added to explicitly teach a user requesting a specific software module, addressing a potential narrow interpretation of the claims that the Examiner adopted during prosecution. Elgressy was added to teach the benefit of using both a list of "acceptable configurations" (allowed resources) and a list of "unacceptable configurations" (prohibited resources) to check against.
    • Motivation to Combine: A POSITA would combine Cole with MacInnis to improve efficiency by allowing the system to check the compatibility of a single, user-requested update rather than processing an entire database of available updates. A POSITA would further incorporate Elgressy's dual-list approach into the Cole/MacInnis system to provide greater versatility in handling upgrade requests (e.g., handling situations where an update could be made compatible) and to address security concerns by explicitly blocking certain updates for reasons beyond simple incompatibility.
    • Expectation of Success: The combination involved applying conventional software techniques, such as using database tables to manage compatibility rules and security policies, which were well-known and would have been straightforward for a POSITA to implement with a high chance of success.

Ground 2: 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 taught a system where a client sends an upgrade request for a specific component to a component server. The server analyzes the request, including "client conditions" (information about the client's current components), to determine an appropriate, compatible version of the requested component. This process inherently involves comparing the requested component and current components against known compatibility requirements. If a compatible version is found, the server provides its location for download (approval); if not, the request is denied. Petitioner argued this base system met most claim limitations.
    • Motivation to Combine: While Pitzel taught the logic of compatibility checking, Cole was added for its explicit teaching of using a formal database table as the "list" to store and organize the compatibility information. A POSITA would combine Pitzel with Cole’s database approach as an efficient and conventional method for organizing and looking up compatibility data, a well-known technique at the time. The motivation to add Elgressy was the same as in Ground 1: to add a list of known unacceptable configurations to Pitzel's system to enhance security and provide more versatile update management.
    • Expectation of Success: A POSITA would have readily integrated a database lookup table (from Cole) and a security blacklist (from Elgressy) into Pitzel’s existing framework for checking component compatibility, as these were standard and predictable software design choices.

4. Key Claim Construction Positions

  • "list": Petitioner argued this term should be construed as “any stored representation of information indicative of component compatibility,” as explicitly stated in the ’088 patent’s specification. This broad construction was central to the argument that the database tables in Cole, the compatibility-checking logic in Pitzel, and the security policies in Elgressy all met the "list" limitation of the challenged claims.

5. Relief Requested

  • Petitioner requests institution of an IPR and cancellation of claims 1-21 of Patent 6,467,088 as unpatentable under 35 U.S.C. §103.