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-01620
`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
`
`
`
`
`
`
`
`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-01620
`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-01620
`Patent 8,489,868 B2
`
`I. INTRODUCTION
`Google LLC (“Petitioner”) filed a Petition for inter partes review of
`claims 1, 13, 76–86, 88–95, 98, 100, 104, 112, 113, 137, 139, and 142 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–86, 88–95, 98, 100, 104, 112, 113, 137,
`139, and 142 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–01619, for
`inter partes review of the ’868 patent based on different prior art. Pet. 1.
`The 1619 petition includes the claims challenged in this petition, plus 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-01620
`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-01620
`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-01620
`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-01620
`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-01620
`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):
`
`Reference(s)
`
`Lin2
`
`Lin and Garst3
`Lin and Davis4
`Lin and Chang5
`Lin and Sibert6
`Lin and Wong-Insley7
`Lin and Haddock8
`Lin and Gong9
`
`Basis Challenged Claim(s)
`§ 102 1, 76, 78, 81, 84, 85, 90-92, 95,
`104, 113, 137, and 142
`§ 103 13, 88, and 98
`§ 103 77, 79, 80, and 82
`§ 103 83
`§ 103 86
`§ 103 89
`§ 103 94
`§ 103 93, 100, 112, 139
`
`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
`
`
`2 U.S. Patent No. 6,766,353 B1, July 20, 2004 (Ex. 1011).
`3 U.S. Patent No. 6,188,995 B1, Feb. 13, 2001 (Ex. 1012).
`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).
`9 Li Gong, Inside JavaTM 2 Platform Security (1999) (Ex. 1016).
`7
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`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
`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.
`
`8
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`“[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–13. 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. 8, emphasis added. In 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 all of the limitations of the
`challenged claims under [both Petitioner’s and] PO’s interpretation,” where
`
`9
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`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.10
`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.
`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
`
`
`10 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-01620
`Patent 8,489,868 B2
`
`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.”
`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
`
`11
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`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
`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–
`
`12
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`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. Anticipation
`A claim is anticipated when each and every element is found in a
`single prior art reference, arranged as recited in the claim. See Net
`MoneyIN, Inc. v. VeriSign, Inc., 545 F.3d 1359, 1369 (Fed. Cir. 2008). “A
`reference anticipates a claim if it discloses the claimed invention ‘such that a
`skilled artisan could take its teachings in combination with his own
`knowledge of the particular art and be in possession of the invention.’” In re
`Graves, 69 F.3d 1147, 1152 (Fed. Cir. 1995) (emphasis omitted) (quoting In
`re LeGrice, 301 F.2d 929, 936 (CCPA 1962)).
`
`13
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`Petitioner contends claims 1, 76, 78, 81, 84, 85, 90–92, 95, 104, 113,
`137, and 142 are unpatentable as anticipated by Lin. Relying on the
`testimony of Dr. Patrick D. McDaniel, Petitioner endeavors to explain how
`Lin discloses all of the claim limitations. See Pet. 15–36. We summarize
`Lin, and then discuss the sufficiency of Petitioner’s anticipation analysis in
`the context of representative independent claims 1 and 76.
`1. Lin
`Lin concerns a method for authenticating a Java archive for portable
`devices. Ex. 1011, Title. The method employs “a signed application
`descriptor file (ADF)” and “a developer descriptor file (DDF).” Id. at 2:23–
`24. The ADF is a file that “describes the portable application in terms of the
`computing resources it requires” and “is signed by the developer of the
`corresponding application using a certification authority.” Id. at 2:23–25;
`2:28–32. The DDF is “associated with a particular application software
`developer” and “specifies the general access control related information
`assigned to the developer.” Id. at 2:35–37. “For example, a DDF may
`restrict the kind of application libraries that applications developed by the
`developer can use, or the security domain to which the developer belongs.”
`Id. at 2:37–40. A signed application descriptor file is shown in Figure 3:
`
`
`“FIG. 3 shows a block diagram of a signed
`application descriptor file (ADF).” Ex. 1011, 1:65–67.
`
`14
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`The signed ADF 300 includes a JAR file 301, “containing the portable code
`to be installed on the client machine,” an “application descriptor file 302,” a
`“file hash 304 of the JAR file,” a “developer descriptor file (DDF) 306,” a
`“developer certificate 308,” “a time stamp 310,” and “a developer signature
`312.” Id. at 3:21–29.) “Upon receiving the signed ADF, the client device
`verifies the developer certificate with the code signing certificate authority’s
`public key (606).” Id. at 5:6–8.
`2. Application of Lin 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 is
`anticipated by Lin.
`(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”
`Lin describes “security and authentication of portable code for use by
`wireless or mobile devices” (Ex. 1011, 1:6–11), where the system may
`“restrict the kind of application libraries that applications developed by the
`developer can use” (id. at 2:39–40) on the mobile device.
`(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”
`As noted above, Lin restricts the kind of application libraries that
`applications can use on a mobile device. We agree with Petitioner that such
`application libraries would include “APIs.” See Pet. 18–20. 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.
`
`15
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`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 Lin 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”
`Lin teaches receipt of an indication that an application is requesting
`access to the sensitive API. See, e.g., Ex. 1011, 5:20–21 (“Upon receiving
`the application code, the client device compares it to the parameters in the
`signed ADF.”).
`(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”
`Lin determines, at the mobile device, whether the application is
`signed, using the signed ADF, which includes both the JAR file with the
`code and the “developer signature 312.” We conclude one of skill in the art
`would understand the signature to have been generated using the developer’s
`private key, and that the private key would not be accessible to the mobile
`device.
`At this stage of the proceeding, we are not persuaded by Patent
`Owner’s argument that Lin does not disclose “a signed software application”
`because “Lin teaches that the signed component is a separate file—called an
`application descriptor file (ADF)—that is used to authenticate the source of
`the software application.” Prelim. Resp. 17. Patent Owner has not sought a
`claim construction that would require the signature to be part of the
`
`16
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`application code itself, or located within the same file as the code, and we
`note that the ’868 patent describes more generally that the signature “is
`generated by the code signing authority 16 and appended to the software
`application Y 14.” Ex. 1001, 4:38–41, emphasis added.
`We also are not persuaded by Patent Owner’s argument that Lin does
`not expressly or inherently disclose a “private key . . . not accessible to the
`mobile device.” Pet. 23. At this stage of the proceeding, we credit the
`testimony of Petitioner’s expert, Dr. McDaniel, that the developer’s private
`key “must only be known to the developer” because otherwise “it cannot be
`verified that the source of the application is the application developer” as
`“an untrusted third party could have used the developer’s private key to
`generate digital signature 312.” Ex. 1002, ¶ 168.
`We do not agree that Patent Owner’s hypothetical, in which “a
`developer who hopes to test their application [downloads] it to confirm that
`it works as anticipated” (Prelim. Resp. 24), precludes a finding of inherency.
`First, it is unclear why, in a testing scenario, the private key would be on a
`developer’s mobile device, as opposed to being on a personal computer or
`other, non-mobile hardware more likely to be used for development and/or
`the application of digital signatures. Second, the test for inherency is “the
`natural result flowing from the operation as taught [in the reference],”
`MEHL/Biophile Int’l Corp. v. Milgraum, 192 F.3d 1362, 1365 (Fed. Cir.
`1999), and the reference describes a conventional private-public key system
`in which the private key is private to the signing entity. We thus find that
`the private key not being accessible to the mobile device is inherent in Lin
`even if Patent Owner can construct a hypothetical scenario in which a
`
`17
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`private key might for some reason find its way onto a mobile device that is
`using a corresponding public key for authentication.
`(e) “the mobile device using a public key of the
`private key public key pair to verify the digital
`signature of the software application”
`Lin explains that “[u]pon receiving the signed ADF, the client device
`verifies the developer certificate with the code signing certificate authority’s
`public key (606).” Ex. 1011, 5:6–8.
`(f) “based upon verifying the digital signature at the
`mobile device, the mobile device allowing the software
`application access to the sensitive API”
`Lin allows the application to access the sensitive API based upon
`verifying the digital signature. See, e.g., Ex. 1011, 3:12–14 (“The virtual
`machine only allows the application to access the resources permitted, as
`dictated by the signed ADF.”).
`3. Application of Lin 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 anticipation of claim 76 for the same reasons
`that the showing of anticipation of claim 1 is sufficient.
`4. Anticipation of Dependent Claims
`Petitioner sets forth a detailed explanation of its challenge to claims
`78, 81, 84, 85, 90–92, 95, 104, 113, 137, and 142 based on Lin. Pet. 29–36.
`We conclude that Petitioner has demonstrated a reasonable likelihood of
`prevailing in its challenge to claims 78, 81, 84, 85, 90–92, 95, 104, 113, 137,
`and 142 based on Lin, for the reasons identified in the Petition. Patent
`Owner does not offer a rebuttal of Petitioner’s anticipation challenge to these
`claims in its Preliminary Response.
`
`18
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`D. 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
`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.11
`Petitioner contends the following combinations render the remaining
`challenged claims unpatentable as obvious under 35 U.S.C. § 103(a): Lin
`and Garst (claims 13, 88, and 98); Lin and Davis (claims 77, 79, 80, and 82);
`Lin and Chang (claim 83); Lin and Sibert (claim 86); Lin and Wong-Insley
`(claim 89); Lin and Haddock (claim 94); and Lin and Gong (claims 93, 100,
`112, and 139). Relying on the testimony of Dr. McDaniel, Petitioner
`endeavors to explain how the references teach or suggest all of the
`limitations of these claims. Pet. 36–63; see Ex. 1002.
`We conclude that Petitioner has accounted sufficiently for the
`limitations of these claims, for the reasons articulated in the cited portion of
`the Petition. We accordingly are persuaded, at this juncture of the
`proceeding, that Petitioner has established a reasonable likelihood that it
`
`
`11 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.
`
`19
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`would prevail in its challenge to these claims as obvious, 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.
`
`E. 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.
`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
`particu
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
