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-01619
`U.S. Patent No. 8,489,868
`
`––––––––––––––––––
`
`PATENT OWNER’S PRELIMINARY RESPONSE
`
`
`
`

`

`IPR2017-01619
`
`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 the Principal References ................................................. 15
`
`i.
`
`ii.
`
`Garst (Ex. 1012) ........................................................................ 15
`
`Gong (Ex. 1016) ........................................................................ 16
`
`B.
`
`The Petition Fails to Show Gong is a Printed Publication .................. 16
`
`i.
`
`ii.
`
`iii.
`
`Petitioner Fails to Show When Gong Was Publicly
`Accessible ................................................................................. 18
`
`Petitioner Fails to Show Gong Was Sufficiently Indexed ........ 21
`
`Petitioner Relies Exclusively on Inadmissible Hearsay ........... 23
`
`C.
`
`Garst and Gong Fail to Disclose “a Sensitive API” ............................ 24
`i
`
`

`

`IPR2017-01619
`
`Patent Owner’s Preliminary Response
`
`i.
`
`i.
`
`Petitioner’s Analysis Reads “Sensitive” Out of the Claims ..... 25
`
`Garst In View Of Gong Does Not Render “Sensitive API”
`Obvious ..................................................................................... 27
`
`V.
`
`Conclusion ..................................................................................................... 29
`
`Certificate Of Compliance ....................................................................................... 31
`
`Certificate Of Service............................................................................................... 32
`
`
`
`
`
`
`
`
`
`ii
`
`

`

`IPR2017-01619
`
`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) .......................................... 19, 22
`Apple Inc. v. ContentGuard Holdings, Inc.,
`IPR2015-00443, Paper 9 (PTAB July 9, 2015) .................................................. 27
`Blue Calypso, LLC v. Groupon, Inc.,
`815 F.3d 1331 (Fed. Cir. 2016) .................................................................... 17, 21
`Coastal Indus., Inc. v. Shower Enclosures Am., Inc.,
`IPR2017-00573, Paper 9 (PTAB July 20, 2017) ................................................ 28
`In re Cronyn,
`890 F.2d 1158 (Fed. Cir. 1989) .......................................................................... 22
`Elec. Frontier Found. v. Personal Audio,
`LLC, IPR2014-00070, Paper 21 (PTAB Apr. 18, 2014) .................................... 17
`Graham v. John Deere Co. of Kansas City,
`383 U.S. 1 (1966) ................................................................................................ 28
`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) .......................................................................... 16
`L-3 Comm. Holdings, Inc. v. Power Survey, LLC,
`IPR2014-00832, Paper 9 (PTAB Nov. 14, 2014) ............................................... 16
`In re Lister,
`583 F.3d 1307 (Fed. Cir. 2009) ........................................................ 17, 21, 22, 23
`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) ............................................. 24
`iii
`
`

`

`IPR2017-01619
`
`Patent Owner’s Preliminary Response
`
`ServiceNow, Inc. v. Hewlett-Packard Co.,
`IPR2015-00716, Paper 13 (PTAB Aug. 2, 2015) ............................................... 24
`Square, Inc. v. Unwired Planet, LLC,
`CBM2014-00156, Paper 22 (PTAB Feb. 26, 2015) ....................................... 1, 18
`In re Suitco Surface, Inc.,
`603 F.3d 1255 (Fed. Cir. 2010) .......................................................................... 25
`Unwired Planet, LLC v. Apple Inc.,
`829 F.3d 1353 (Fed. Cir. 2016) .......................................................................... 13
`Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc.,
`200 F.3d 795 (Fed. Cir. 1999) ............................................................................ 11
`Statutes
`35 U.S.C. § 102(b) ................................................................................................... 17
`35 U.S.C. § 311(b) ................................................................................................... 16
`35 U.S.C. § 312(a)(3) ............................................................................................... 28
`Other Authorities
`37 C.F.R. § 42.100(b) ................................................................................................ 8
`37 C.F.R. § 42.104(b)(4) .......................................................................................... 28
`37 C.F.R. § 42.107 ..................................................................................................... 1
`Fed. R. Evid. 801 ..................................................................................................... 24
`
`
`
`
`iv
`
`

