`
` Paper 31
`Trials@uspto.gov
`571-272-7822 Entered: December 19, 2018
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`
`GOOGLE LLC,
`Petitioner
`
`v.
`
`BLACKBERRY LTD.,
`Patent Owner.
`____________
`
`Case IPR2017-01619
`Patent 8,489,868 B2
`____________
`
`
`
`Before SALLY C. MEDLEY, ROBERT J. WEINSCHENK,
`and AARON W. MOORE, Administrative Patent Judges.
`
`MOORE, Administrative Patent Judge.
`
`
`
`
`FINAL WRITTEN DECISION
`35 U.S.C. § 318(a) and 37 C.F.R. § 42.73
`
`
`
`
`
`
`

`

`IPR2017-01619
`Patent 8,489,868 B2
`
`A. Background
`
`I. INTRODUCTION
`
`Google LLC (“Petitioner”) filed a Petition (Paper 1, “Pet.”) for inter
`partes 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 B2 (Ex. 1001, “the ’868 patent”).
`The Petition asserted that these claims are unpatentable on the following
`grounds (see Pet. 2–3):
`
`References
`
`Basis
`
`Garst1 and Gong2
`
`§ 103(a)3
`
`Garst, Gong, and Davis4
`Garst, Gong, and Chang5
`Garst, Gong, and Sibert6
`Garst, Gong, and Wong-Insley7
`Garst, Gong, and Haddock8
`
`§ 103(a)
`§ 103(a)
`§ 103(a)
`§ 103(a)
`§ 103(a)
`
`Challenged Claim(s)
`1, 13, 76, 78, 81, 84, 85,
`87, 88, 90–93, 95, 98,
`100, 104, 108, 112, 113,
`137–39, and 142–44
`77, 79, 80, and 82
`83
`86
`89
`94
`
`
`1 U.S. Patent No. 6,188,995 B1, Feb. 13, 2001 (Ex. 1012).
`2 Li Gong, Inside JavaTM 2 Platform Security (1999) (Ex. 1016).
`3 Because the effective filing date of the ’868 patent is earlier than
`March 16, 2013, the pre-AIA version of § 103 controls.
`4 U.S. Patent No. 5,844,986, Dec. 1, 1998 (Ex. 1013).
`5 U.S. Patent No. 5,724,425, Mar. 3, 1998 (Ex. 1014).
`6 U.S. Patent No. 7,243,236 B1, July 10, 2007 (Ex. 1015).
`7 U.S. Patent No. 6,131,166, Oct. 10, 2000 (Ex. 1017).
`8 U.S. Patent No. 5,657,378, Aug. 12, 1997 (Ex. 1018).
`2
`
`

