Paper No. 8
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`––––––––––––––––––
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`––––––––––––––––––
`
`GOOGLE INC.,
`Petitioner,
`
`v.
`
`BLACKBERRY LTD.,
`Patent Owner.
`
`––––––––––––––––––
`
`Case No. IPR2017-01620
`U.S. Patent No. 8,489,868
`
`––––––––––––––––––
`
`PATENT OWNER’S PRELIMINARY RESPONSE
`
`
`
`

`

`IPR2017-01620
`
`Patent Owner’s Preliminary Response
`
`TABLE OF CONTENTS
`
`I.
`
`II.
`
`Introduction ...................................................................................................... 1
`
`Overview of the ’868 Patent ............................................................................ 2
`
`III. Claim Construction .......................................................................................... 6
`
`A.
`
`“Sensitive API To Which Access Is Restricted”................................... 6
`
`i.
`
`ii.
`
`A “Sensitive API” Is One That Implicates a Security Concern
`Relative to Non-Sensitive APIs .................................................. 6
`
`“[A] Plurality of [APIs] …, Wherein at Least One API
`Comprises a Sensitive API to Which Access Is Restricted”
`Requires the “Sensitive API” to Have Additional Access
`Restrictions Relative to Non-Sensitive APIs .............................. 7
`
`B.
`
`“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” ............................................................. 10
`
`IV. The Petition Fails to Meet the Requirements for Instituting an Inter Partes
`Review ........................................................................................................... 14
`
`A. Overview of Lin (Ex. 1011) ................................................................ 15
`
`B.
`
`C.
`
`Lin Does Not Disclose “A Signed Software Application” ................. 17
`
`Lin Does Not Disclose “A Sensitive API to Which Access Is
`Restricted” ........................................................................................... 20
`
`i.
`
`ii.
`
`Petitioner’s Analysis Reads “Sensitive” Out of the Claims ..... 20
`
`Lin Does Not Disclose Additional Access Restrictions for
`“Sensitive APIs” ....................................................................... 22
`
`D.
`
`Lin Does Not Expressly or Inherently Disclose “Wherein the Private
`Key Is Not Accessible to the Mobile Device” .................................... 23
`
`i
`
`

`

`IPR2017-01620
`
`Patent Owner’s Preliminary Response
`
`E.
`
`The Petition Fails to Show Gong is a Printed Publication (Claims 93,
`100, 112, and 139) ............................................................................... 26
`
`i.
`
`ii.
`
`iii.
`
`Petitioner Fails to Show When Gong Was Publicly
`Accessible ................................................................................. 28
`
`Petitioner Fails to Show Gong Was Sufficiently Indexed ........ 31
`
`Petitioner Relies Exclusively on Inadmissible Hearsay ........... 33
`
`F.
`
`The Board Should Deny the Petition Under 35 U.S.C. § 325(d)
`Because Lin Was Overcome During Prosecution ............................... 34
`
`V.
`
`Conclusion ..................................................................................................... 36
`
`Certificate Of Compliance ....................................................................................... 37
`
`Certificate Of Service............................................................................................... 38
`
`
`
`
`
`
`
`ii
`
`

