PTAB

IPR2017-01620

Google Inc v. BlackBerry Ltd

Log In
Key Events
Petition
petition

1. Case Identification

2. Patent Overview

  • Title: Secure Systems for Application Access
  • Brief Description: The ’868 patent relates to controlling a software application’s access to sensitive Application Programming Interfaces (APIs) on a mobile device. The technology requires an application to be digitally signed by a trusted entity, such as the device manufacturer or a designated code signing authority, to be granted access to protected platform resources.

3. Grounds for Unpatentability

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

  • Prior Art Relied Upon: Lin (Patent 6,766,353).
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner argued that Lin discloses every element of the challenged independent claims. Lin describes a system for the "security and authentication of portable code for use by wireless or mobile devices," including an application platform, storing APIs (disclosed as "classes," "methods," and "application libraries"), and restricting access to these resources based on security permissions. Petitioner asserted that Lin's method of authenticating an application by verifying a developer's digital signature using public-key cryptography before allowing access to permitted resources directly maps to the limitations of claims 1 and 76. Dependent claims related to denying access upon failed verification and using a virtual machine were also argued to be expressly or inherently taught by Lin.

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

  • Prior Art Relied Upon: Lin (Patent 6,766,353), Garst (Patent 6,188,995).
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner contended that while Lin teaches the core security framework, Garst supplies the limitations of displaying a description string (claims 13, 88) and verifying the signature upon each access attempt (claim 98). Garst allegedly discloses a system that displays an error message (e.g., “API Not Licensed”) upon a denied access attempt and performs its verification process "each time the [API] receives a request for access."
    • Motivation to Combine: A POSITA would combine Lin’s security architecture with Garst’s teachings to improve usability and security. Adding user notifications would inform the user of an access denial, and verifying the signature at each access attempt would ensure the application's integrity throughout its use, representing a predictable enhancement to Lin's system.
    • Expectation of Success: The combination involved applying known programming methods (user notifications, repeated checks) to an existing security framework to achieve the predictable result of a more robust and user-friendly system.

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

  • Prior Art Relied Upon: Lin (Patent 6,766,353), Gong ("Inside Java 2 Platform Security Architecture...").
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner argued that a POSITA would find it obvious to modify Lin's system to include features taught by Gong, such as a proprietary data model (claim 93), obtaining a public key from a repository (claim 100), and allowing access to non-sensitive APIs (claims 112, 139). Gong, which describes security for the Java platform also referenced in Lin, explicitly teaches using a "keystore database" as a public key repository and implementing security models where all applications can access non-sensitive resources while only trusted applications can access sensitive ones.
    • Motivation to Combine: A POSITA would combine these teachings to improve device capabilities and efficiency. Using a public key repository, as taught by Gong, would be advantageous for memory-limited devices like those in Lin. Further, allowing default access to non-sensitive APIs is a practical necessity for basic application functionality, making its inclusion a logical design choice.
    • Expectation of Success: Since both references address security on the Java platform, integrating Gong's well-established architectural features into Lin's mobile security system would have been a straightforward modification with a high expectation of success.
  • Additional Grounds: Petitioner asserted additional obviousness challenges based on Lin in combination with other references. These combinations sought to add known elements such as purging unverified code (Davis), implementing a "global" signature for platform access (Chang), signing an "abridged" version of the application for efficiency (Sibert), and explicitly including an operating system (Wong-Insley) or I/O controller (Haddock).

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...” recited in claims 1 and 76.
  • Proposed Construction: The phrase requires determining whether the application includes a digital signature generated using a private key corresponding to an entity with an interest in protecting access to the sensitive API (e.g., a device manufacturer or code signing authority), not merely the application developer.
  • Supporting Argument: Petitioner asserted that the specification of the ’868 patent explicitly and repeatedly disavows prior art code signing schemes where the signature only identifies the developer. The patent allegedly frames its invention as a contrast to such schemes, emphasizing a stricter, application-by-application control model where a trusted authority, not the developer, provides the signature required to access sensitive APIs.

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.