`

`IPR2017-01619
`Patent 8,489,868 B2
`
`We instituted an inter partes review on all grounds raised in the
`Petition. See Paper 9 (“Inst. Dec.”) at 21.
`The briefing in this proceeding now includes the Petition, a Patent
`Owner Response (Paper 16, “PO Resp.”), a Petitioner Reply (Paper 19,
`“Reply”), and a Patent Owner Sur-Reply (Paper 26, “Sur-Reply”). On
`September 17, 2018, we held an oral hearing, together with IPR2017-01620,
`a transcript of which is included in the record as Paper 30 (“Tr.”). Petitioner
`relies on a declaration by Dr. Patrick D. McDaniel (Ex. 1002, “McDaniel
`Decl.”); Patent Owner relies on a declaration of Dr. George T. Ligler
`(Ex. 2002, “Ligler Decl.”). Both experts were deposed, and the deposition
`transcripts were made of record. See Ex. 2004 (“McDaniel Tr.”); Ex. 1046
`(“Ligler Tr.”). Patent Owner filed evidentiary objections (Papers 11 and
`21), but no motion to exclude.
`We have jurisdiction under 35 U.S.C. § 6. Petitioner bears the burden
`of proving unpatentability of the challenged claims, and the burden of
`persuasion never shifts to Patent Owner. Dynamic Drinkware, LLC v. Nat’l
`Graphics, Inc., 800 F.3d 1375, 1378 (Fed. Cir. 2015). To prevail, Petitioner
`must prove unpatentability by a preponderance of the evidence. See
`35 U.S.C. § 316(e); 37 C.F.R. § 42.1(d).
`This Final Written Decision is issued pursuant to 35 U.S.C. § 318(a)
`and 37 C.F.R. § 42.73. On this record, we determine, for the reasons
`detailed below, that Petitioner has shown by a preponderance of the
`evidence that claims 1, 13, 76, 78, 81, 83–85, 87–95, 98, 100, 104, 108, 113,
`137–39, and 142–44 of the ’868 patent are unpatentable, but has not shown
`that claims 77, 79, 80, 82, 86, and 112 are unpatentable.
`
`3
`
`

`

`IPR2017-01619
`Patent 8,489,868 B2
`
`B.
`
`Related Proceedings
`
`The ’868 patent was at issue in BlackBerry Ltd. v. BLU Products, Inc.,
`No. 1-16-cv-23535 (S.D. Fla.). Pet. 1. According to PACER, the case was
`dismissed on August 15, 2017.
`Petitioner concurrently filed another petition, IPR2017-01620, for
`inter partes review of the ’868 patent based on different prior art. Pet. 1.
`The 1620 petition does not challenge claims 87, 108, 138, 143, and 144.
`Patent Owner is presently prosecuting a continuation of the
`’868 patent, U.S. Serial No. 13/413,173.
`
`C.
`
`The ’868 Patent
`
`The ʼ868 patent describes “a code signing system and method” said to
`be “particularly well suited for JavaTM applications for mobile communication
`devices, such as Personal Digital Assistants, cellular telephones, and wireless
`two-way communication devices.” Ex. 1001, 1:20–24.
`The patent explains that “[i]n a typical software code signing scheme,
`a digital signature is attached to a software application that identifies the
`software developer” and “[o]nce the software is downloaded by a user, the
`user typically must use his or her judgment to determine whether or not the
`software application is reliable, based solely on his or her knowledge of the
`software developer’s reputation.” Id. at 1:30–36. The patent identifies two
`drawbacks to this prior art scheme. First, it “does not ensure that a software
`application written by a third party for a mobile device will properly interact
`with the device’s native applications and other resources.” Id. at 1:37–43.
`Second, “[b]ecause typical code signing protocols are not secure and rely
`solely on the judgment of the user, there is a serious risk that destructive . . .
`
`4
`
`

`

`IPR2017-01619
`Patent 8,489,868 B2
`
`software applications may be downloaded and installed onto a mobile
`device.” Id.
`The solution described in the ’868 patent is “[a] code signing system
`[that] operates in conjunction with a software application having a digital
`signature.” Id. at 1:54–56. An application programming interface (“API”)
`is “configured to link the software application with [an] application
`platform” and “[a] virtual machine verifies the authenticity of the digital
`signature in order to control access to the API by the software application.”
`Id. at 1:58–61.
`The main embodiment of the ’868 patent is described with reference
`to Figure 1:
`
`
`Figure 1 represents “a code signing protocol according
`to one embodiment of the invention.” Ex. 1001, 2:54–55.
`
`5
`
`

`

`IPR2017-01619
`Patent 8,489,868 B2
`
`As illustrated, “[a]n application developer 12 creates a software
`application 14 (application Y) for a mobile device that requires access to one
`or more sensitive APIs on the mobile device.” Id. at 3:9–12. Then,
`“[s]oftware application Y 14 is sent from the application developer 12 to the
`code signing authority 16.” Id. at 4:24–26. “If the code signing authority 16
`determines that software application Y 14 may access the sensitive API and
`therefore should be signed, then a signature . . . for the software application
`Y 14 is generated by the code signing authority 16 and appended to the
`software application Y 14.” Id. at 4:36–40. “The signed software
`application Y 22 may then be sent to a mobile device 28 or downloaded by
`the mobile device 28 over a wireless network 24” and, “[o]nce the signed
`software application Y 22 is loaded on the mobile device 28, each digital
`signature is preferably verified with a public signature key 20 before the
`software application Y 14 is granted access to a sensitive API library.” Id. at
`4:56–58, 4:66–5:3. “When the signatures are verified, the software
`application Y 14 can be executed on the device and access any APIs for
`which corresponding signatures have been verified.” Id. at 5:9–11.
`The ’868 patent also describes a method for “network operators” to
`“maintain control over which software applications are activated on mobile
`devices.” Id. at 1:44–46. “In this multiple-signature scenario, all APIs are
`restricted and locked until a ‘global’ signature is verified for a software
`application.” Id. at 4:1–3. For example, corporate mobile devices may “be
`configured to require verification of at least a global signature before a
`software application can be executed,” and “[a]ccess to sensitive device
`APIs and libraries . . . could then be further restricted, dependent upon
`verification of respective corresponding digital signatures.” Id. at 4:7–12.
`
`6
`
`

`

`IPR2017-01619
`Patent 8,489,868 B2
`
`Independent claims 1 and 76 of the ’868 patent, which exemplify the
`subject matter of the challenged claims, are the only independent claims
`challenged and are reproduced below:
`1. A mobile device containing software instructions
`which when executed on the mobile device cause the mobile
`device to perform operations for controlling access to an
`application platform of the mobile device, the operations
`comprising:
`storing a plurality of application programming interfaces
`(APIs) at the mobile device, wherein at least one API comprises
`a sensitive API to which access is restricted;
`receiving, at the mobile device, an indication that a
`software application on the mobile device is requesting access
`to the sensitive API stored at the mobile device;
`determining, at the mobile device, whether the software
`application is signed, wherein a signed software application
`includes a digital signature generated using a private key of a
`private key-public key pair, wherein the private key is not
`accessible to the mobile device;
`the mobile device using a public key of the private key
`public key pair to verify the digital signature of the software
`application; and
`based upon verifying the digital signature at the mobile
`device, the mobile device allowing the software application
`access to the sensitive API.
`Ex. 1001, 14:42–62.
`76. A method for controlling access to an application
`platform of a mobile device, comprising:
`storing a plurality of application programming interfaces
`(APIs) at the mobile device, wherein at least one API comprises
`a sensitive API to which access is restricted;
`receiving, at the mobile device, an indication that a
`software application on the mobile device is requesting access
`to the sensitive API stored at the mobile device;
`
`7
`
`

`

`IPR2017-01619
`Patent 8,489,868 B2
`
`determining, at the mobile device, whether the software
`application is signed, wherein a signed software application
`includes a digital signature generated using a private key of a
`private key-public key pair, wherein the private key is not
`accessible to the mobile device;
`mobile device using a public key of the private
`key-public key pair to verify of [sic] the digital signature of the
`software application; and
`based upon verifying the digital signature at the mobile
`device, the mobile device allowing the software application
`access to the sensitive API.
`Id. at 20:4–22.
`
`II. ANALYSIS
`
`A.
`
`Level of Skill in the Art
`
`The level of skill in the art is a factual determination that informs the
`claim construction analysis and helps guarantee objectivity in an
`obviousness analysis. See Al-Site Corp. v. VSI Int’l Inc., 174 F.3d 1308,
`1323 (Fed. Cir. 1999) (citing Graham v. John Deere Co., 383 U.S. 1, 17–18
`(1966); Teva Pharm. USA, Inc. v. Sandoz, Inc., 135 S. Ct. 831, 841 (2015)
`(explaining that claim construction seeks the meaning “a skilled artisan
`would ascribe” to the term “in the context of the specific patent claim”).
`Petitioner asserts that a person of ordinary skill in the art at the time of
`the alleged invention “would have had at least a Bachelor’s degree in
`computer science or the equivalent, and two years of work experience in the
`relevant field, e.g., secure systems, including security protocols for software
`applications” and that “[m]ore education can substitute for practical
`experience and vice versa.” Pet. 6. Patent Owner asserts “[o]ne of ordinary
`skill [] in the field . . . would have had (1) at least a bachelor’s degree in
`computer science, or the equivalent, and (2) at least two years of experience
`
`8
`
`

`

`IPR2017-01619
`Patent 8,489,868 B2
`
`in secure systems, including security protocols for software applications.”
`PO Resp. 5.
`The parties’ proposals are similar and neither party argues that it
`makes a difference which one we choose. We determine that the selection
`of one proposal over the other does not affect our analysis, but adopt Patent
`Owner’s formulation for purposes of this Decision.
`
`B.
`
`Claim Construction
`
`In inter partes reviews filed before November 13, 2018, the Board
`construes claims in an unexpired patent according to their broadest
`reasonable construction in light of the specification of the patent in which
`they appear. See Cuozzo Speed Techs., LLC v. Lee, 136 S. Ct. 2131, 2144–
`46 (2016); Changes to the Claim Construction Standard for Interpreting
`Claims in Trial Proceedings Before the Patent Trial and Appeal Board,
`83 Fed. Reg. 51,340 (Oct. 11, 2018). The broadest reasonable construction
`is the “ordinary and customary meaning” to a person of ordinary skill in the
`art at the time of invention. See In re Translogic Tech., Inc., 504 F.3d 1249,
`1257 (Fed. Cir. 2007); Phillips v. AWH Corp., 415 F.3d 1303, 1312–14
`(Fed. Cir. 2005) (en banc). “[T]he person of ordinary skill in the art is
`deemed to read the claim term not only in the context of the particular claim
`in which the disputed term appears, but in the context of the entire patent,
`including the specification.” Phillips, 415 F.3d at 1313. “[T]he claims
`themselves provide substantial guidance as to the meaning of particular
`claim terms,” id. at 1314, and “[w]hile we read claims in view of the
`specification, of which they are a part, we do not read limitations from the
`embodiments in the specification into the claims,” Hill-Rom Servs., Inc. v.
`Stryker Corp., 755 F.3d 1367, 1371 (Fed. Cir. 2014). We may “depart from
`
`9
`
`

`

`IPR2017-01619
`Patent 8,489,868 B2
`
`the plain and ordinary meaning of claim terms based on the specification in
`only two instances: lexicography and disavowal.” Id.
`
`“signed software application”
`1.
`All challenged claims include a “signed software application.” Patent
`Owner argues “a POSA would understand a signed software application to
`be a software application that is signed, i.e., the signature is of the software
`application or a unique transformation of the software application, such as a
`hash or an abridging function.” PO Resp. 14–15. Specifically, Patent
`Owner argues [A] “[t]he claims expressly require the software application be
`digitally signed” (id. 7–8), [B] “[e]very example of generating a signed
`message or a signed software application in the ’868 patent involves signing
`the information to be signed or a unique transformation of that information,
`such as a hash or abridged version” (id. at 8–11), [C] “[t]he extrinsic record
`and the testimony of Petitioner’s expert, Dr. McDaniel, further confirm
`Patent Owner’s construction” (id. at 11–13), and [D] “Patent Owner’s
`construction is further confirmed by Petitioner’s prior art” (id. at 13–14).
`Petitioner replies that “while the signed information may need to be
`associated with the application, the plain and ordinary meaning of the claims
`does not require signing the application code itself” and “[t]his
`understanding of the claims is confirmed by the specification of the
`’868 patent.” Reply 2. Petitioner further argues that Patent Owner’s
`arguments based on Dr. McDaniel’s testimony are “misplaced,” and that the
`prior art cited by Patent Owner is not contrary to Petitioner’s position. Id. at
`2–3.
`
`We begin the claim construction inquiry “with the actual words of the
`claim.” Homeland Housewares, LLC v. Whirlpool Corp., 865 F.3d 1372,
`
`10
`
`

`

`IPR2017-01619
`Patent 8,489,868 B2
`
`1375 (Fed. Cir. 2017). Here, claim 1 recites “determining . . . whether the
`software application is signed” where “a signed software application
`includes a digital signature generated using a private key of a private
`key-public key pair, wherein the private key is not accessible to the mobile
`device.” The claim language thus neither requires nor suggests that the
`signature is “of the software application or a unique transformation of the
`software application, such as a hash or an abridging function.” Instead, to
`the extent other language in the claim sheds light on the issue, it indicates
`that “a signed software application” is simply an application that “includes a
`digital signature generated using a private key.” We thus conclude that the
`actual words of the claim do not support Patent Owner’s construction.
`We next look to the rest of the intrinsic record, which in this case is
`the remainder of the specification, and then to “extrinsic evidence [if]
`appropriate.” Phillips, 415 F.3d at 1314.
`The specification describes the generation of the signed software
`application as follows:
`If the code signing authority 16 determines that software
`application Y 14 may access the sensitive API and therefore
`should be signed, then a signature (not shown) for the software
`application Y 14 is generated by the code signing authority 16
`and appended to the software application Y 14. The signed
`software application Y 22, comprising the software application
`Y 14 and the digital signature, is then returned to the
`application developer 12. The digital signature is preferably a
`tag that is generated using a private signature key 18 maintained
`solely by the code signing authority 16. For example,
`according to one signature scheme, a hash of the software
`application Y 14 may be generated, using a hashing algorithm
`such as the Secure Hash Algorithm SHA1, and then used with
`the private signature key 18 to create the digital signature. In
`some signature schemes, the private signature key is used to
`
`11
`
`

`

`IPR2017-01619
`Patent 8,489,868 B2
`
`encrypt a hash of information to be signed, such as software
`application Y 14, whereas in other schemes, the private key
`may be used in other ways to generate a signature from the
`information to be signed or a transformed version of the
`information.
`Ex. 1001, 4:36–55. We do not agree with Patent Owner that its proposed
`construction is mandated by this portion of the disclosure. The passage
`states that “a signature . . . for the software application . . . is generated by
`the code signing authority,” without specifying that the signature must be
`“of the software application or a unique transformation of the software
`application,” or anything else to that effect. The signature is described as
`“preferably a tag that is generated using a private signature key . . .
`maintained solely by the code signing authority,” again without any
`requirement that the tag be generated from the “software application or a
`unique transformation of the software application.” We consider this portion
`of the specification to describe a broadest embodiment that does not require
`generation of the signature from the application itself.
`The Specification goes on to explain that “for example, according to
`one signature scheme” the application may be hashed and the hash may be
`used to create the digital signature. Ex. 1001, 4:45–50 (emphasis added). It
`further states that “[i]n some signature schemes,” the private key is used to
`encrypt a hash of information to be signed, “whereas in other schemes, the
`private key may be used in other ways to generate a signature from the
`information to be signed or a transformed version of the information.” Id. at
`4:50–55. We view this description as providing examples of how the signed
`application may be generated, not as evidence that the signature must be
`generated from the application itself. We determine that these examples, in
`the absence of a clear disavowal of other embodiments, do not limit the
`
`12
`
`

`

`IPR2017-01619
`Patent 8,489,868 B2
`
`claims. See Info-Hold, Inc. v. Applied Media Techs. Corp., 783 F.3d 1262,
`1267 (Fed. Cir. 2015) (“[T]he scope of the invention is properly limited to
`the preferred embodiment if the patentee uses words that manifest a clear
`intention to restrict the scope of the claims to that embodiment.”). This is
`particularly true given that the key may be “used to encrypt a hash of
`information to be signed, such as software application Y 14” (Ex. 1001,
`4:51–52, emphasis added), which indicates that the signature may be
`generated by applying the key to something other than the software
`application or a hash of the software application. Once the signature is
`generated, it is appended to the application, resulting in “a signed software
`application.”
`The written description, we conclude, does not provide a basis for
`limiting the claims in the manner urged by Patent Owner.
`We also are not persuaded by Patent Owner’s references to
`Dr. McDaniel’s deposition testimony and declaration (see PO Resp. 11–13;
`Ex. 2002, ¶¶ 51–58), because we do not find statements about digital
`signatures in general to be sufficient to read limitations into the claims of the
`’868 patent. Moreover, that testimony is not inconsistent with our result,
`which allows for the signature to be based on “the thing you’re signing.”
`The written description described above is broad enough to include creating
`a signature using any information (so the signature would be based on “the
`thing being signed,” as described by Dr. McDaniel), and then creating a
`“signed software application” by appending that signature to the application.
`For similar reasons, we are unpersuaded by Patent Owner’s arguments
`regarding the prior art (see PO Resp. 13–14).
`
`13
`
`

`

`IPR2017-01619
`Patent 8,489,868 B2
`
`As explained above, the ’868 patent describes “a signed application”
`as an application to which a signature has been appended, but does not
`require that the signature have been generated from the application. Even if
`one of skill in the art would have understood that a digital signature must be
`based on “the thing you’re signing,” we see nothing in the ’868 patent
`requiring that the “thing” be the application itself. In other words, and to be
`clear, we find the disclosure to support claims that encompass creating a
`signature from something that is not the application itself and then
`appending that signature to the application.
`Patent Owner argues the system could be defeated if the signature was
`not of the entire application. See PO Resp. 13. This seems to be a valid
`technical point but, even if true, it would be insufficient to mandate Patent
`Owner’s construction because the claims do not require that the system be
`perfectly secure. The applicant could have claimed a more secure system by
`narrowing the claims to the embodiment in which the signature is generated
`from the application or a hash of the application, but elected to pursue
`broader claims instead.
`Considering the intrinsic and extrinsic evidence as a whole, we find
`they do not support Patent Owner’s proposed construction of “signed
`software application,” as requiring that the signature is of the software
`application or a unique transformation of the software application.
`
`2.
`
`“determining, at the mobile device, whether the software
`application is signed, wherein a signed software application
`includes a digital signature generated using a private key of a
`private key-public key pair”
`All challenged claims include the above phrase, which Petitioner
`argues should be construed to mean “determining, at the mobile device,
`
`14
`
`

`

`IPR2017-01619
`Patent 8,489,868 B2
`
`whether the software application includes a digital signature generated using
`a private key of a private key-public key pair corresponding to an entity with
`an interest in protecting access to the sensitive API, such as a mobile device
`manufacturer or other entity that classified the API as sensitive, or from a
`code signing authority acting on behalf of the manufacturer.” Pet. 7–8
`(emphasis added). Petitioner asks us to find that the claims require the key
`pair to be generated by the mobile device manufacturer or another entity that
`classified the API as sensitive. Petitioner notes that in a prior district court
`case, Patent Owner interpreted this phrase to include a key pair generated by
`an application developer. See Pet. 14 (citing Ex. 1010, 20–21). Petitioner
`goes on to assert, however, that the “petition demonstrates how the prior art
`discloses the challenged claims under both Petitioner’s and PO’s
`interpretations.” Id. Patent Owner does not address this issue in this
`proceeding.
`As in the institution decision, because we need not interpret this claim
`language to reach our decision, we decline to do so. See Vivid Techs., Inc. v.
`Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999) (explaining that
`terms are construed to resolve a “controversy, and only to the extent
`necessary to resolve the controversy”).
`
`“sensitive API”/“non-sensitive API”
`3.
`Patent Owner argues “[t]he broadest reasonable interpretation of a
`‘sensitive API’ is an API classified as implicating a security concern” and
`“[t]he broadest reasonable interpretation of a ‘non-sensitive API’ is likewise
`an API that is not classified as implicating a security concern.” PO Resp.
`16. This is so, according to Patent Owner, because the ’868 patent “uses the
`phrase ‘sensitive API’ to refer to a specific classification of API related to
`
`15
`
`

`