`

`IPR2017-01620
`
`Patent Owner’s Preliminary Response
`
`TABLE OF AUTHORITIES
`
` Page(s)
`
`Cases
`ABS Global, Inc. v. Inguran, LLC,
`IPR2016-00927, Paper 33 (PTAB Oct. 2, 2017) .......................................... 29, 32
`Bettcher Indus. v. Bunzl USA, Inc.,
`661 F.3d 629 (Fed. Cir. 2011) ............................................................................ 26
`Blue Calypso, LLC v. Groupon, Inc.,
`815 F.3d 1331 (Fed. Cir. 2016) .................................................................... 27, 31
`In re Cronyn,
`890 F.2d 1158 (Fed. Cir. 1989) .......................................................................... 32
`Elec. Frontier Found. v. Personal Audio,
`LLC, IPR2014-00070, Paper 21 (PTAB Apr. 18, 2014) .................................... 27
`Hill-Rom Servs., Inc. v. Stryker Corp.,
`755 F.3d 1367 (Fed. Cir. 2014) .......................................................................... 12
`In re Klopfenstein,
`380 F.3d 1345 (Fed. Cir. 2004) .......................................................................... 26
`L-3 Comm. Holdings, Inc. v. Power Survey, LLC,
`IPR2014-00832, Paper 9 (PTAB Nov. 14, 2014) ............................................... 26
`In re Lister,
`583 F.3d 1307 (Fed. Cir. 2009) ........................................................ 27, 31, 32, 33
`Neil Ziegman, N.P.Z., Inc. v. Stephens,
`IPR2015-01860, Paper 11 (P.T.A.B. Feb. 24, 2016) .......................................... 35
`Nidec Motor Corp. v. Zhongshan Broad Ocean Motor Co. Ltd,
`851 F.3d 1270 (Fed. Cir. 2017) .......................................................................... 26
`On-Line Techs., Inc. v. Bodenseewerk Perkin-Elmer GmbH,
`386 F.3d 1133 (Fed. Cir. 2004) .......................................................................... 12
`ServiceNow, Inc. v. Hewlett-Packard Co.,
`IPR2015-00707, Paper 12 (PTAB Aug. 26, 2015) ............................................. 34
`iii
`
`

`

`IPR2017-01620
`
`Patent Owner’s Preliminary Response
`
`ServiceNow, Inc. v. Hewlett-Packard Co.,
`IPR2015-00716, Paper 13 (PTAB Aug. 2, 2015) ............................................... 34
`Square,
`CBM2014-00156, Paper 22 ................................................................................ 28
`In re Suitco Surface, Inc.,
`603 F.3d 1255 (Fed. Cir. 2010) .......................................................................... 21
`Unwired Planet, LLC v. Apple Inc.,
`829 F.3d 1353 (Fed. Cir. 2016) .................................................................... 13, 14
`Statutes
`35 U.S.C. § 102(b) ................................................................................................... 27
`35 U.S.C. § 311 ........................................................................................................ 11
`35 U.S.C. § 311(b) ................................................................................................... 26
`35 U.S.C. § 325(d) ............................................................................................... 2, 34
`Other Authorities
`37 C.F.R. § 42.100(b) ................................................................................................ 8
`37 C.F.R. § 42.107 ..................................................................................................... 1
`Fed. R. Evid. 801 ..................................................................................................... 34
`
`
`
`
`iv
`
`

`

`IPR2017-01620
`
`I.
`
`Introduction
`
`Patent Owner’s Preliminary Response
`
`Pursuant to 37 C.F.R. § 42.107, Patent Owner BlackBerry Limited (“Patent
`
`Owner”) submits this Preliminary Response in opposition to the Petition for Inter
`
`Partes Review of U.S. Patent No. 8,489,868 (“’868 patent”). The Petition
`
`challenges the patentability of claims 1, 13, 76-86, 88-95, 98, 100, 104, 112, 113,
`
`137, 139, and 142 across eight different grounds, each of which relies on U.S.
`
`Patent No. 6,766,353 (“Lin”). As explained below, trial should not be instituted
`
`because the Petition fails in at least four independent ways—each of which is fatal
`
`to the Petition.
`
`First, Lin does not disclose “a signed software application,” as required by
`
`each of the challenged claims. Rather, Lin discloses only authentication using a
`
`signed file that is entirely separate from the software application.
`
`Second, Lin does not disclose “a sensitive API,” as required by each of the
`
`challenged claims. To the extent Lin discloses an application programming
`
`interface (“API”) at all, it certainly does not disclose any APIs that are “sensitive,”
`
`i.e., one that implicates additional security concerns relative to a non-sensitive API.
`
`Third, Lin does not disclose “wherein the private key is not accessible to the
`
`mobile device,” as required by each of the challenged claims. Petitioner admits
`
`that Lin does not expressly disclose this element and instead asserts inherency, but
`
`fails to explain why that element would have necessarily been present in Lin.
`
`1
`
`