`

`IPR2017-01619
`
`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-95, 98, 100, 104, 108, 112, 113,
`
`137-39, and 142-44 across six different grounds, each of which relies on U.S.
`
`Patent No. 6,188,995 (“Garst”) and “Inside Java 2 Platform Security Architecture”
`
`(“Gong”). As explained below, trial should not be instituted because the Petition
`
`fails in at least two independent ways—each of which is fatal to the Petition.
`
`First, Petitioner fails to show that Gong is prior art to the ’868 patent.
`
`Petitioner exclusively relies on unexplained citations to copyright dates or library
`
`date stamps, and does not justify how these dates show when Gong was publicly
`
`accessible. See Square, Inc. v. Unwired Planet, LLC, CBM2014-00156, Paper 22
`
`at 6-7 (PTAB Feb. 26, 2015). Nor does Petitioner offer any evidence of the
`
`cataloging or indexing practices of the libraries that purportedly added the relied
`
`upon date stamps.
`
`Second, Garst as combined with Gong does not disclose a “sensitive API,”
`
`i.e., one that implicates additional security concerns relative to a non-sensitive API.
`
`Although Garst discloses APIs with access restrictions, it does not disclose any
`
`other APIs with either greater or lesser security concerns or access restrictions.
`
`1
`
`

`

`IPR2017-01619
`
`Patent Owner’s Preliminary Response
`
`Without any differential in security concerns, Petitioner fails to explain how the
`
`Garst APIs are “sensitive” in the context of the ’868 patent. And Petitioner’s
`
`reliance on Gong for its catchall “data security” obviousness position cannot save
`
`the deficiencies of its “sensitive API” analysis. For either 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
`
`were not “secure and rely solely on the judgment of the user, there is a serious risk
`
`2
`
`

`

`IPR2017-01619
`
`Patent Owner’s Preliminary Response
`
`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-01619
`
`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-01619
`
`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-01619
`
`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 and institution should be denied.
`
`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-01619
`
`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, 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-01619
`
`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-01619
`
`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-01619
`
`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 7-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-01619
`
`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,
`
`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
`
`
`
`1 Petitioner urges the Board to adopt its proposed construction, but at the same time
`
`asserts that the construction is irrelevant to the Garst and Gong grounds. Pet. at 5
`
`(arguing that “this petition … relies on prior art that discloses the claims under
`
`both interpretations of the ‘determining’ phrase”), 14 (arguing the present petition
`
`“demonstrates how the prior art discloses the challenged claims under []
`
`Petitioner’s and PO’s interpretations”). Thus, Petitioner effectively concedes that
`
`the construction of “determining” is irrelevant to this proceeding, so it need not be
`
`construed. See Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803
`
`(Fed. Cir. 1999) (only those terms which are in controversy need to be construed,
`
`and only to the extent necessary to resolve the controversy).
`
`
`
`11
`
`

`

`IPR2017-01619
`
`Patent Owner’s Preliminary Response
`
`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
`
`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
`
`12
`
`

`

`IPR2017-01619
`
`Patent Owner’s Preliminary Response
`
`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
`
`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
`
`13
`
`

`

`IPR2017-01619
`
`Patent Owner’s Preliminary Response
`
`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 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
`
`claim 1 or 76) are rendered obvious over Garst in view of Gong. The remaining
`
`challenged claims all depend on either claim 1 or 76 and the Petition adds various
`
`secondary references to Garst and Gong to argue that the additional limitations in
`
`those dependent claims would have been obvious. As discussed further below,
`
`because Petitioner has failed to show that Gong is prior art to the ’868 patent and
`
`the Garst and Gong combination does not disclose the claimed “sensitive API” in
`14
`
`

`

