PTAB

IPR2017-01620

Google, Inc. v. BlackBerry Limited

Log In

1. Case Identification

2. Patent Overview

  • Title: Secure Systems
  • Brief Description: The ’868 patent is directed to security systems for mobile devices. The technology involves controlling access to sensitive Application Programming Interfaces (APIs) on an application platform by requiring a software application to be digitally signed by an authorized entity before access is granted.

3. Grounds for Unpatentability

Ground 1: Anticipation of Claims 1, 76, 78, 81, 84-85, 90-92, 95, 104, 113, 137, and 142 under 35 U.S.C. §102 by Lin

  • Prior Art Relied Upon: Lin (Patent 6,766,353)
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner argued that Lin discloses all limitations of the challenged claims. Lin describes a system for the "security and authentication of portable code for use by wireless or mobile devices" which includes an application platform with resources (hardware and software). These resources, such as "application libraries," "classes," and "methods," function as the claimed APIs. Lin further teaches restricting access to certain resources based on security concerns, thereby disclosing the "sensitive API" limitation. Critically, Lin describes a process where a downloaded application is authenticated by verifying a digital signature generated using a developer's private key. The mobile device verifies this signature using a corresponding public key, and only upon successful verification is the application granted access to the permitted resources (the sensitive APIs). This process, Petitioner asserted, meets all steps of independent claims 1 and 76.

Ground 2: Claims 13, 88, and 98 are obvious over Lin in view of Garst

  • Prior Art Relied Upon: Lin (Patent 6,766,353) and Garst (Patent 6,188,995)
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner asserted that Lin teaches the base system as detailed in Ground 1. However, Lin does not explicitly disclose displaying a description string when an application attempts to access a sensitive API (claim 13) or verifying the signature each time access is requested (claim 98). Garst, which addresses enforcing licensing agreements for software, remedies this by teaching the display of an error message (e.g., "API Not Licensed") when an unlicensed application is denied access. Garst also discloses that its verification process occurs "each time the [API] receives a request for access."
    • Motivation to Combine: A POSITA would combine Lin's security architecture with Garst's user-feedback and repeated-verification features to improve the system. Displaying a message would enhance usability by informing the user why access was denied. Verifying the signature upon each access request, rather than only at download, would enhance security by ensuring the application's code integrity throughout its use.
    • Expectation of Success: A POSITA would have a reasonable expectation of success in this combination, as it involved implementing a known user-interface feature (an error message) and applying a known security check (verification) at a logical point (each access attempt) using standard programming techniques.

Ground 3: Claims 93, 100, 112, and 139 are obvious over Lin in view of Gong

  • Prior Art Relied Upon: Lin (Patent 6,766,353) and Gong ("Inside Java 2 Platform Security Architecture," 1999)

  • Core Argument for this Ground:

    • Prior Art Mapping: Petitioner argued that while Lin provides the foundational mobile security framework, Gong provides the motivation to add specific features recited in dependent claims. Gong, which describes security for the Java platform (a technology explicitly mentioned in Lin), discloses the use of "proprietary data models" (e.g., Quicken tax files) and obtaining public keys from a remote "keystore database" (a public key repository). Gong also describes a tiered permission model where all applications can access non-sensitive resources, while only applications with a verified signature can access sensitive resources.
    • Motivation to Combine: A POSITA would combine these teachings to improve the capabilities and convenience of Lin's device. Integrating proprietary data models (claim 93) was a known way to enhance user functionality. Using a public key repository (claim 100) would be advantageous for memory-limited mobile devices by offloading key storage and simplifying key updates. Implementing Gong's tiered access model would allow verified applications to access non-sensitive APIs (claim 112), which is a liberal but practical policy for ensuring basic application functionality.
    • Expectation of Success: The combination would have been straightforward. Since Lin's system is based on Java, incorporating security features from Gong's Java security architecture would be a predictable and well-understood modification for a POSITA.

  • Additional Grounds: Petitioner asserted additional obviousness challenges, including combinations of Lin with Davis (Patent 5,844,986) to teach purging unverified code; with Chang (Patent 5,724,425) to teach using a "global signature"; with Sibert (Patent 7,243,236) to teach signing an "abridged version" of the application; with Wong-Insley (Patent 6,131,166) to teach an operating system; and with Haddock (Patent 5,657,378) to teach an I/O controller.

4. Key Claim Construction Positions

  • Petitioner argued for a specific construction of the phrase "determining, at the mobile device, whether the software application is signed."
  • Proposed Construction: Petitioner contended this phrase requires determining whether the application is signed by an entity with an interest in protecting the sensitive API (e.g., the device manufacturer or a designated authority), and explicitly excludes a signature generated by the application developer.
  • Rationale: This construction was based on intrinsic evidence. Petitioner argued the ’868 patent specification repeatedly disparages conventional code-signing schemes that rely on signatures from the developer as unreliable and risky. In contrast, the patent describes the "invention" as a system where access is controlled via signatures from a trusted entity like the manufacturer. Petitioner asserted this constitutes a clear disavowal of claim scope that would otherwise cover developer-generated signatures.

5. Relief Requested

  • Petitioner requests institution of an inter partes review and cancellation of claims 1, 13, 76-86, 88-95, 98, 100, 104, 112, 113, 137, 139, and 142 of the ’868 patent as unpatentable.