`

`IPR2017-01620
`
`Patent Owner’s Preliminary Response
`
`Finally, the Board should exercise its discretion and deny the petition under
`
`35 U.S.C. § 325(d) because each of Petitioner’s asserted grounds of unpatentability
`
`relies on Lin, which was considered by the Examiner during prosecution and in
`
`view of which the claims were allowed. Petitioner provides no justification for
`
`why the Board should revisit art that already was considered and overcome during
`
`prosecution. For each of these reasons, the Petition should be denied.
`
`II. Overview of the ’868 Patent
`
`The ’868 patent, entitled “Software Code Signing System and Method,” was
`
`filed on March 20, 2003 and issued on July 16, 2013. The ’868 patent claims
`
`priority to provisional application No. 60/234,152, which was filed on September
`
`21, 2000; provisional application No. 60/235,354, which was filed on September
`
`26, 2000; and provisional application No. 60/270,663, which was filed on February
`
`20, 2001. Petitioner does not dispute that the ’868 patent is entitled to its
`
`September 21, 2000 priority date. See Paper 1 (“Petition”) at 3.
`
`The ’868 patent is generally directed to security protocols involving
`
`software code signing schemes for mobile devices. Ex. 1001 at 1:18-25. The ’868
`
`patent explains that application developers may create software applications that
`
`may require access to one or more application programming interfaces (“APIs”).
`
`Id. at 3:9-45. APIs allow a software application to interact with the device
`
`resources associated with those APIs. Id. Because prior code signing protocols
`
`2
`
`

`

`IPR2017-01620
`
`Patent Owner’s Preliminary Response
`
`were not “secure and rely solely on the judgment of the user, there is a serious risk
`
`that destructive, ‘Trojan horse’ type software applications may be downloaded and
`
`installed onto a mobile device.” Id. at 1:39-43. The ’868 patent explains that
`
`among a device’s APIs, certain “sensitive” APIs may expose functionality that is
`
`particularly vulnerable to a virus or malicious code in a device software
`
`application. Id. at 3:46-50. For example, APIs “that interface with cryptographic
`
`routines, wireless communication functions, or proprietary data models such as
`
`address book or calendar entries” may be deemed “sensitive.” Id. at 3:50-54.
`
`Importantly, the ’868 patent further explains that an API on a device may be
`
`a “sensitive” API if, for example, the mobile device manufacturer, API author,
`
`wireless network operator, device owner or operator, or some other entity could be
`
`adversely impacted should a virus or malicious program access the API. Ex. 1001
`
`at 3:46-54. Figure 3 below shows various API Libraries A, B, C, and D on mobile
`
`device 62. API Libraries A and C include sensitive APIs and API Libraries B and
`
`D do not include sensitive APIs.
`
`3
`
`

`

`IPR2017-01620
`
`Patent Owner’s Preliminary Response
`
`
`
`Ex. 1001 at Fig. 3; see also id. at 7:19-23.
`
`To protect against unauthorized access to sensitive APIs, the ‘868 patent
`
`provides a mechanism for controlling access to sensitive APIs by using digital
`
`signatures. Ex. 1001 at 3:54-61. For example, as depicted below in Figure 1, in
`
`one embodiment, the application developer 12 sends its software application Y 14
`
`to code signing authority 16 which signs the software application Y with one or
`
`more digital signatures and sends the signed software application Y 22,
`
`“comprising the software application Y 14 and the digital signature,” to the
`
`developer 12. Id. at 4:24-43, 3:62-4:12. The signed software application Y 22
`
`may then be downloaded by mobile device 28. Id. at 4:56-58.
`
`4
`
`

`

`IPR2017-01620
`
`Patent Owner’s Preliminary Response
`
`Id. at Fig. 1.
`
`
`
`Once a digitally signed software application is downloaded onto the mobile
`
`device, the mobile device verifies the one or more digital signatures before
`
`granting access to an API library, including a sensitive API library. Ex. 1001 at
`
`4:66-5:3. Due to the nature of sensitive APIs, additional access restrictions apply
`
`to sensitive APIs relative to non-sensitive APIs. For example, where a software
`
`application is signed with multiple signatures “all APIs are restricted and locked
`
`until a ‘global’ signature is verified for a software application. . . . Access to
`
`sensitive device APIs and libraries, if any, could then be further restricted” and
`
`locked until corresponding digital signatures are verified. Id. at 4:1-12. The ’868
`
`patent also discloses that the device may display a message to the user before the
`
`5
`
`

