Google LLC v. Blackberry Ltd.

Case: 19-1568 Document: 59 Page: 1 Filed: 09/02/2020

NOTE: This disposition is nonprecedential.

United States Court of Appeals

for the Federal Circuit

______________________

GOOGLE LLC,

Appellant

v.

BLACKBERRY LTD.,

Cross-Appellant

______________________

2019-1568, 2019-1569, 2019-1624, 2019-1625

______________________

Appeals from the United States Patent and Trademark

Office, Patent Trial and Appeal Board in Nos. IPR2017-

01619, IPR2017-01620.

______________________

Decided: September 2, 2020

______________________

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.

______________________

Case: 19-1568 Document: 59 Page: 2 Filed: 09/02/2020

2 GOOGLE LLC v. BLACKBERRY LTD.

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 pro-

ceeding) and claims 1, 13, 76–86, 88–95, 98, 100, 104, 112,

113, 137, 139, and 142 of the ’868 patent in its second peti-

tion (1620 proceeding). The ’868 patent is directed to con-

trolling 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 De-

cember 19, 2018. Google appeals the Board’s conclusion

that claims 77, 79, 80, 82, 86, and 112 in the 1619 proceed-

ing and claims 13, 85, 86, 88, 98, 104, and 112 in the 1620

proceeding were not proven to be unpatentable. Black-

Berry Ltd. (BlackBerry), the patent owner, cross appeals

the Board’s conclusion that claims 1 and 76 are unpatent-

able in the 1619 proceeding and 1620 proceeding and that

claims 77, 79, and 80 are unpatentable in the 1620 proceed-

ing. 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

Case: 19-1568 Document: 59 Page: 3 Filed: 09/02/2020

GOOGLE LLC v. BLACKBERRY LTD. 3

patent. Claim 86 states in relevant part “applying the pri-

vate key to a first abridged version of the software applica-

tion; 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 differ-

ent digital signature. The ’868 specification discusses gen-

erating 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 gener-

ate 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 ap-

plication and is therefore application-specific.”). We there-

fore 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 peti-

tions, Google argued that U.S. Patent No. 7,243,236 (Si-

bert) 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 sup-

ports 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 sub-

sets of a software application provides an adequate level of

Case: 19-1568 Document: 59 Page: 4 Filed: 09/02/2020

4 GOOGLE LLC v. BLACKBERRY LTD.

security for its system, but that does not mean that hash-

ing a subset of the program results in a unique transfor-

mation 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 con-

ditioned on verifying a signature. Google’s Opening Br. 51.

We disagree with Google and affirm the Board’s under-

standing 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 al-

low applications access to non-sensitive APIs, which is con-

ditional 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 unpatenta-

bility theories in both proceedings, all of which are prem-

ised 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 in-

correctly focused solely on the individual teachings of Garst

Case: 19-1568 Document: 59 Page: 5 Filed: 09/02/2020

GOOGLE LLC v. BLACKBERRY LTD. 5

and Lin. 1 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 de-

scribes 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 re-

sources (sensitive resources).” Id. at 169, 952. Because

Google did not contend before the Board that Gong dis-

closed this particular claim limitation, that contention was

waived and the Board did not err in focusing its analysis

on the remaining prior art references.

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 soft-

ware application” to mean “simply an application that ‘in-

cludes 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 applica-

tion that is itself signed, i.e., the signature is of the soft-

ware application or a unique transformation of the

software application, such as a hashed or abridged trans-

formation of the software application.” BlackBerry’s Open-

ing Br. 84. The claims recite only that the digital signature

1 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 Imple-

mentation” (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.

Case: 19-1568 Document: 59 Page: 6 Filed: 09/02/2020

6 GOOGLE LLC v. BLACKBERRY LTD.

is generated using a private key. The claims do not recite

that the private key must be applied to the software appli-

cation. 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 dis-

closes 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 mo-

bile 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 suc-

cessfully verifying an application’s digital signature.

’353 patent col. 1 ll. 6–11, col. 2 ll. 39–40. Lin does not ex-

pressly 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 ver-

ification of Lin’s digital signature grants access to the sen-

sitive 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, ex-

plained in detail the use for the signature and, like the

Board, we see no other purpose for the verification of a dig-

ital 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

Case: 19-1568 Document: 59 Page: 7 Filed: 09/02/2020

GOOGLE LLC v. BLACKBERRY LTD. 7

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 sig-

nature 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 sig-

nature 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.