`
` Paper 9
`Trials@uspto.gov
`571-272-7822 Entered: December 22, 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.
`
`
`
`
`DECISION
`Instituting Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`
`
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`I. INTRODUCTION
`Google LLC (“Petitioner”) filed a Petition for inter partes review of
`claims 1, 13, 76–95, 98, 100, 104, 108, 112, 113, 137–39, and 142–44 of
`U.S. Patent No. 8,489,868 B2 (Ex. 1001, “the ’868 patent”). Paper 1
`(“Pet.”). BlackBerry Ltd. (“Patent Owner”) filed a Preliminary Response.
`Paper 8 (“Prelim. Resp.”).
`Institution of an inter partes review is authorized by statute when “the
`information presented in the petition . . . and any response . . . shows that
`there is a reasonable likelihood that the petitioner would prevail with respect
`to at least 1 of the claims challenged in the petition.” 35 U.S.C. § 314(a);
`see 37 C.F.R. § 42.108.
`Upon consideration of the Petition, we conclude there is a reasonable
`likelihood that Petitioner would prevail in establishing the unpatentability of
`all of challenged claims 1, 13, 76–95, 98, 100, 104, 108, 112, 113, 137–39,
`and 142–44 of the ’868 patent in this proceeding.
`
`A. Related Matters
`According to Petitioner, the ’868 patent is at issue in BlackBerry Ltd.
`v. BLU Products, Inc., No. 1-16-cv-23535 (S.D. Fla.). Pet. 1.
`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, not identified by either party.
`
`
`2
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`B. The ’868 Patent
`The ʼ868 patent is directed to “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, that 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” and that
`“[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 . . . software
`applications may be downloaded and installed onto a mobile device.” Id. at
`1:37–43.
`The solution to these problems 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. “The API[1] is
`configured to link the software application with [an] application platform”
`and “[a]virtual machine verifies the authenticity of the digital signature in
`
`
`1 “API” stands for “application programming interface.” Ex. 1001, 1:57.
`3
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`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.
`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
`
`4
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`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.
`
`C. Illustrative Claims
`Independent claims 1 and 76 are reproduced below, illustrating the
`claimed subject matter:
`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
`
`5
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`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;
`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 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.
`
`
`
`
`6
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`D. Asserted Grounds of Unpatentability
`Petitioner asserts claims 1, 13, 76–95, 98, 100, 104, 108, 112, 113,
`137–39, and 142–44 are unpatentable on the following grounds (Pet. 2–3):
`
`References
`
`Garst2 and Gong3
`
`Garst, Gong, and Davis4
`Garst, Gong, and Chang5
`Garst, Gong, and Sibert6
`Garst, Gong, and Wong-Insley7
`Garst, Gong, and Haddock8
`
`Basis
`
`§ 103
`
`§ 103
`§ 103
`§ 103
`§ 103
`§ 103
`
`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
`
`
`2 U.S. Patent No. 6,188,995 B1, Feb. 13, 2001 (Ex. 1012).
`3 Li Gong, Inside JavaTM 2 Platform Security (1999) (Ex. 1016).
`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).
`7
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`II. DISCUSSION
`A. Level of Skill in the Art
`The level of skill in the art is a factual determination that provides a
`primary guarantee of 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)). The level of skill in the art
`also informs the claim construction and anticipation analyses. See 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”); Wasica Fin. GmbH
`v. Cont’l Auto. Sys., Inc., 853 F.3d 1272, 1284 (Fed. Cir. 2017)
`(“Anticipation is an inquiry viewed from the perspective of one skilled in the
`art.”).
`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. As Patent Owner does not dispute
`Petitioner’s characterization, we adopt it for purposes of this analysis.
`B. Claim Construction
`In inter partes review, 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. 37 C.F.R. § 42.100(b).
`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
`
`8
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`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.” Id. at 1313.
`“[T]he claims themselves provide substantial guidance as to the meaning of
`particular claim terms,” Phillips, 415 F.3d 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).
`Petitioner provides a proposed construction for one claim term and
`asserts that the remaining terms should be interpreted in accordance with
`their plain and ordinary meaning. Pet. 7. Patent Owner provides a proposed
`construction for two claim terms, different from the one identified by
`Petitioner, and asserts that the term proposed by Petitioner need not be
`construed. Prelim. Resp. 6–14. We address the terms in the order raised.
`1. “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”
`Petitioner invites us to construe the limitation above to mean
`“determining, at the mobile device, 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. In
`
`9
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`essence, Petitioner asks us to limit the claim by requiring that the key pair is
`generated by the mobile device manufacturer or another entity that classified
`the API as sensitive. 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,” where Patent Owner’s interpretation
`would include a key pair generated by an application developer. See Pet. 14,
`citing Ex. 1001, 20–21.
`Because we need not interpret this claim language in reaching our
`institution decision, we decline to do so.9
`2. “sensitive API”
`Patent Owner requests that we construe “sensitive API” to be an API
`that “implicates greater security concerns relative to a non-sensitive API.”
`Prelim. Resp. 7. Such a construction is appropriate, according to Patent
`Owner, because “the ’868 patent uses the word ‘sensitive’ to distinguish
`certain APIs from non-sensitive APIs that do not implicate the same amount
`of security concerns.” Id. at 6.
`We do not agree that “sensitive APIs” are appropriately limited to
`API’s that implicate greater security concerns relative to a non-sensitive
`API. As discussed above, the ’868 patent is concerned about 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.
`
`
`9 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”).
`10
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`We note that the ’868 patent 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. This supports a conclusion that a “sensitive API” is simply
`one to which access is restricted, as it indicates that a developer may not be
`“trusted” because it has not contracted to access a particular API, or because
`it has not proven that the application properly uses the API, rather than
`because access to the API presents a security concern.
`Viewing the disclosure as a whole, we find the portions of the patent
`cited by Patent Owner insufficient to require that the “sensitive” designation
`be limited to APIs that implicate high level security concerns. The claims
`identify “a plurality of application programming interfaces (APIs),” and then
`identify a subset of those API’s as “sensitive APIs.” The subset is those
`APIs to which access is restricted (including by use of the private-public key
`scheme recited in the claim), as opposed to other APIs to which application
`access is not restricted. Consistent with the use of the term in the claims, for
`purposes of this decision, we construe “sensitive API” to be “an API to
`which access is restricted on an application-by-application basis.” We
`include the language “on an application-by-application basis” to avoid
`confusion with the optional global restriction also described in the patent.
`In addition to finding Patent Owner’s proposed construction
`improperly narrow, we find it problematic due to its circular nature, as it
`defines “sensitive API” only by comparison to what is not a “sensitive API.”
`
`11
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`Further, it is unclear how one would determine, and then compare or rank,
`the extent to which an API “implicates . . . security concerns.” The ’868
`patent includes no guidance. Our construction, on the other hand, in
`addition to being commensurate with the full scope of the disclosure,
`provides a clear distinction: an API to which application access is restricted
`is a “sensitive API,” and an API to which application access is not restricted
`is not a “sensitive API.”
`Finally, we do not agree with Patent Owner that a construction such as
`ours would read “sensitive” out of the claims. See Prelim. Resp. 25.
`Instead, we find that the claim was drafted using the term “sensitive APIs”
`as a label for the subset of APIs to which access is restricted for certain
`applications, 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.” Because the term is used as a label, it has
`a purpose in the claim even without adding additional structural or
`functional limitation.
`3. “[a] plurality of [APIs] . . . , wherein
`at least one API comprises a sensitive API
`to which access is restricted”
`Patent Owner also requests that we find the claims to require that
`“‘sensitive API[s]’ have greater ‘access [] restrict[ions]’ relative to those
`‘plurality of APIs’ that may be non-sensitive.” Prelim. Resp. 9–10. We do
`not agree that this language requires any additional construction.
`The claim reads “at least one API comprises a sensitive API to which
`access is restricted.” We agree that this contemplates restricting access to
`sensitive APIs, such as by use of the private-public key scheme. See, e.g.,
`Ex. 1001, 14:49–51 (“receiving, at the mobile device, an indication that a
`
`12
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`software application on the mobile device is requesting access to the
`sensitive API”) & 60–62 (“based upon verifying the digital signature at the
`mobile device, the mobile device allowing the software application access to
`the sensitive API”). We see no reason, however, to add additional language
`characterizing “relative” restrictions associated with sensitive and non–
`sensitive APIs. The extent to which APIs may be subject to other
`restrictions (e.g., by requiring a global signature before any application can
`be executed) is beyond the scope of the claim.
`Our preliminary conclusions on the construction of the terms
`identified by the parties are summarized below.
`
`Term
`“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”
`
`“sensitive API”
`
`Preliminary Construction
`
`Not construed.
`
`“An API to which access is
`restricted on an application-by-
`application basis.”
`
`“[a] plurality of [APIs] . . . ,
`wherein at least one API comprises
`a sensitive API to which access is
`restricted”
`
`Not construed.
`
`C. Obviousness
`A patent claim is unpatentable under 35 U.S.C. § 103(a) if the
`differences between the claimed subject matter and the prior art are such that
`the subject matter, as a whole, would have been obvious at the time the
`
`13
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`invention was made to a person having ordinary skill in the art to which said
`subject matter pertains. KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 406
`(2007). The question of obviousness is resolved on the basis of underlying
`factual determinations including: (1) the scope and content of the prior art;
`(2) any differences between the claimed subject matter and the prior art; (3)
`the level of ordinary skill in the art; and (4) objective evidence of
`nonobviousness. Graham, 383 U.S. at 17–18.10
`Petitioner contends claims 1, 13, 76, 78, 81, 84, 85, 87, 88, 90–93, 95,
`98, 100, 104, 108, 112, 113, 137–39, and 142–44 are unpatentable as
`obvious over Garst and Gong. Relying on the testimony of Dr. Patrick D.
`McDaniel, Petitioner endeavors to explain how Garst and Gong teach or
`suggest all of the limitations of these claims. See Pet. 14–51; see Ex. 1002.
`We summarize Garst and Gong, and then discuss the sufficiency of
`Petitioner’s obviousness analysis in the context of representative
`independent claims 1 and 76.
`
`1. Garst
`Garst describes “a method and apparatus for enforcing software
`licenses for resource libraries such as an application program interface
`(API), a toolkit, a framework, a runtime library, a dynamic link library
`(DLL), an applet . . . , or any other reusable resource.” Ex. 1012, Abstract.
`The scheme includes a “license key” that “constitutes the resource library
`vendor’s digital signature of the license text string.” Id. at 3:27–29. “The
`resource library has a checking [routine] for verifying the resource library
`
`10 As neither party offers objective evidence of non-obviousness or argues
`any secondary considerations, our analysis is based upon the first three of
`the four Graham factors.
`
`14
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`vendor’s digital signature” and “[t]he resource library is unlocked and made
`available for use with the requesting program only if the license text string is
`verified as authentic by the resource library.” Id. at 3:29–33.
`2. Gong
`Gong is a book concerning Java security, cited by Petitioner in
`support of its assertion that “it was known in the art that Java technology
`was being deployed on mobile devices, including ‘PDAs’ and ‘cell
`phones.’” Pet. 17, citing Ex. 1016, at 23, 242.
`3. Application of Garst and Gong
`to Independent Claim 1
`For the reasons explained below, we conclude that Petitioner shows
`sufficiently, for purposes of institution, that the subject matter of claim 1
`would have been obvious to a person of ordinary skill in the art in view of
`Garst and Gong.
`(a) “[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”
`Garst describes “a method and apparatus for enforcing software
`licenses for resource libraries such as an application program interface
`(API), a toolkit, a framework, a runtime library, a dynamic link library
`(DLL).” Exhibit 1012, Abstract. It thus teaches software instructions for
`“controlling access to an application platform.” Garst does not describe use
`of the system on a mobile device. Gong, however, describes the use of Java
`security schemes on mobile devices and we agree with Petitioner that, at
`least on the record developed to date, it would have been obvious to
`implement Garst’s system on a mobile device. See Pet. 16–19.
`
`15
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`(b) “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”
`The software libraries for which Garst describes enforcing licenses are
`located on the device, which is a mobile device in the combination. See,
`e.g., Exhibit 1012, Abstract, Fig. 2, 1:37–40. We agree with Petitioner that
`such application libraries would include “APIs.” See Pet. 19. At least one
`of the application libraries, e.g., one for which a software license is being
`enforced, is “a sensitive API to which access is restricted” because it is one
`to which access is limited on an application-by-application basis.
`We are not persuaded by Patent Owner’s argument regarding “a
`sensitive API” because, for the reasons described above, we do not agree, at
`least for purposes of this decision, with Patent Owner’s proposed
`construction, and find that Garst does teach that limitation under our
`preliminary construction.
`(c) “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”
`Garst teaches receipt of an indication that an application is requesting
`access to the sensitive API. See, e.g., Ex. 1012, 6:47–49 (“[T]he process
`begins with a requesting program making a request to use the resource
`library at step 700.”).
`(d) “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”
`After the request to access the API, Garst’s method obtains the
`program’s license text and license key. See Exhibit 1012, 6:49–50. In at
`least one embodiment, the key “comprises a digital signature of the resource
`
`16
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`library vendor.” Id. at 5:23–25. Garst explains that the key (called
`“LicenseKeyString”) can be a digital signature of the text describing the
`license restrictions (the “LicenseAgreementString”) that is “prepared by
`providing the LicenseAgreementString and a private key of the API vendor
`to a digital signature process.” Id. at 9:38–40. The reference thus teaches
`that the “digital signature [is] generated using a private key of a private key-
`public key pair.” And, given the described used of the “private key,” we
`conclude that one of skill in the art would have understood the key to be
`private to the developer and, thus, not accessible on the mobile device. See
`Garst 5:41–43 (“The originator digitally signs the resulting message digest,
`for example by performing an algorithmic operation on the message digest
`using the originator’s private key.”).
`(e) “the mobile device using a public key of the
`private key-public key pair to verify the digital
`signature of the software application”
`Garst uses the public key of the pair to verify the digital signature of
`the application. See, e.g., Ex. 1012, 3:30–33 (“The resource library is
`unlocked and made available for use with the requesting program only if the
`license text string is verified as authentic by the resource library”).
`(f) “based upon verifying the digital signature at the
`mobile device, the mobile device allowing the software
`application access to the sensitive API”
`Garst allows the application to access the sensitive API based upon
`verifying the digital signature. See, e.g., Ex. 1012, Abstract (“Resource
`library functions are made available only to a program having an authentic
`and unaltered license text string.”).
`
`17
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`4. Application of Garst and Gong
`to Independent Claim 76
`Claim 76 is a method claim corresponding to the apparatus of claim 1.
`The bodies of claims 1 and 76 are identical. We conclude that Petitioner has
`made a sufficient showing of obviousness of claim 76 for the same reasons
`that the showing of obviousness of claim 1 is sufficient.
`5. Dependent Claims
`Petitioner sets forth a detailed explanation of its challenge to claims
`13, 78, 81, 84, 85, 87, 88, 90–93, 95, 98, 100, 104, 108, 112, 113, 137–39,
`and 142–44 based on the combination of Garst and Gong. See Pet. 30–51.
`We have reviewed Petitioner’s showing and determine that Petitioner has
`demonstrated a reasonable likelihood of prevailing in its challenge to these
`claims based on Garst and Gong, for the reasons identified in the Petition.
`Patent Owner does not offer a rebuttal of Petitioner’s obviousness challenge
`to these claims in its Preliminary Response.
`We have also reviewed Petitioner’s showing with respect to claims
`77, 79, 80, 82, 83, 86, 89, and 94, along with the additional supporting
`evidence, including Davis, Chang, Sibert, Wong-Insley, and Haddock. See
`Pet. 51–64. We have reviewed Petitioner’s showing and determine that
`there is a reasonable likelihood that Petitioner would prevail in establishing
`the unpatentability of those claims, for the reasons identified in the Petition.
`Patent Owner does not offer a rebuttal of Petitioner’s obviousness challenge
`to these claims in its Preliminary Response.
`D. Gong as Prior Art
`Patent Owner asserts that Petitioner has not shown Gong is prior art
`because there is insufficient evidence that the reference was publicly
`accessible. See Prelim. Resp. 16–22. We do not agree.
`
`18
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`A reference is publicly accessible if it “has been disseminated or
`otherwise made available to the extent that persons interested and ordinarily
`skilled in the subject matter or art, exercising reasonable diligence, can
`locate it.” In re Wyer, 655 F.2d 221, 226 (CCPA 1981) (citations omitted).
`If public accessibility is proved, “there is no requirement to show that
`particular members of the public actually received the information”
`disclosed in the reference. Constant v. Advanced Micro-Devices, Inc., 848
`F.2d 1560, 1568–69 (Fed. Cir. 1988). Public accessibility “is determined on
`a case-by-case basis, based on the ‘facts and circumstances surrounding the
`reference’s disclosure to members of the public.’” In re Lister, 583 F.3d
`1307, 1311 (Fed. Cir. 2009) (quoting In re Klopfenstein, 380 F.3d 1345,
`1350 (Fed. Cir. 2004)).
`In this instance, the reference, Gong, is a book that bears a 1999
`copyright date. Ex. 1016, iv. Petitioner offers evidence that the book was
`received at the North Carolina State University (“NCSU”) library and the
`Library of Congress. See Ex. 1033–1036. We recognize that the library
`evidence does not include a specific date that Gong was indexed or
`cataloged at either library. However, viewing the evidence as a whole, we
`find it sufficient to establish, at least for purposes of institution, that Gong
`was publicly available prior to September 20, 2000. We note, for example,
`that page v of Exhibit 1016, which is the NCSU copy of Gong, includes a
`series of date stamps indicating that the book was checked out, and thus
`presumably publicly available, prior to September of 2000.
`Regarding Patent Owner’s hearsay argument (Prelim. Resp. 23–24),
`we conclude that such evidentiary issues are properly addressed after
`institution, with objections under 37 C.F.R. § 42.64(b) and, if necessary, a
`
`19
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`motion to exclude under 37 C.F.R. § 42.64(c) pursuant to the Scheduling
`Order. See LKQ Corp. v. Clearlamp, LLC, IPR2013-00020, Paper 17, at 3–
`4 (PTAB March 5, 2013).
`
`
`III. CONCLUSION
`Petitioner demonstrates a reasonable likelihood of prevailing in
`showing the unpatentability of claims 1, 13, 76–95, 98, 100, 104, 108, 112,
`113, 137–39, and 142–44 of the ’868 patent in this proceeding.
`
`
`20
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`IV. ORDER
`In consideration of the foregoing, it is hereby:
`ORDERED that, pursuant to 35 U.S.C. § 314(a), an inter partes
`review is hereby instituted as to claims 1, 13, 76–95, 98, 100, 104, 108, 112,
`113, 137–39, and 142–44 of the ’868 patent on the following grounds of
`unpatentability:
`
`References
`
`Garst and Gong
`
`Garst, Gong, and Davis
`Garst, Gong, and Chang
`Garst, Gong, and Sibert
`Garst, Gong, and Wong-Insley
`Garst, Gong, and Haddock
`
`§ 103
`
`Basis 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
`
`§