`

`IPR2017-01620
`
`Patent Owner’s Preliminary Response
`
`software application accesses a sensitive API thereby giving the user final control
`
`to grant or deny access to the sensitive API. Id. at 8:11-18, 9:45-51.
`
`III. Claim Construction
`
`A.
`
`“Sensitive API To Which Access Is Restricted”
`
`Claims 1 and 76 recite “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.” In this proceeding, Petitioner’s
`
`patentability challenges fail to show (1) a “sensitive API” that implicates a security
`
`concern relative to non-sensitive APIs, and (2) a “sensitive API” that is different in
`
`any respect from an API by, for example, having any additional access restrictions
`
`relative to non-sensitive APIs. Because the claims require both of these elements,
`
`this Petition fails for both of these independent reasons.
`
`i.
`
`A “Sensitive API” Is One That Implicates a Security
`Concern Relative to Non-Sensitive APIs
`
`The term “sensitive API” is not a term of art in this context, and 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. The ’868 patent
`
`explains that because prior art code signing protocols were not “secure and rely
`
`solely on the judgment of the user, there is a serious risk that destructive, ‘Trojan
`
`horse’ type software applications may be downloaded and installed onto a mobile
`
`device.” Ex. 1001 at 1:39-43. Certain “sensitive” APIs may be particularly
`
`6
`
`

`

`IPR2017-01620
`
`Patent Owner’s Preliminary Response
`
`vulnerable to a virus or malicious code in a device software application. Id. at
`
`3:46-50. For example, APIs “that interface with cryptographic routines, wireless
`
`communication functions, or proprietary data models such as address book or
`
`calendar entries” may be classified as “sensitive.” Id. at 3:50-54. The ’868 patent
`
`then discloses ways to “protect against unauthorized access to these sensitive
`
`APIs.” Id. at 3:54-61.
`
`The ’868 patent recognizes that certain APIs expose portions of the device’s
`
`functionality that bad actors—such as “Trojan horse” programs—could exploit to
`
`particular ill-effect and, thus, such APIs require additional protection. The ’868
`
`patent, therefore, describes numerous ways of dealing with that sensitivity using,
`
`for example, cryptographic and non-cryptographic access restrictions. See, e.g.,
`
`Ex. 1001 at 4:1-12 (cryptographic access restrictions), 8:11-18 (non-cryptographic
`
`access restrictions). Each of these access restrictions is used to deal with the
`
`“sensitive” nature of the API—they do not make the API sensitive. A “sensitive”
`
`API is therefore one that implicates greater security concerns relative to a non-
`
`sensitive API.
`
`ii.
`
`“[A] Plurality of [APIs] …, Wherein at Least One API
`Comprises a Sensitive API to Which Access Is Restricted”
`Requires the “Sensitive API” to Have Additional Access
`Restrictions Relative to Non-Sensitive APIs
`
`Independent claims 1 and 76 recite “wherein at least one API [of a plurality
`
`of APIs] comprises a sensitive API to which access is restricted.” This phrase
`7
`
`

`

`IPR2017-01620
`
`Patent Owner’s Preliminary Response
`
`makes clear that a sensitive API is not just any API, and the sensitive API has
`
`greater access restrictions relative to non-sensitive APIs. The claims call out and
`
`differentiate a “sensitive API to which access is restricted” from the “plurality of
`
`APIs” of which it is a part. Thus, according to the plain language of the claims, the
`
`separately identified “sensitive API” has “access [] restrict[ions]” relative to those
`
`“plurality of APIs” that may be non-sensitive.
`
`This reading of the plain language of the claims is consistent with the ’868
`
`patent’s specification. See 37 C.F.R. § 42.100(b). For example, the specification
`
`explains that the “plurality of API libraries 72-78 may include both libraries that
`
`expose a sensitive API 74 and 78 . . . and libraries 72 and 76, that may be accessed
`
`without exposing sensitive APIs.” Ex. 1001 at 7:19-23. In addition, the
`
`specification describes a multiple-signature scenario with at least two layers of
`
`access restrictions where the first layer of restriction applies to all APIs and the
`
`second layer of restriction applies only to sensitive APIs:
`
`In this multiple-signature scenario, all APIs are restricted and locked
`until a “global” signature is verified for a software application. For
`example, a company may wish to prevent its employees from executing
`any software applications onto their devices without first obtaining
`permission from a corporate information technology (IT) or computer
`services department. All such corporate mobile devices may then be
`configured to require verification of at least a global signature before a
`software application can be executed. Access to sensitive device APIs
`
`8
`
`

