Opinion
2019-1568 2019-1569 2019-1624 2019-1625
09-02-2020
GOOGLE LLC, Appellant v. BLACKBERRY LTD., Cross-Appellant
PHILLIP W. CITROEN, Paul Hastings LLP, Washington, DC, argued for appellant. Also represented by NAVEEN MODI, STEPHEN BLAKE KINNAIRD, SEONGHEE EMILY LEE, JOSEPH PALYS. CHING-LEE FUKUDA, Sidley Austin LLP, New York, NY, argued for cross-appellant. Also represented by SHARON LEE; SAMUEL DILLON, Washington, DC.
NOTE: This disposition is nonprecedential. Appeals from the United States Patent and Trademark Office, Patent Trial and Appeal Board in Nos. IPR2017-01619, IPR2017-01620. PHILLIP W. CITROEN, Paul Hastings LLP, Washington, DC, argued for appellant. Also represented by NAVEEN MODI, STEPHEN BLAKE KINNAIRD, SEONGHEE EMILY LEE, JOSEPH PALYS. CHING-LEE FUKUDA, Sidley Austin LLP, New York, NY, argued for cross-appellant. Also represented by SHARON LEE; SAMUEL DILLON, Washington, DC. Before WALLACH, CHEN, and STOLL, Circuit Judges. CHEN, Circuit Judge.
In June 2017, Google LLC (Google) filed two inter partes review (IPR) petitions with the United States Patent and Trademark Office's Patent Trial and Appeal Board (Board), requesting review of claims 1, 13, 76-95, 98, 100, 104, 108, 112, 113, 137-139, and 142-144 of U.S. Patent No. 8,489,868 ('868 patent) in its first petition (1619 proceeding) and claims 1, 13, 76-86, 88-95, 98, 100, 104, 112, 113, 137, 139, and 142 of the '868 patent in its second petition (1620 proceeding). The '868 patent is directed to controlling a software application's access to certain application programming interfaces (APIs) by requiring verification of a digital signature. '868 patent col. 1 ll. 54-61. On December 22, 2017, the Board instituted review. The Board subsequently issued its Final Decisions on December 19, 2018. Google appeals the Board's conclusion that claims 77, 79, 80, 82, 86, and 112 in the 1619 proceeding and claims 13, 85, 86, 88, 98, 104, and 112 in the 1620 proceeding were not proven to be unpatentable. BlackBerry Ltd. (BlackBerry), the patent owner, cross appeals the Board's conclusion that claims 1 and 76 are unpatentable in the 1619 proceeding and 1620 proceeding and that claims 77, 79, and 80 are unpatentable in the 1620 proceeding. We affirm the Board's decisions and reject both sides' arguments to the contrary.
With respect to claim 86, Google argues that the Board incorrectly construed "abridged version of the software" to mean "a unique transformation of the software application that is smaller than the software application." Google's Opening Br. 39. Specifically, Google argues that the plain meaning of "abridged version of the software" is simply a "shortened version of the software application," id. at 29 (internal quotations omitted)—as opposed to also requiring a unique transformation. That argument, however, fails to consider the claim language's meaning in the context of the patent. Claim 86 states in relevant part "applying the private key to a first abridged version of the software application; and the digital signature is verified by generating a second abridged version." '868 patent at claim 86. The abridged version is used to verify the digital signature of the application and thus each application requires a different digital signature. The '868 specification discusses generating different outputs for different inputs so that each software application will have an abridged version that is unique and therefore a signature that can only be verified when appended to the particular software application. Id. at col. 6 ll. 32-37 ("If an otherwise abridged version of the software application Y is sent to the code signing authority, then the abridged version may similarly be used to generate the digital signature, provided that the abridging scheme or algorithm, like a hashing algorithm, generates different outputs for different inputs."), col. 10 l. 64-col. 11 l. 2 ("[T]he digital signature is preferably generated from a hash or otherwise transformed version of the software application and is therefore application-specific."). We therefore agree with the Board that the specification makes clear that "abridged version of the software application" is "a unique transformation of the software application that is smaller than the software application."
In both the 1619 proceeding and 1620 proceeding petitions, Google argued that U.S. Patent No. 7,243,236 (Sibert) disclosed an "abridged version of the software." J.A. 178, 939. Based on the construction above, requiring the abridged version to be unique, substantial evidence supports the Board's finding that Sibert does not disclose the claimed limitation. Sibert discloses randomly selecting portions of an application to create an abridged version. '236 patent col. 7 ll. 52-59. BlackBerry's expert, Dr. Ligler, stated in his declaration that a random selection to create an abridged version is not the same as a unique abridged version. J.A. 6083 ("Sibert has concluded that signing subsets of a software application provides an adequate level of security for its system, but that does not mean that hashing a subset of the program results in a unique transformation of that program."). Google's expert did not opine on Sibert's teachings based on the correct construction. Based on this record, a reasonable fact finder could conclude, as the Board did, that Google did not meet its burden of proof as to whether Sibert discloses the claim limitation as properly construed.
Next, Google argues that claim 112 is unpatentable, and the Board erroneously construed the word "upon" in the claim to mean that access to a non-sensitive API is conditioned on verifying a signature. Google's Opening Br. 51. We disagree with Google and affirm the Board's understanding of "upon." Claim 112 in pertinent part states "upon verifying the digital signature at the mobile device, the mobile device allowing the software application access to at least one non-sensitive API." '868 patent at claim 112. The plain and ordinary meaning of "upon" in the context of the claim means that the digital signature is verified to allow applications access to non-sensitive APIs, which is conditional and not merely temporal. Google points to nothing persuasive in the intrinsic evidence that would change the plain meaning.
Because the Board applied the correct understanding of "upon," the Board properly rejected Google's unpatentability theories in both proceedings, all of which are premised on an incorrect interpretation of the word "upon." Additionally, none of the asserted prior art references teach the limitation that upon verifying a digital signature the application is granted access to non-sensitive APIs. Therefore, the Board correctly concluded that Google failed to establish that claim 112 is unpatentable.
Google also argues, with respect to claim 112, that the Board erred by disregarding the teachings of Gong and incorrectly focused solely on the individual teachings of Garst and Lin. Google's Opening Br. 56. But Google's petitions never argued that Gong teaches access to a non-sensitive API based upon verification of a signature. J.A. 168-70, 951-54. In fact, Google explicitly stated that "Gong describes implementing the Java security model such that any application—regardless of whether the application has a verified digital signature—can access some resources (non-sensitive resources) while only applications having a verified digital signature can also access additional resources (sensitive resources)." Id. at 169, 952. Because Google did not contend before the Board that Gong disclosed this particular claim limitation, that contention was waived and the Board did not err in focusing its analysis on the remaining prior art references.
In the 1619 petition, Google argued U.S. Patent No. 6,188,995 (Garst) in view of the book titled "Inside Java 2 Platform Security: Architecture, API Design, and Implementation" (Gong) disclosed the limitations of claim 112. In the 1620 petition, Google argued that U.S. Patent No. 6,766,353 (Lin) anticipated claim 112. --------
BlackBerry cross appeals and argues that the Board erred in finding claims 1 and 76 unpatentable in the 1619 proceeding because the Board improperly construed "signed software application." BlackBerry's Opening Br. 72-74. The Board construed the phrase "signed software application" to mean "simply an application that 'includes a digital signature generated using a private key.'" J.A. 11. Based on the claim language and specification, we affirm this construction. Neither the specification nor claims require, as BlackBerry urges, "a software application that is itself signed, i.e., the signature is of the software application or a unique transformation of the software application, such as a hashed or abridged transformation of the software application." BlackBerry's Opening Br. 84. The claims recite only that the digital signature is generated using a private key. The claims do not recite that the private key must be applied to the software application. The '868 specification states that an application is signed when "a signature for the software application is generated by the code signing authority and appended to the software application." '868 patent col. 4 ll. 36-40. Therefore, based on the claims and specification, "signed software application" means "an application that includes a digital signature generated using a private key." It is undisputed that based on the Board's interpretation of signed software application, Garst in view of Gong discloses the limitations of claims 1 and 76. BlackBerry's Opening Br. 78; Hearing Tr. 20:30-22:37.
Also in its cross appeal, BlackBerry argues that the Board erred in finding claims 1 and 76 anticipated in the 1620 proceeding because Lin does not disclose "based upon verifying the digital signature at the mobile device, the mobile device allowing the software application access to the sensitive API." BlackBerry's Opening Br. 76. Lin teaches the steps of granting access to an application as well as successfully verifying an application's digital signature. '353 patent col. 1 ll. 6-11, col. 2 ll. 39-40. Lin does not expressly describe that access is conditioned on successful verification of the digital signature. However, relying on expert testimony, the Board reasonably found that a skilled artisan would have understood that successful verification of Lin's digital signature grants access to the sensitive API, especially because there was no other purpose for the digital signature than to allow access. J.A. 64. We agree with the Board. Google's expert, Dr. McDaniel, explained in detail the use for the signature and, like the Board, we see no other purpose for the verification of a digital signature. See J.A. 5819 (224:2-25). We therefore find that the Board's conclusion that Lin anticipates claims 1 and 76 is supported by substantial evidence.
BlackBerry also appeals the Board's findings in the 1620 proceeding that claims 77, 78, and 79 are unpatentable. BlackBerry's Opening Br. 93. BlackBerry argues that Lin does not disclose denying an application access to an API when the signature is missing. Id. at 93-94. The Board found that because Lin discloses allowing the application access if the signature can be verified, it likewise implicitly discloses not granting access if the signature cannot be verified. J.A. 69. Substantial evidence supports that finding. Lin's mobile device authenticates the signed time stamp, which is used by the mobile device to check whether the application developer file is signed within the valid period of the developer certificate. '353 patent col. 3 ll. 56-61. Lin performs the step of verifying the signature, and a skilled artisan would understand that an application in Lin would not be granted access if a signature was not verified, regardless of the reason. We therefore affirm the Board's interpretation of Lin and its conclusion of unpatentability as to claims 77, 78, and 79.
We have considered all remaining arguments and find them unpersuasive. The Board opinions were detailed and thorough and we see no reversible error. Accordingly, the Final Decisions of the Board are
AFFIRMED
COSTS
No costs.