`
` Paper 31
`Trials@uspto.gov
`571-272-7822 Entered: December 19, 2018
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`
`GOOGLE LLC,
`Petitioner
`
`v.
`
`BLACKBERRY LTD.,
`Patent Owner.
`____________
`
`Case IPR2017-01620
`Patent 8,489,868 B2
`____________
`
`
`
`Before SALLY C. MEDLEY, ROBERT J. WEINSCHENK,
`and AARON W. MOORE, Administrative Patent Judges.
`
`MOORE, Administrative Patent Judge.
`
`
`
`
`FINAL WRITTEN DECISION
`35 U.S.C. § 318(a) and 37 C.F.R. § 42.73
`
`
`
`
`
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`A. Background
`
`I. INTRODUCTION
`
`Google LLC (“Petitioner”) filed a Petition (Paper 1, “Pet.”) for inter
`partes review of claims 1, 13, 76–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”),
`asserting unpatentability on the following grounds (see Pet. 2–3):
`
`References
`
`Lin1
`
`Lin and Garst3
`Lin and Davis4
`Lin and Chang5
`Lin and Sibert6
`Lin and Wong-Insley7
`Lin and Haddock8
`Lin and Gong9
`
`Basis
`
`§ 102(e)2
`
`§ 103(a)
`§ 103(a)
`§ 103(a)
`§ 103(a)
`§ 103(a)
`§ 103(a)
`§ 103(a)
`
`Challenged Claim(s)
`1, 76, 78, 81, 84, 85, 90–92,
`95, 104, 113, 137, and 142
`13, 88, and 98
`77, 79, 80, and 82
`83
`86
`89
`94
`93, 100, 112, 139
`
`
`1 U.S. Patent No. 6,766,353 B1, July 20, 2004 (Ex. 1011).
`2 Because the effective filing date of the ’868 patent is earlier than March 16,
`2013, the pre-AIA versions of Sections 102 and 103 control.
`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).
`
`2
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`We instituted an inter partes review on all grounds raised in the
`Petition. See Paper 9 (“Inst. Dec.”) at 23.
`The briefing in this proceeding now includes the Petition, a Patent
`Owner Response (Paper 16, “PO Resp.”), a Petitioner Reply (Paper 19,
`“Reply”), and a Patent Owner Sur-Reply (Paper 26, “Sur-Reply”). On
`September 17, 2018, we held an oral hearing, together with IPR2017-01619,
`a transcript of which is included in the record as Paper 30 (“Tr.”). Petitioner
`relies on a declaration by Dr. Patrick D. McDaniel (Ex. 1002, “McDaniel
`Decl.”); Patent Owner relies on a declaration of Dr. George T. Ligler
`(Ex. 2002, “Ligler Decl.”). Both experts were deposed, and the deposition
`transcripts were made of record. See Ex. 2004 (“McDaniel Tr.”); Ex. 1046
`(“Ligler Tr.”). Patent Owner filed evidentiary objections (Papers 11 and
`21), but no motion to exclude.
`We have jurisdiction under 35 U.S.C. § 6. Petitioner bears the burden
`of proving unpatentability of the challenged claims, and the burden of
`persuasion never shifts to Patent Owner. Dynamic Drinkware, LLC v. Nat’l
`Graphics, Inc., 800 F.3d 1375, 1378 (Fed. Cir. 2015). To prevail, Petitioner
`must prove unpatentability by a preponderance of the evidence. See 35
`U.S.C. § 316(e); 37 C.F.R. § 42.1(d).
`This Final Written Decision is issued pursuant to 35 U.S.C. § 318(a)
`and 37 C.F.R. § 42.73. On this record, we determine, for the reasons
`detailed below, that Petitioner has shown by a preponderance of the
`evidence that claims 1, 76–84, 89, 90, 91, 92, 93, 94, 100, 113, 137, 139, and
`142 of the ’868 patent are unpatentable, but has not shown that claims 13,
`85, 86, 88, 98, 104, and 112 are unpatentable.
`
`3
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`B.
`
`Related Proceedings
`
`The ’868 patent was at issue in BlackBerry Ltd. v. BLU Products, Inc.,
`No. 1-16-cv-23535 (S.D. Fla.). Pet. 1. According to PACER, the case was
`dismissed on August 15, 2017.
`Petitioner concurrently filed another petition, IPR2017-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.
`
`C.
`
`The ’868 Patent
`
`The ʼ868 patent describes “a code signing system and method” said to
`be “particularly well suited for JavaTM applications for mobile communication
`devices, such as Personal Digital Assistants, cellular telephones, and wireless
`two-way communication devices.” Ex. 1001, 1:20–24.
`The patent explains that “[i]n a typical software code signing scheme,
`a digital signature is attached to a software application that identifies the
`software developer” and “[o]nce the software is downloaded by a user, the
`user typically must use his or her judgment to determine whether or not the
`software application is reliable, based solely on his or her knowledge of the
`software developer’s reputation.” Id. at 1:30–36. The patent identifies two
`drawbacks to this prior art scheme. First, it “does not ensure that a software
`application written by a third party for a mobile device will properly interact
`with the device’s native applications and other resources.” Id. at 1:37–43.
`Second, “[b]ecause typical code signing protocols are not secure and rely
`solely on the judgment of the user, there is a serious risk that destructive . . .
`4
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`software applications may be downloaded and installed onto a mobile
`device.” Id.
`The solution described in the ’868 patent is “[a] code signing system
`[that] operates in conjunction with a software application having a digital
`signature.” Id. at 1:54–56. An application programming interface (“API”)
`is “configured to link the software application with [an] application
`platform” and “[a] virtual machine verifies the authenticity of the digital
`signature in order to control access to the API by the software application.”
`Id. at 1:58–61.
`
`
`
`
`5
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`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
`
`6
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`therefore should be signed, then a signature . . . for the software application
`Y 14 is generated by the code signing authority 16 and appended to the
`software application Y 14.” Id. at 4:36–40. “The signed software
`application Y 22 may then be sent to a mobile device 28 or downloaded by
`the mobile device 28 over a wireless network 24.” Id. at 4:56–58. “Once
`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:66–5:3. “When the signatures are verified, the software application
`Y 14 can be executed on the device and access any APIs for which
`corresponding signatures have been verified.” Id. at 5:9–11.
`The ’868 patent also describes a method for “network operators” to
`“maintain control over which software applications are activated on mobile
`devices.” Id. at 1:44–46. “In this multiple-signature scenario, all APIs are
`restricted and locked until a “global” signature is verified for a software
`application.” Id. at 4:1–3. For example, corporate mobile devices may “be
`configured to require verification of at least a global signature before a
`software application can be executed,” and “[a]ccess to sensitive device
`APIs and libraries . . . could then be further restricted, dependent upon
`verification of respective corresponding digital signatures.” Id. at 4:7–12.
`Independent claims 1 and 76 of the ’868 patent, which exemplify the
`subject matter of the challenged claims, are the only independent claims
`challenged and are reproduced below:
`1. A mobile device containing software instructions
`which when executed on the mobile device cause the mobile
`device to perform operations for controlling access to an
`application platform of the mobile device, the operations
`comprising:
`
`7
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`storing a plurality of application programming interfaces
`(APIs) at the mobile device, wherein at least one API comprises
`a sensitive API to which access is restricted;
`receiving, at the mobile device, an indication that a
`software application on the mobile device is requesting access
`to the sensitive API stored at the mobile device;
`determining, at the mobile device, whether the software
`application is signed, wherein a signed software application
`includes a digital signature generated using a private key of a
`private key-public key pair, wherein the private key is not
`accessible to the mobile device;
`the mobile device using a public key of the private key
`public key pair to verify the digital signature of the software
`application; and
`based upon verifying the digital signature at the mobile
`device, the mobile device allowing the software application
`access to the sensitive API.
`Ex. 1001, 14:42–62.
`76. A method for controlling access to an application
`platform of a mobile device, comprising:
`storing a plurality of application programming interfaces
`(APIs) at the mobile device, wherein at least one API comprises
`a sensitive API to which access is restricted;
`receiving, at the mobile device, an indication that a
`software application on the mobile device is requesting access
`to the sensitive API stored at the mobile device;
`determining, at the mobile device, whether the software
`application is signed, wherein a signed software application
`includes a digital signature generated using a private key of a
`private key-public key pair, wherein the private key is not
`accessible to the mobile device;
`mobile device using a public key of the private key-
`public key pair to verify of [sic] the digital signature of the
`software application; and
`
`8
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`based upon verifying the digital signature at the mobile
`device, the mobile device allowing the software application
`access to the sensitive API.
`Id. at 20:4–22.
`
`II. ANALYSIS
`
`A.
`
`Level of Skill in the Art
`
`The level of skill in the art is a factual determination that informs the
`claim construction analysis and helps guarantee objectivity in an
`obviousness analysis. See Al-Site Corp. v. VSI Int’l Inc., 174 F.3d 1308,
`1323 (Fed. Cir. 1999) (citing Graham v. John Deere Co., 383 U.S. 1, 17–18
`(1966); Teva Pharm. USA, Inc. v. Sandoz, Inc., 135 S. Ct. 831, 841 (2015)
`(explaining that claim construction seeks the meaning “a skilled artisan
`would ascribe” to the term “in the context of the specific patent claim”).
`Petitioner asserts that a person of ordinary skill in the art at the time of
`the alleged invention “would have had at least a Bachelor’s degree in
`computer science or the equivalent, and two years of work experience in the
`relevant field, e.g., secure systems, including security protocols for software
`applications” and that “[m]ore education can substitute for practical
`experience and vice versa.” Pet. 6. Patent Owner asserts “[o]ne of ordinary
`skill [] in the field . . . would have had (1) at least a bachelor’s degree in
`computer science, or the equivalent, and (2) at least two years of experience
`in secure systems, including security protocols for software applications.”
`PO Resp. 5.
`The parties’ proposals are similar and neither party argues that it
`makes a difference which one we choose. We determine that the selection
`of one proposal over the other does not affect our analysis, but adopt Patent
`Owner’s formulation for purposes of this Decision.
`9
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`B.
`
`Claim Construction
`
`In inter partes reviews filed before November 13, 2018, the Board
`construes claims in an unexpired patent according to their broadest
`reasonable construction in light of the specification of the patent in which
`they appear. See Cuozzo Speed Techs., LLC v. Lee, 136 S. Ct. 2131, 2144–
`46 (2016); Changes to the Claim Construction Standard for Interpreting
`Claims in Trial Proceedings Before the Patent Trial and Appeal Board,
`83 Fed. Reg. 51,340 (Oct. 11, 2018). The broadest reasonable construction
`is the “ordinary and customary meaning” to a person of ordinary skill in the
`art at the time of invention. See In re Translogic Tech., Inc., 504 F.3d 1249,
`1257 (Fed. Cir. 2007); Phillips v. AWH Corp., 415 F.3d 1303, 1312–14
`(Fed. Cir. 2005) (en banc). “[T]he person of ordinary skill in the art is
`deemed to read the claim term not only in the context of the particular claim
`in which the disputed term appears, but in the context of the entire patent,
`including the specification.” Phillips, 415 F.3d at 1313. “[T]he claims
`themselves provide substantial guidance as to the meaning of particular
`claim terms,” id. at 1314, and “[w]hile we read claims in view of the
`specification, of which they are a part, we do not read limitations from the
`embodiments in the specification into the claims,” Hill-Rom Servs., Inc. v.
`Stryker Corp., 755 F.3d 1367, 1371 (Fed. Cir. 2014). We may “depart from
`the plain and ordinary meaning of claim terms based on the specification in
`only two instances: lexicography and disavowal.” Id.
`
`10
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`1.
`
`“determining, at the mobile device, whether the software
`application is signed, wherein a signed software application
`includes a digital signature generated using private key of a
`private key-public key pair”
`All challenged claims include the above phrase. The Petition
`proposes that this phrase be construed as “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). Patent Owner did not offer a construction before
`institution. See Prelim Resp. 10–11. At institution, we declined to adopt
`Petitioner’s construction, finding that it unnecessarily narrowed the claims.
`See Inst. Dec. 9–10. Neither the Patent Owner Response nor the Reply
`substantively addresses this issue.
`We find Petitioner’s arguments (see Pet. 8–12) insufficient to narrow
`the scope of the claim language because they, at best, seek to limit the
`claims to the preferred embodiment without identifying anything sufficient
`to rise to the level of a clear disavowal. See Info-Hold, Inc. v. Applied
`Media Techs. Corp., 783 F.3d 1262, 1267 (Fed. Cir. 2015) (“[T]he scope of
`the invention is properly limited to the preferred embodiment if the patentee
`uses words that manifest a clear intention to restrict the scope of the claims
`to that embodiment.”). We thus decline to adopt Petitioner’s proposed
`construction and determine that this term does not otherwise require
`construction.
`
`11
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`2.
`
`“[a] plurality of [APIs] . . . , wherein at least one API
`comprises a sensitive API to which access is restricted”
`In the Preliminary Response, Patent Owner asked 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. 7–10. We did not agree in our institution decision
`that this language requires any additional construction, and Patent Owner
`does not revisit the issue in the Response. See Inst. Dec. 12–13; PO Resp.
`5–22. To the extent Patent Owner is still seeking this construction, we
`decline to add the additional language for the reasons provided in the
`institution decision. See Inst. Dec. 12–13.
`
`“abridged version of a software application”
`3.
`Patent Owner argues the broadest reasonable interpretation of
`“abridged version of a software application,” which appears in claim 86, “is
`a unique transformation of the software application that is smaller than the
`software application.” PO Resp. 52. To support this argument, Patent
`Owner points to the description in the patent of “an ‘abridging scheme or
`algorithm,’ which is used like a hash function to ‘generate different outputs
`for different inputs.’” Id. (quoting Ex. 1001, 6:32–37).
`Petitioner responds that the patent “does not claim any abridging
`scheme or algorithm,” that “the term ‘transformation’ is not defined by the
`specification . . . or by PO and therefore is vague and ambiguous,” and that
`“the specification [does not] refer to an abridged version of the software
`application as a transformation.” Reply 1–2.
`We agree with Patent Owner that the broadest reasonable
`interpretation of an “abridged version of a software application” is “a unique
`
`12
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`transformation of the software application that is smaller than the software
`application.” The patent describes an embodiment in which the software
`developer may “provide the software application Y in some type of abridged
`format” in order to “have the software application Y signed without
`revealing proprietary code to the code signing authority.” Ex. 1001, 6:16–
`29. The ’868 patent further states “the abridged version may . . . be used to
`generate the digital signature, provided that the abridging scheme or
`algorithm . . . generates different outputs for different inputs,” to “ensure
`that every software application will have a different abridged version and
`thus a different signature that can only be verified when appended to the
`particular corresponding software application from which the abridged
`version was generated.” Id. at 6:34–41 (emphasis added). We conclude that
`the phrase “provided that” is sufficient to limit claims reciting an abridged
`version of the application to abridged versions that are unique. See Hill-Rom
`Services, 755 F.3d at 1372 (explaining that disavowal is appropriate where
`the specification makes clear that the invention does not include a particular
`feature or is clearly limited to a particular form of the invention); cf. X2Y
`Attenuators, LLC v. Int’l Trade Comm’n, 757 F.3d 1358, 1362 (Fed. Cir.
`2014) (finding disavowal where the specification stated the feature was an
`“essential element”); Andersen Corp. v. Fiber Composites, LLC, 474 F.3d
`1361, 1367 (Fed. Cir. 2007) (finding disclaimer where the specification
`indicated that for “successful manufacture” a particular step was “required”);
`Chimie v. PPG Indus., Inc., 402 F.3d 1371, 1385 (Fed. Cir. 2005)
`(construing claim to include a feature the applicant told the examiner “must
`be used”).
`
`13
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`We do not agree with Petitioner that the term “transformation” is
`“vague and ambiguous” in this context, as it simply refers to the use of a
`scheme or algorithm to generate an output from an input––transforming the
`input into the output––as described in the patent. See Ex. 1001, 6:16–41.
`
` Claim Construction Conclusion
`4.
`The table below summarizes our resolution of the claim construction
`issues we decide in this proceeding.
`
`Term
`abridged version of a
`software application
`
`Construction
`“a unique transformation of
`the software application that
`is smaller than the software
`application”
`
`C. Anticipation
`
`Petitioner contends claims 1, 76, 78, 81, 84, 85, 90–92, 95, 104, 113,
`137, and 142 are unpatentable as anticipated by Lin. See Pet. 15–36; Reply
`2–16. Patent Owner disputes those contentions. See PO Resp. 10–45.
`
`Legal Standard
`1.
`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)).
`
`14
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`Overview of Lin
`2.
`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.
`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
`
`15
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`(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.
`
`Independent Claim 1
`3.
`We conclude that Petitioner has proven, by a preponderance of the
`evidence, that the subject matter of claim 1, which we address on an
`element-by-element basis below, was 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. See Pet. 15–17.
`Patent Owner does not dispute that Lin satisfies this limitation.
`
`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 described 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 (citing Ex. 1002
`¶ 142); see also, e.g., Ex. 1011, 2:38–41. 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
`
`16
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`is limited by the digital signature, as described below. See Pet. 20–22
`(citing, e.g., Ex. 1011, 1:31–35, 2:35–41, 3:5–14, 3:48–56). Patent Owner
`does not dispute that Lin would include APIs stored on the mobile device or
`that access is restricted to certain APIs.
`
`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 Pet. 22–23 (citing Ex. 1011, 2:24–29, 3:5–
`10, 3:12–14, 3:29–31, 3:35–41, 5:26–30, Fig. 3). Patent Owner does not
`dispute that Lin includes receiving an indication that an application is
`requesting API access.
`
`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.” See Pet. 23–24 (“signed”; citing
`Ex. 1011, 2:29–32, 3:42–48, 4:15–18, 5:45–48, 6:18–26, 6:58–60; Ex. 1002
`¶ 163); id. at 24–26 (“determining”; citing Ex. 1011, 2:29–35, 2:67–3:5,
`3:62–64, 4:54–60, 4:66–5:4, 5:6–30, 5:37–52, 6:13–26; Ex. 1002 ¶ 172–
`175). We conclude that one of skill in the art would have understood the
`signature to have been generated using the developer’s private key, and that
`the private key would not have been accessible to the mobile device. See
`Ex. 1002 ¶¶ 28–34, 162–169; Section II.C.5.c.
`
`17
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`e.
`
`“the mobile device using a public key of the private
`key public key pair to verify the digital signature of
`the software application”
`We agree with Petitioner that Lin describes how “after downloading
`the application file 204 onto the mobile device, the device verifies digital
`signature 312 using public key 318.” Pet. 28 (citing Ex. 1011, Abstract,
`2:29–35, 3:62–64, 5:20–30, 5:43–48, 6:18–20, 5:6–8; Ex. 1002 ¶¶ 177–178).
`Patent Owner does not dispute that Lin uses the public key to verify the
`digital signature.
`
`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 Pet. 28–29 (citing Ex. 1011, Abstract,
`1:6–11, 1:29–39, 1:56–58, 2:20–29, 2:29–41, 3:5–14, 3:12–16 (“The virtual
`machine only allows the application to access the resources permitted, as
`dictated by the signed ADF.”), 3:21–39, 3:35–39, 3:48–56, 3:63–64, 4:20–
`23, 5:6–13, 5:20–30, 5:37–52, 5:62–6:61, 6:18–20, Figs. 2, 3). We discuss
`Patent Owner’s argument regarding this “based on” recitation below. See
`Section II.C.5.b.
`
`Independent Claim 76
`4.
`Claim 76 is a method claim corresponding to the apparatus of claim 1.
`Specifically, it recites “[a] method for controlling access to an application
`platform of a mobile device,” where the steps of the method are identical to
`the claim 1 limitations discussed in Sections II.C.3.b–f above. Patent Owner
`does not argue claim 76 separately from claim 1.
`
`18
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`Patent Owner Arguments Regarding Anticipation
`5.
`Patent Owner makes three arguments regarding anticipation by Lin,
`which we address in the order presented.
`
`Improperly Combining Embodiments
`a.
`Patent Owner first argues that Petitioner improperly combines distinct
`embodiments described in Lin. See PO Resp. 17–25. We disagree because,
`viewed as a whole, Lin describes one system that can be implemented in
`various ways. Lin’s description begins with a general overview (see
`Ex. 1011, 2:19–41), describes in connection with Figure 1 the types of
`hardware and software that may used (see id. at 2:42–64), describes in
`connection with Figure 2 the network environment (see id. at 2:25–3:20),
`describes in connection with Figure 3 the ADF (see id. at 3:21–64),
`describes in connection with Figure 4 how the developer produces the ADF
`(see id. at 3:64–4:29), describes in connection with Figure 5 how the
`developer obtains a developer’s certificate (see id. at 4:30–53), and then
`describes in connection with Figure 6 how clients can download the ADF
`and the application (see id. at 4:54–5:30). Although it is true that the portion
`of the description associated with Figure 6 does not specifically state that the
`ADF and application may be transferred together, we find that immaterial
`because the overall system is described as including the option for them to
`be transferred together. See Ex. 1011, 3:1–5 (“[T]he client device [receives]
`an application file 204, which includes a signed ADF 206 and the
`application code 208. . . . These two parts maybe transferred separately or
`together.” (emphasis added)). Because Figure 6 and its associated
`description purport to detail only a portion of the overall system, not a
`standalone embodiment, there is no improper mixing of embodiments.
`
`19
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`“Based Upon Verifying the Digital Signature”
`b.
`Patent Owner next argues that the claim language “based upon
`verifying the digital signature at the mobile device, the mobile device
`allowing the software application access to the sensitive API” means that
`“access to the sensitive API [depends] on successful verification of the
`digital signature” and that Lin “does not disclose that an application’s access
`to device resources 212 is ‘based upon verifying’ digital signature 312.” PO
`Resp. 25–26. Patent Owner argues that “even if the process for verifying
`digital signature 312 were inherently disclosed, such disclosure does not in
`turn disclose—either expressly or inherently—that a software application is
`allowed to access resources ‘based upon verifying’ digital signature 312.”
`Id. at 27. Regarding Lin’s disclosures that the “developer’s signature . . .
`allows the client device to authenticate the ADF” (Ex. 1011, 3:63–64) and
`that the “developers provide[] their public key in the signed ADF so that
`client devices can use them to further establish a trusted chain” (id. at 5:43–
`45), Patent Owner argues that these passages “say nothing about whether
`execution of the . . . application is ‘based upon’ successful verification of
`developer’s digital signature 312.” PO Resp. 27.
`Petitioner responds that “as explained by Dr. McDaniel, verification
`of signature 312 using the developer’s public key 318 confirms that elements
`302/304/306/308/310 have not been altered after signature 312 was created”
`and that “the ‘signed ADF allows devices . . . to easily authenticate the
`trustworthiness of an application’ before it is executed.” Reply 8–9 (quoting
`Ex. 1011, 5:37–40).
`We agree with Petitioner that Lin describes allowing the software
`application access to the sensitive API “based upon” verifying the digital
`
`20
`
`
`
`IPR2017-01620
`Patent 8,489,868 B2
`
`signature 312. Having considered Lin’s description as a whole, as well as
`the expert testimony on this issue (see Ex. 1002 ¶¶ 179–182; Ex. 2002
`¶¶ 62–75), we conclude that one of skill in the art would have understood
`that the purpose of verifying the digital signature 312 would have been to
`make a determination about whether the ADF was trustworthy or had been
`altered. We further conclude that one of skill in the art would have known
`not to rely on the ADF to allow access by the application if the digital
`signature could not be verified. We see no other purpose for the digital
`signature 312, and, when asked at the hearing, Patent Owner likewise could
`not identify one. See Tr. 93:22–94:6. In fact, Patent Owner acknowledged
`that the digital signature 312 “could potentially provide an additional level
`of assurance” (id. at 94:1–2), and we understand that to mean, in this
`context, that insufficient assurance would cause one to not allow access by
`the application.
`Our conclusion is also supported by Lin’s claim 2, which adds to the
`“method of authenticating a JAVA archive file as defined in claim 1,” the
`additional step of “verifying the developer signature using the developer
`public key.” Patent Owner’s argument that claim 2
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