`

`IPR2017-01620
`
`Patent Owner’s Preliminary Response
`
`and libraries, if any, could then be further restricted dependent upon
`verification of respective corresponding digital signatures.
`
`Ex. 1001 at 4:1-12 (emphasis added); see also id. at 9:5-17 (explaining
`
`embodiment where access restriction applies only to sensitive APIs). The
`
`specification further explains that a third layer of access restriction may also be
`
`applied to sensitive APIs:
`
`Then, once the appropriate digital signature 96 has been located and
`verified, the description string 88 is preferably displayed on the mobile
`device before the software application X or Y is executed and accesses
`the sensitive API. For instance, the description string 88 may display a
`message stating that “Application Y is attempting to access API Library
`A,” and thereby provide the mobile device user with the final control
`to grant or deny access to the sensitive API.
`
`Id. at 8:11-18; see also id. at 9:45-51 (“If the digital signature is authentic,
`
`however, then the description string 88 is preferably displayed in step 112,
`
`warning the mobile device user that the software application requires access to a
`
`sensitive API, and possibly prompting the user for authorization to execute or
`
`load the software application (step 114).” (emphasis added)). Thus, it is apparent
`
`from the claims and specification that the ’868 patent draws a distinction between
`
`sensitive APIs and non-sensitive APIs and treats them differently at least with
`
`respect to the extent to which access is restricted to each category of APIs. The
`
`plain language of the claims therefore requires that “sensitive API[s]” have greater
`9
`
`

`

`IPR2017-01620
`
`Patent Owner’s Preliminary Response
`
`“access [] restrict[ions]” relative to those “plurality of APIs” that may be non-
`
`sensitive.
`
`B.
`
`“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 proposes construction of a single term: it argues that the broadest
`
`reasonable interpretation (“BRI”) of “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”
`
`(the “‘determining’ limitation”) is “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. at 8. Although Petitioner provides a lengthy
`
`argument regarding construction of the “determining” limitation, its argument
`
`appears to boil down to the assertion that the “digital signature” in the
`
`“determining” limitation cannot include one that is generated using a private key of
`
`an application developer. Id. at 13-14. The Petition is defective for the reasons
`
`detailed in Section IV (below) regardless of whether the “determining” limitation
`
`excludes digital signatures generated using a private key of an application
`10
`
`

`

`IPR2017-01620
`
`Patent Owner’s Preliminary Response
`
`developer, so the Board need not construe the “determining” limitation to deny
`
`institution of the Petition.1
`
`To the extent it must be considered at all, Petitioner’s construction is
`
`incorrect and should be rejected. Contrary to Petitioner’s proposed construction,
`
`
`
`1 Petitioner urges the Board to adopt its proposed construction, but at the same time
`
`acknowledges that its Petition fails under its own narrow proposed construction.
`
`Pet. at 6 (arguing that only “the concurrently-filed petition [] relies on prior art that
`
`discloses the claims under [both the Petitioner’s and Patent Owner’s
`
`interpretations] of the ‘determining’ phrase”), 14 (arguing the present petition
`
`applies only under “PO’s interpretation,” while the prior art filed in IPR2017-
`
`01619 discloses the claims under both “Petitioner’s and PO’s [] constructions”).
`
`Thus, Petitioner is effectively requesting that the Board adopt Petitioner’s proposed
`
`construction and deny institution of this petition. This is an improper use of the
`
`inter partes review process and the Board’s limited resources. See 35 U.S.C. § 311
`
`(“[A] person who is not the owner of a patent may file with the Office a petition to
`
`institute an inter partes review of the patent.” (emphasis added)). Contrary to 35
`
`U.S.C. § 311, here, Petitioner improperly filed a petition seeking denial of inter
`
`partes review in favor of adoption of its proposed construction.
`
`
`
`11
`
`

`