`IPR2017-01619
`Patent 8,489,868 B2
`
`the security concerns implicated by that API, in that it may be affected by a
`virus or malicious code in a device software application.” Id. at 17.
`Petitioner responds that Patent Owner’s position is “unsupported by
`the disclosure of the ’868 patent” and that the claims “do not mention
`security” but, instead, “use these terms merely to distinguish between APIs
`based on access restrictions.” Reply 5–6. Petitioner further argues “PO’s
`construction of ‘sensitive API’ also fails because neither the specification
`nor the prosecution history of the ’868 patent even mentions the phrase
`‘security concern,’” Patent Owner and its expert “neglect to explain what
`this phrase means,” and “it is also unclear what it means to ‘implicat[e]’ a
`security concern.” Id. at 6.
`We do not agree with Patent Owner that “sensitive APIs” should be
`limited to APIs classified as implicating a security concern and, instead, we
`construe this term to mean “an API to which access is restricted.” (See Inst.
`Dec. 13.9) The claims identify “a plurality of application programming
`interfaces (APIs),” and then identify a subset of those APIs as “sensitive
`APIs.” The subset is those APIs to which access is restricted by use of the
`private-public key scheme recited in the claims, as opposed to other APIs to
`which application access is not restricted by that scheme.
`
`
`9 Having further considered the issue, we omit from this construction “on an
`application-by-application basis,” which we included in the institution
`decision. That was done in response to Patent Owner’s argument
`concerning the patent’s “multiple-signature scenario” (see Prelim. Resp. 8–
`9), but we now conclude the language is not needed. The patent’s
`description of using one global signature to restrict any API access and a
`second to allow access to only sensitive APIs does not create any potential
`inconsistency because the independent claims are not directed to the two
`signature scheme––they recite only one signature.
`16
`
`

`

`IPR2017-01619
`Patent 8,489,868 B2
`
`Patent Owner does not argue that “sensitive API” is a known term of
`art (see Tr. 74:10) and, as Petitioner observes, the term “security concern”
`does not appear in the patent or its file history. In an effort to support its
`construction, Patent Owner points to 3:46–62 of the ’868 patent, which
`begins “[p]referably, any API may be classified as sensitive by a mobile
`device manufacturer, or possibly by an API author, a wireless network
`operator, a device owner or operator, or some other entity that may be
`affected by a virus or malicious code in a device software application.” We
`read this language as indicating that “any API” may be classified as
`sensitive, not just APIs that “implicate security concerns.” We find this to
`describe an embodiment in which APIs that do not “implicate security
`concerns” may be “sensitive APIs.” It is true that the patent states “[f]or
`instance, a mobile device manufacturer may classify as sensitive those APIs
`that interface with cryptographic routines, wireless communication
`functions, or proprietary data models such as address book or calendar
`entries,” but we read that additional language as exemplary (“for instance”),
`not limiting. Given the lack of any clear indication in the ’868 patent of an
`intent to limit “sensitive APIs” to only APIs that implicate a “security
`concern,” we decline to do so. See Info-Hold, 783 F.3d at 1267.
` The ’868 patent, which does not even use the phrase “security
`concern,” offers no guidance on what the term means, or how one would
`determine whether or not an API “implicate[s] security concerns.” And
`Patent Owner is also unable to adequately explain it. For example, at the
`hearing, when asked whether “preventing someone who has not paid a
`license to access APIs” would be a “security concern,” Patent Owner
`answered in the negative, because “[i]t would be a business concern.” Tr.
`
`17
`
`

`

`IPR2017-01619
`Patent 8,489,868 B2
`
`72:21–73:3. But we fail to see why preventing someone from avoiding the
`payment of license fees does not “implicate a security concern.” The
`construction we adopt, on the other hand, provides a clear distinction: an
`API to which application access is restricted using the claimed scheme is a
`“sensitive API,” and an API to which application access is not restricted
`using that scheme is not a “sensitive API.”
`As discussed above, the ’868 patent is concerned with both
`“ensur[ing] that a software application written by a third party for a mobile
`device will properly interact with the device’s native applications and other
`resources” and the “serious risk that destructive . . . software applications
`may be downloaded and installed.” Ex. 1001, 1:37–43. The specification
`also describes how the signing authority may determine whether to sign a
`developer’s key based on “several criteria,” including “whether or not the
`developer has a contractual obligation or has entered into some other type of
`business arrangement with a device manufacturer” (Ex. 1001, 10:11–23),
`indicating that a valid signature may be provided for API access based on
`business, as opposed to security, considerations. These disclosures support
`the conclusion that a “sensitive API” is simply one to which access is
`restricted––including because a developer has not contracted to access a
`particular API, because it has not proven that the application properly uses
`the API, or for any other reason––rather than only because access to the API
`presents a “security concern.”
`We are not persuaded by Patent Owner’s argument regarding “the role
`of trust in granting access to sensitive APIs.” PO Resp. 18. The ’868 patent
`describes how the signing authority may consult a database or other records
`to determine whether to “trust” the application developer. But the
`
`18
`
`

`

`IPR2017-01619
`Patent 8,489,868 B2
`
`determination of whether to trust, and therefore grant access, is made
`according to several criteria including, as noted above, “whether or not the
`developer has a contractual obligation or has entered into some other type of
`business arrangement with a device manufacturer.” Ex. 1001, 10:19–22.
`Again, this suggests that access to the APIs may be allowed for various
`reasons, including because the developer has contracted for the right to use
`the APIs, not only because the application having access to the API
`implicates a “security concern.”
`As in the institution decision, we find that the claims were drafted
`using the term “sensitive APIs” as a label, or shorthand, for the subset of
`APIs to which access is restricted using the scheme described in the
`independent claims, such that when the claims subsequently refer to the
`subset they use the shorthand “sensitive API,” rather than the entire phrase
`“sensitive API to which access is restricted.”
`Patent Owner disputes the notion that the term functions as a label by
`citing the portion of the patent concerning the additional, global signature,
`and arguing “the ’868 patent describes access restrictions for ‘no