`
` 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
`
`§
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