`IPR2017-01620
`
`Patent Owner’s Preliminary Response
`
`the plain language of the claims does not specify whose private key has to be used
`
`(or cannot be used) in generating a digital signature. The only requirement in the
`
`claims is that the “digital signature [be] generated using a private key of a private
`
`key-public key pair.” None of Petitioner’s extraneous language in its proposed
`
`construction (“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”) is supported by the ’868 patent’s specification. And, in fact,
`
`Petitioner’s extraneous language is inconsistent with the specification.
`
`Petitioner’s proposed construction is not the BRI and should be rejected
`
`because it seeks to improperly read in limitations from some embodiments
`
`disclosed in the specification, and excludes other disclosed embodiments. Hill-
`
`Rom Servs., Inc. v. Stryker Corp., 755 F.3d 1367, 1372-73 (Fed. Cir. 2014) (“[W]e
`
`do not import limitations from the specification into the claims”); On-Line Techs.,
`
`Inc. v. Bodenseewerk Perkin-Elmer GmbH, 386 F.3d 1133, 1138 (Fed. Cir. 2004)
`
`(“[A] claim interpretation that excludes a preferred embodiment from the scope of
`
`the claim ‘is rarely, if ever, correct.’”). Petitioner insists its proposed construction
`
`must be correct because “in every embodiment of the specification related to
`
`restricting access to a sensitive API, this authorization scheme involves generating
`
`12
`
`

`

`IPR2017-01620
`
`Patent Owner’s Preliminary Response
`
`a digital signature using a private key corresponding to an entity with an interest in
`
`protecting access to the sensitive API.” Pet. at 10; see also id. at 10-13.
`
`As an initial matter, the Petition provides no explanation as to why an
`
`application developer is not or cannot be “an entity with an interest in protecting
`
`access to the sensitive API.” A legitimate application developer would have such
`
`an interest because, if access to sensitive APIs were not protected and malicious
`
`applications could freely access those sensitive APIs, mobile device users could be
`
`discouraged from downloading applications altogether—e.g., for fear of having
`
`malicious applications access those sensitive APIs and use them for a harmful
`
`purpose—which would negatively impact the legitimate application developer.
`
`And, in any event, it is well-settled that “it is not enough that the only
`
`embodiments, or all of the embodiments, contain a particular limitation to limit
`
`claims beyond their plain meaning.” Unwired Planet, LLC v. Apple Inc., 829 F.3d
`
`1353, 1359 (Fed. Cir. 2016) (quotations omitted). Nor does Petitioner explain why
`
`one entity (e.g., a mobile device manufacturer) could not both act as the code
`
`signing authority and develop its own applications.
`
`Finally, Petitioner argues that the ’868 patent specification disclaims digital
`
`signatures from application developers based on the specification’s description of
`
`how prior code signing schemes operated. Pet. at 9-10, 14. But nothing that
`
`Petitioner points to amounts to “words or expressions of manifest exclusion or
`
`13
`
`

`