`IPR2017-01619
`
`Patent Owner’s Preliminary Response
`
`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 the Principal References
`
`i.
`
`Garst (Ex. 1012)
`
`Garst, entitled “Method and Apparatus for Enforcing Software Licenses,”
`
`was filed on July 28, 1997, and is directed toward methods of enforcing software
`
`licenses for resource libraries such as application program interfaces (API). Ex.
`
`1012 at Abstract, [22], [54]. Garst explains that in prior art licensing schemes, a
`
`resource library can be used with multiple end user programs, so once the end user
`
`receives a copy of a resource library, the resource library vendor would not receive
`
`additional revenue when the vendor’s resource library is used with additional end
`
`user programs. Id. at 2:29-54. Garst’s solution is to provide a “per-program”
`
`licensing scheme for a resource library where the library is licensed only for use
`
`with particular software programs. Id. at 2:57-3:6. Certain licenses are provided
`
`with digital signatures to authenticate the license text string, and only programs
`
`having authentic and unaltered license text strings are able to access the resource
`
`library. Id. at 3:7-26. Garst’s resource library vendor digitally signs the “license
`
`text string,” and a resource library licensing module is used to verify that the
`
`license is correct. Id. at 5:30-61.
`
`15
`
`

`

`IPR2017-01619
`
`Patent Owner’s Preliminary Response
`
`ii.
`
`Gong (Ex. 1016)
`
`Gong purports to be a book entitled “Inside Java 2 Platform Security:
`
`Architecture, API Design, and Implementation.” Ex. 1016 at Cover. It discusses
`
`computer and network security, basic security for the Java language, the JDK 1.2
`
`security architecture, object security, and programming cryptography. Id. at v-ix.
`
`Gong briefly references the use of “Java technology” on “personal digital assistants
`
`(PDAs)” and “cellphones.” Id. at 242. Gong explains several basic security
`
`techniques in the context of the Java language, id. at 21-31, before introducing the
`
`JDK 1.2 Security Architecture. Id. at 33. Gong asserts that this architecture is a
`
`“fine-grained access-control security” scheme where “attempts to access protected
`
`resources will invoke security checks that will compare the granted permissions
`
`with the permissions needed for the attempted access.” Id. at 37.
`
`B.
`
`The Petition Fails to Show Gong is a Printed Publication
`
`Petitioner has failed to advance sufficient evidence to show that Gong is a
`
`prior art printed publication. Prior art relied on in a petition for inter partes review
`
`may only consist of “patents or printed publications.” 35 U.S.C. § 311(b). The
`
`burden was on Petitioner to establish that Gong, which is not a patent and a named
`
`reference in every ground, was “sufficiently accessible to the public interested in
`
`the art.” In re Klopfenstein, 380 F.3d 1345, 1348 (Fed. Cir. 2004); see L-3 Comm.
`
`Holdings, Inc. v. Power Survey, LLC, IPR2014-00832, Paper 9 at 12 (PTAB Nov.
`
`16
`
`

`

`IPR2017-01619
`
`Patent Owner’s Preliminary Response
`
`14, 2014) (“The party seeking to introduce the reference ‘should produce sufficient
`
`proof of its dissemination or that it has otherwise been available and accessible to
`
`persons concerned with the art to which the document relates and thus most likely
`
`to avail themselves of its contents.’” (citation omitted)); Elec. Frontier Found. v.
`
`Personal Audio, LLC, IPR2014-00070, Paper 21 at 20-24 (PTAB Apr. 18, 2014).
`
`The Petition asserts that Gong qualifies as prior art under “at least [] 35
`
`U.S.C. § 102(b).” Pet. at 4. To prove Gong is a printed publication under § 102,
`
`Petitioner must prove that Gong was publicly available prior to September 21,
`
`2000—the ’868 patent’s uncontested priority date. Blue Calypso, LLC v. Groupon,
`
`Inc., 815 F.3d 1331, 1348 (Fed. Cir. 2016). “A reference will be considered
`
`publicly accessible if it was 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.” Id. at 1348 (internal quotations omitted). This
`
`is particularly true in the context of prior art purportedly available in a library. See
`
`In re Lister, 583 F.3d 1307, 1312 (Fed. Cir. 2009) (“In short, we must consider all
`
`of the facts and circumstances surrounding the disclosure and determine whether
`
`an interested researcher would have been sufficiently capable of finding the
`
`reference and examining its contents.”).
`
`Petitioner has failed to