`IPR2017-01620
`
`Patent Owner’s Preliminary Response
`
`restriction” that are required to constitute disclaimer. Unwired Planet, 829 F.3d at
`
`1358 (“A disclaimer or disavowal of claim scope must be clear and
`
`unmistakable….”). This is particularly true in view of other portions of the
`
`specification—which Petitioner ignores—that broadly describe the various entities
`
`that can digitally sign a software application. For example, the specification
`
`explains that the code signing authority that digitally signs an application can be
`
`anyone with “knowledge of the operation of the sensitive APIs to which the
`
`software application needs access.” Ex. 1001 at 4:31-35. Because the application
`
`developer creates the software application and determines to which APIs the
`
`application needs access for the application to operate as intended (Id. at 1:9-12),
`
`the application developer must have “knowledge of the operation of [those]
`
`sensitive APIs.” In addition, the specification explains that any “entity with an
`
`interest in protecting access to sensitive device APIs” may provide a digital
`
`signature for the software application. Id. at 3:54-61. And, as explained above, an
`
`application developer would certainly have an interest in protecting access to
`
`sensitive device APIs and fall within that category.
`
`Thus, there is no disclaimer and Petitioner’s construction should be rejected.
`
`IV. The Petition Fails to Meet the Requirements for Instituting an Inter
`Partes Review
`
`The Petition challenges two independent claims—claims 1 and 76—and
`
`asserts that those claims (along with various dependent claims that depend on
`14
`
`

`

`IPR2017-01620
`
`Patent Owner’s Preliminary Response
`
`claim 1 or 76) are anticipated by Lin. The remaining challenged claims all depend
`
`on either claim 1 or 76 and the Petition adds various secondary references to Lin to
`
`argue that the additional limitations in those dependent claims would have been
`
`obvious. The Petition does not argue obviousness for claims 1 or 76. Therefore,
`
`each asserted ground of patentability is based on Petitioner’s assertion that each
`
`and every limitation of claims 1 and 76 is either disclosed or inherent in Lin.
`
`As discussed further below, because Lin does not disclose various
`
`limitations that appear in claims 1 and 76, the Petition fails to demonstrate there is
`
`a reasonable likelihood that any of the challenged claims is unpatentable on any of
`
`the asserted grounds of unpatentability. Accordingly, the Petition should be
`
`denied.
`
`A. Overview of Lin (Ex. 1011)
`
`Lin, entitled “Method for Authenticating Java Archive (JAR) for Portable
`
`Devices,” was filed on July 11, 2000—just over two months before the earliest
`
`provisional application to which the ’868 patent claims priority was filed. Lin
`
`explains that prior art methods of authenticating whether an application originated
`
`from a trusted source were designed for desktop personal computers, but were not
`
`well-suited for small, portable devices (e.g., personal organizers and mobile
`
`communication devices) due to the limited memory resources available on the
`
`smaller mobile devices. Ex. 1011 at 1:40-58. In particular, Lin notes that
`
`15
`
`

`

`IPR2017-01620
`
`Patent Owner’s Preliminary Response
`
`compared to the limited memory resources of smaller mobile devices, the X.509
`
`certificates that were widely used for authentication on desktop computers are
`
`large files and that “since the certificate comes bundled with the application
`
`typically, the device must load both the application and the certificate.” Id. at
`
`1:50-56.
`
`Thus, Lin proposes solving the problem of downloading and authenticating
`
`the author of an application on a client device with limited computing resources by
`
`creating an application descriptor file (“ADF”) that is digitally signed by the
`
`application developer and contains information associated with an application and
`
`information against which the application can be authenticated. Ex. 1011 at 2:32-
`
`35. Unlike in the prior art, where the X.509 certificate was bundled with the
`
`application so that the device must load both, the signed ADF may be downloaded
`
`first onto the client device separately from the application. Id. at 4:66-5:1. Once
`
`the information in the signed ADF is verified by the client device using a public
`
`key, “the client device obtains the network location of the application code or JAR
`
`file, and transmits a request to the server, specifying the particular application
`
`desired” and downloads the application. Id. at 5:6-19. Lin also notes that a signed
`
`ADF is better suited for smaller mobile devices because a “signed ADF is
`
`substantially smaller than the presently used signed JAR file format because a
`
`signed JAR file includes all applications-related files, and is more desirable for use
`
`16
`
`

`

`IPR2017-01620
`
`Patent Owner’s Preliminary Response
`
`with computing devices with relatively limited resources.” Id. at 3:16-20. Once
`
`the signed ADF and application are verified, the application is granted access to all
`
`of the device resources the application and/or developer has permission to access.
`
`See, e.g., Id. at 3:12-14, 5:26-30.
`
`B.
`
`Lin Does Not Disclose “A Signed Software Application”
`
`Lin does not disclose that the software application is signed, as required by
`
`the plain language of the claims. Rather, 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. Ex. 1011 at 2:20-24. While
`
`the signed ADF has some association with a particular software application, Lin
`
`makes clear that the signed ADF is a separately downloadable component
`
`unattached to the software application. Id. at 3:4-5. For example, Lin discloses
`
`that the client device can first download and verify the signed ADF, and once the
`
`ADF is verified, then download the corresponding software application:
`
`Upon receiving the signed ADF, the client device verifies the developer
`certificate with the code signing certificate authority's public key (606).
`The client may also a