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

`

`IPR2017-01619 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`TABLE OF CONTENTS
`
`Table of Authorities ................................................. Error! Bookmark not defined.
`
`Exhibit List ................................................................................................................. v
`
`I.
`
`II.
`
`Introduction ...................................................................................................... 1
`
`The ’868 Patent ................................................................................................ 1
`
`A. Overview of the ’868 Patent .................................................................. 1
`
`B.
`
`Person of Ordinary Skill ........................................................................ 5
`
`III. Claim Construction .......................................................................................... 5
`
`A.
`
`B.
`
`“Signed Software Application” (All Claims) ........................................ 6
`
`“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” (All Claims) ........................................ 15
`
`C.
`
`“Sensitive API” (All Claims) / “Non-Sensitive API” (Claims 112 and
`139) ...................................................................................................... 16
`
`D.
`
`“Abridged Version of a Software Application” (Claim 86) ............... 21
`
`IV. Claims 1, 13, 76, 78, 81, 84, 85, 87, 88, 90-93, 95, 98, 100, 104, 108, 112,
`113, 137-39, and 142-44 Are Patentable Over Garst and Gong ................... 22
`
`A. Overview of Garst (Ex. 1012) ............................................................. 23
`
`B.
`
`C.
`
`Overview of Gong (Ex. 1016) ............................................................. 24
`
`Garst Fails to Disclose or Render Obvious a “Signed Software
`Application” (All Claims) ................................................................... 24
`
`i.
`
`Garst Discloses Signing a License String, Not a Software
`Application ................................................................................ 24
`
`i
`
`

`

`IPR2017-01619 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`ii.
`
`iii.
`
`Garst’s License Key Fails the Recognized Requirements of a
`Digital Signature when Applied to the Application Program ... 28
`
`It Would Not Have Been Obvious to Sign the Software
`Application Using the API Vendor’s Private Key .................... 33
`
`D. Garst and Gong Fail to Disclose a “Sensitive API” (All Claims) ....... 38
`
`i.
`
`ii.
`
`Garst Discloses Licensed APIs, Not “Sensitive APIs” ............. 39
`
`Petitioner Cannot Rely on its Catchall “Data Security”
`Argument to Show the Obviousness of a “Sensitive API” ....... 41
`
`E.
`
`The Petition Fails to Show Gong is a Printed Publication .................. 43
`
`i.
`
`Petitioner Fails to Show When Gong Was Publicly
`Accessible ................................................................................. 45
`
`ii.
`
`Petitioner Fails to Show Gong Was Sufficiently Indexed ........ 49
`
`F.
`
`Garst Fails to Disclose Allowing Access to Non-Sensitive APIs
`“Upon Verifying the Digital Signature” (Claim 112) ......................... 51
`
`V.
`
`Claims 77, 79, 80, and 82 Are Patentable Over Garst, Gong, and Davis ..... 52
`
`VI. Claim 86 Is Patentable Over Garst, Gong, and Sibert ................................... 55
`
`VII. Remaining Claims and Grounds .................................................................... 57
`
`VIII. Reservation of Rights .................................................................................... 57
`
`IX. Conclusion ..................................................................................................... 58
`
`Certificate Of Compliance ....................................................................................... 59
`
`Certificate Of Service............................................................................................... 60
`
`
`
`
`
`
`
`ii
`
`

`

`IPR2017-01619 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`TABLE OF AUTHORITIES
`
` Page(s)
`
`Cases
`ABS Global, Inc. v. Inguran, LLC,
`IPR2016-00927, Paper 33 (PTAB Oct. 2, 2017) .................................... 46, 47, 49
`Apple Inc. v. ContentGuard Holdings, Inc.,
`IPR2015-00443, Paper 9 (PTAB July 9, 2015) .................................................. 41
`Blue Calypso, LLC v. Groupon, Inc.,
`815 F.3d 1331 (Fed. Cir. 2016) .................................................................... 44, 49
`Coastal Indus., Inc. v. Shower Enclosures Am., Inc.,
`IPR2017-00573, Paper 9 (PTAB July 20, 2017) ................................................ 42
`In re Cronyn,
`890 F.2d 1158 (Fed. Cir. 1989) .......................................................................... 49
`Elec. Frontier Found. v. Personal Audio,
`LLC, IPR2014-00070, Paper 21 (PTAB Apr. 18, 2014) .................................... 44
`Graham v. John Deere Co. of Kansas City,
`383 U.S. 1 (1966) ................................................................................................ 42
`In re Klopfenstein,
`380 F.3d 1345 (Fed. Cir. 2004) .......................................................................... 43
`L-3 Comm. Holdings, Inc. v. Power Survey, LLC,
`IPR2014-00832, Paper 9 (PTAB Nov. 14, 2014) ............................................... 43
`In re Lister,
`583 F.3d 1307 (Fed. Cir. 2009) ........................................................ 44, 49, 50, 51
`Microsoft Corp. v. Proxyconn, Inc.,
`789 F.3d 1292 (Fed. Cir. 2015), overruled on other grounds, Aqua
`Products, Inc. v. Matal, 872 F.3d 1290 (Fed. Cir. 2017) (en banc) ..................... 5
`Oil States Energy Services, LLC v. Greene’s Energy Group, LLC,
`No. 2015-1855, 639 F. App’x 639 (Fed. Cir. May 4, 2016), cert.
`granted, No. 16-712 (U.S. June 12, 2017) ......................................................... 57
`
`iii
`
`

`

`IPR2017-01619 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`Square,
`CBM2014-00156, Paper 22 .......................................................................... 45, 46
`In re Suitco Surface, Inc.,
`603 F.3d 1255 (Fed. Cir. 2010) .......................................................................... 39
`Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc.,
`200 F.3d 795 (Fed. Cir. 1999) ............................................................................ 15
`Statutes
`35 U.S.C. § 102(b) ................................................................................................... 44
`35 U.S.C. § 311(b) ................................................................................................... 43
`35 U.S.C. § 312(a)(3) ............................................................................................... 42
`35 U.S.C. § 316(e) ..................................................................................................... 1
`Other Authorities
`37 C.F.R. § 42.6(a)(3) .............................................................................................. 36
`37 C.F.R. § 42.6(e), I ............................................................................................... 60
`37 C.F.R. § 42.24 ..................................................................................................... 59
`37 C.F.R. § 42.104(b)(4) .......................................................................................... 42
`37 C.F.R. § 42.123(a) ............................................................................................... 45
`
`
`
`
`
`
`iv
`
`

`

`IPR2017-01619 (US. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`EXHIBIT LIST
`
`n Exhibit Description
`2001 Declaration of Sharon Lee In Support of Patent Owner BlackBerry Ltd.’s
`Motion for Pro Hac Vice Admission
`
`2002 Declaration of Dr. George T. Ligler
`
`NEW
`
`2003
`
`CV of Dr. George T. Ligler
`
`NEW
`
`NEW
`
`2004 Deposition Transcript of Dr. Patrick D. McDaniel (Feb. 21, 2018)
`
`NEW
`
`2005 Webster’s NewWorld Dictionary (1984)
`
`
`
`

`

`IPR2017-01619 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`I.
`
`Introduction
`
`Patent Owner BlackBerry Limited (“Patent Owner”) submits this Response
`
`to the Petition for inter partes review (Paper 1, “Pet.”) of U.S. Patent No.
`
`8,489,868 (“’868 patent”). In its Institution Decision (Paper 9, “Dec.”), the Board
`
`instituted trial on eight grounds of unpatentability: (1) claims 1, 13, 76, 78, 81, 84,
`
`85, 87, 88, 90–93, 95, 98, 100, 104, 108, 112, 113, 137–39, and 142–44 as obvious
`
`over Garst and Gong; (2) claims 77, 79, 80, and 82 as obvious over Garst, Gong,
`
`and Davis; (3) claim 83 as obvious over Garst, Gong, and Chang; (4) claim 86 as
`
`obvious over Garst, Gong, and Sibert; (5) claim 89 as obvious over Garst, Gong,
`
`and Wong-Insley, and (6) claim 94 as obvious over Garst, Gong, and Haddock.
`
`Dec. 21. For the reasons discussed below, Petitioner Google LLC (“Petitioner”)
`
`has failed to meet its burden of proving, by a preponderance of the evidence, that
`
`any of the challenged claims are unpatentable. See 35 U.S.C. § 316(e).
`
`II. The ’868 Patent
`A. 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
`
`1
`
`

`

`IPR2017-01619 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`20, 2001. Petitioner does not dispute that the ’868 patent is entitled to its
`
`September 21, 2000 priority date. See Pet. 3.
`
`The ’868 patent is generally directed to security protocols involving
`
`software code signing schemes for mobile devices. Ex. 1001, 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., 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 that
`
`destructive, ‘Trojan horse’ type software applications may be downloaded and
`
`installed onto a mobile device.” Id., 1:39-43. The ’868 patent explains that among
`
`a device’s APIs, certain APIs are classified as “sensitive” because they may expose
`
`functionality that is particularly vulnerable to a virus or malicious code in a device
`
`software application. Id., 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., 3:50-54.
`
`Importantly, the ’868 patent further explains that an API on a device may be
`
`classified as a “sensitive” API if, for example, the mobile device manufacturer,
`
`API author, wireless network operator, device owner or operator, or some other
`
`2
`
`

`

`IPR2017-01619 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`entity could be adversely impacted should a virus or malicious program access the
`
`API. Ex. 1001, 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:
`
`
`
`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, 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
`
`3
`
`

`

`IPR2017-01619 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`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., 4:24-
`
`43, 3:62-4:12. The signed software application Y 22 may then be downloaded by
`
`mobile device 28. Id., 4:56-58.
`
`Id., Fig. 1.
`
`
`
`Once a digitally signed software application with an appended digital
`
`signature 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, 4:66-5:3. The ’868 patent also teaches that a
`
`software application may be signed with multiple signatures. For example, where
`
`a software application is signed with multiple signatures “all APIs are restricted
`
`4
`
`

`

`IPR2017-01619 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`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., 4:1-
`
`12. The ’868 patent also discloses that the device may display a message to the
`
`user before the software application accesses a sensitive API thereby giving the
`
`user final control to grant or deny access to the sensitive API. Id., 8:11-18, 9:45-
`
`51.
`
`B.
`
`Person of Ordinary Skill
`
`One of ordinary skill in the field of the ’868 patent 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. Declaration of Dr. George T. Ligler (Ex. 2002), ¶¶35-38.
`
`III. Claim Construction
`
`Under the broadest reasonable interpretation standard, claims are evaluated
`
`using the plain and ordinary meaning of their words from the perspective of a
`
`person of ordinary skill in the art in the context of the entire patent disclosure.
`
`Microsoft Corp. v. Proxyconn, Inc., 789 F.3d 1292, 1298 (Fed. Cir. 2015) (“A
`
`construction that is ‘unreasonably broad’ and which does not ‘reasonably reflect
`
`the plain language and disclosure’ will not pass muster.”), overruled on other
`
`grounds, Aqua Products, Inc. v. Matal, 872 F.3d 1290 (Fed. Cir. 2017) (en banc).
`
`5
`
`

`

`IPR2017-01619 (US. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`A.
`
`“Signed Software Application” (All Claims)
`
`Independent claims 1 and 76 recite a “determining, at the mobile device,
`
`whether the software application is signed, wherein a signed software application
`
`includes a digital signature
`
`Petitioner does not offer an explicit construction
`
`of “signed software application,” but offers an implicit construction: “Claims 1 and
`
`76 do not recite that the ‘digital signature’ is generated by applying the private key
`
`to application code,” and instead “may be generated by applying the private key to
`
`‘information,’” of which “software application” is just an example. Pet. 25 n. 10
`
`(citing Ex. 1001, 4:45-55).
`
`Petitioner’s reliance on the specification is misplaced because, while the
`
`specification identifies “software application” as an example of “information,” the
`
`challenged claims require the “software application” to be signed, not merely
`
`signed “information.” Petitioner apparently argues that the claims merely require
`
`“software application” that “includes a digital signature.” Petitioner’s proposed
`
`construction of the claimed “determining” step confirms this apparent
`
`interpretation because it omits much of the language of that step:
`
`Claims 1 and 76
`
`Petitioner’s Construction,
`Relative to Claims 1 and 76
`
`generated using a private key of a
`
`determining, at the mobile device,
`whether the software application is
`signed, wherein a signed software
`application includes a digital signature
`
`determining, at the mobile device,
`whether the software application is
`Signed—wherem-a-Si-gned-sofiwaie
`'
`includes a digital signature
`
`

`

`IPR2017-01619 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`generated using a private key of a
`private key-public key pair
`
`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
`
`See Pet. 7-14.1 Petitioner’s apparent construction ignores the explicit language of
`
`the claim, and is contrary to both the intrinsic and extrinsic record, as explained
`
`below.
`
`The claims recite a “signed software application,” i.e., a software application
`
`that is itself signed. A signature that just happens to be included in or with the
`
`software application is insufficient to meet the claims unless that the signature is of
`
`the software application. A software application that merely includes a signature
`
`of information other than the software application would not be considered a
`
`“digital signature” of that software application in the eyes of a POSA. In the
`
`context of the claims from the perspective of a POSA, this means the signature is
`
`generated from the software application or a unique transformation of the software
`
`
`
`1 Petitioner does not explain or justify this omission in its analysis of its proposed
`
`construction, which exclusively relates to the “corresponding to” language it adds.
`
`Patent Owner responds to that language separately below. See § III.B below.
`
`7
`
`

`

`IPR2017-01619 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`application, e.g., a hash or the ’868 patent’s abridging function. Ex. 2002, ¶¶42-
`
`44.
`
`This requirement is consistent with—and mandated by—the language of the
`
`claims: “determining … whether the software application is signed, wherein a
`
`signed software application includes a digital signature,” and also “digital signature
`
`of the software application.” These limitations explicitly link the claimed digital
`
`signature as the signature of the software application, not some other piece of
`
`information. The claims expressly require the software application be digitally
`
`signed.
`
`The ’868 patent’s discussion of signed software applications confirms Patent
`
`Owner’s interpretation. Ex. 2002, ¶¶45-47. Every example of generating a signed
`
`message or a signed software application in the ’868 patent involves signing the
`
`information to be signed or a unique transformation of that information, such as a
`
`hash or abridged version. Id.2 The intrinsic record thus supports the plain meaning
`
`of the claimed “signed software application”: the software application is itself
`
`signed. For example, the ’868 patent describes the process used to create a digital
`
`signature:
`
`
`
`2 The ’868 patent’s disclosure of signing an abridged version of a software
`
`application is further explained below. See § III.D.
`
`8
`
`

`

`IPR2017-01619 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`For example, according to one signature scheme, a hash of the
`software application Y 14 may be generated, using a hashing
`algorithm such as the Secure Hash Algorithm SHA1, and then used
`with the private signature key 18 to create the digital signature. In
`some signature schemes, the private signature key is used to encrypt a
`hash of information to be signed, such as software application Y 14,
`whereas in other schemes, the private key may be used in other ways
`to generate a signature from the information to be signed or a
`transformed version of the information.
`
`Ex. 1001, 4:36-55 (emphasis added). Here, the information to be signed is used as
`
`an input into a digital signature process, which then generates a signature from the
`
`information to be signed. Id. One example of information that may be signed is a
`
`software application, which is the example claimed by claims 1 and 76 of the ’868
`
`patent.
`
`Figure 1 further confirms this understanding, and illustrates using
`
`“Application Y” as an input into the signing process (Code signer 16) to generate
`
`“Signed Application Y,” meaning that a signed application is generated from the
`
`application itself:
`
`9
`
`

`

`IPR2017-01619 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`
`
`Ex. 1001, Fig. 1. This process could also involve signing a unique transformation
`
`of application Y, such as a hash or abridged version, to achieve the same result: a
`
`signed application. Ex. 2002, ¶47.
`
`Petitioner’s apparent construction of “signed software application” as
`
`including any digital signature is contrary to the disclosure in the ’868 patent and
`
`the claims themselves. Ex. 2002, ¶¶48. While the ’868 patent states that a
`
`software application is one example of information that may be signed, the claims
`
`require signing a software application. The portion on column 4 lines 45-55
`
`describes digital signature algorithms generally, which of course may be applied to
`
`all types of information, including messages, emails, and software applications.
`
`10
`
`

`

`IPR2017-01619 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`Ex. 1001, 4:45-55; Ex. 2002, ¶49. Claims 1 and 76 of the ’868 patent, however,
`
`specifically claim a “signed software application” rather than “signed
`
`information.” Petitioner’s efforts to conflate “software application” with
`
`“information” should be rejected.
`
`Petitioner’s apparent construction is also inconsistent with the ’868 patent’s
`
`teaching that a signature is generated from the information to be signed. Ex. 2002,
`
`¶50. The ’868 patent explains that, in some signature schemes, “the private
`
`signature key is used to encrypt a hash of information to be signed, such as a
`
`software application.” Ex. 1001, 4:45-55. The ’868 patent then explains that
`
`certain other schemes allow “the private key [] be used in other ways to generate a
`
`signature from the information to be signed or a transformed version of the
`
`information.” Id. (emphasis added). In every case, the information to be signed is
`
`used to generate the signature, such that a signature of a software application
`
`would be generated from the software application itself or a unique transformation
`
`of that software, application such as a hash or abridged version. Ex. 2002, ¶50.
`
`Petitioner’s apparent construction is thus inconsistent with both the language of the
`
`claims and the intrinsic record.
`
`The extrinsic record and the testimony of Petitioner’s expert, Dr. McDaniel,
`
`further confirm Patent Owner’s construction. Ex. 2002, ¶¶51-58. Dr. McDaniel
`
`testified that digital signatures are generated based on “the thing you’re signing,”
`
`11
`
`

`

`IPR2017-01619 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`even if “the thing you’re actually using a private key on might be a derivative of a
`
`particular document.” Ex. 2004, 62:15-63:22. In the context of a JAR file, Dr.
`
`McDaniel explained that a signed JAR file is created by using the JAR file as an
`
`input into the signing function. Ex. 2004, 71:19-73:25, 75:25-76:7.
`
`Dr. McDaniel also explained that the “Technological Background” section
`
`of his declaration provides a foundation for what a POSA would have understood
`
`about digital signatures in September 2000. Ex. 2004, 54:12-19; id., 54:20-57:2,
`
`69:15-25. In that section, Dr. McDaniel described a set of five requirements for
`
`digital signatures. Ex. 1002, ¶39; Ex. 2004, 60:2-10. Both experts agree that a
`
`(valid) public-key digital signature is authentic, unforgeable, not reusable with
`
`other software applications, renders the software application unalterable, and
`
`cannot be repudiated. Ex. 1002, ¶39; Ex. 2002, ¶¶51-52; see Ex. 1009, 34-35.3
`
`These requirements confirm that the “signed software application” cannot merely
`
`include the digital signature of something else. Ex. 2002, ¶52.
`
`For example, if a signed software application merely included a signature of
`
`something other than the software application, then someone could reuse the
`
`
`
`3 Dr. McDaniel explained that the ’868 patent’s use of “digital signature” was
`
`consistent with the five requirements of digital signatures he listed in his
`
`declaration. Ex. 2004, 126:25-129:13, 130:23-131:7.
`
`12
`
`

`

`IPR2017-01619 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`signature among multiple applications. Id., ¶53; see Ex. 1009, 35 (“3. The
`
`signature is not reusable. The signature is part of the document; an unscrupulous
`
`person cannot move the signature to a different document.”). It would not be a
`
`signature of the software application—and would be reusable—if the signature did
`
`not depend on the specific composition or content of the software application. Ex.
`
`2002, ¶53; Ex. 2004, 62:15-63:22 (Dr. McDaniel explaining that the not-reusable
`
`requirement means that you “couldn’t take the signature and put it with a different
`
`document and then it would be a signature of that document.”).
`
`As another example, if a signed software application merely included a
`
`signature of something other than the software application itself, then someone
`
`could alter the software application after the signature was generated without
`
`needing to generate a new signature. Id., ¶54; see Ex. 1009, 35 (“4. The signed
`
`document is unalterable. After the document is signed, it cannot be altered.”).
`
`Both experts agree that a software application that merely includes a signature of
`
`something else is not “signed” by a digital signature. Ex. 2002, ¶¶51-52; Ex. 2004,
`
`67:19-68:13 (Dr. McDaniel explaining that the unalterable requirement means “if
`
`you modify the thing you’re singing, the signature will no longer be valid.”).
`
`Patent Owner’s construction is further confirmed by Petitioner’s prior art.
`
`Ex. 2002, ¶¶55-59. The prior art consistently uses digital signatures and signed
`
`information with the meaning that Patent Owner proposes, rather than the broader
`
`13
`
`

`

`IPR2017-01619 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`meaning that Petitioner apparently proposes. Id. For example, Garst (Ex. 1012)
`
`explains that a “digital signature is used to authenticate an electronic message and
`
`to determine whether an electronic message has been altered.” Ex. 1012, 5:25-29.
`
`Garst explains that a signed message includes a signature that allows a recipient to
`
`verify that the message was not modified:
`
`To verify the authenticity of a digitally signed message, the recipient
`obtains the electronic message and the digital signature of the sender.
`… The verification process verifies that the electronic message was
`(1) digitally signed by the sender, and (2) that the electronic message
`content was not changed from the time that it was signed to the time
`that the digital signature was verified.
`
`Ex. 1012, 5:47-57. This is consistent with the idea that a “signed message” is a
`
`message that is itself signed, and not just a message that includes a signature of
`
`information other than the message. Ex. 2002, ¶¶56-57. Gong likewise discusses
`
`signing JAR files as a whole or on a class file-by-class file basis, but in each case
`
`the information that is signed is used as an input to the signing process. Ex. 2002,
`
`¶58; e.g., Ex. 1016, 27, 42, 143. Finally, Lin refers to signed timestamps, a signed
`
`application descriptor file, and a signed hash. Ex. 1011, 4:8-20, 5:6-12, 5:45-48.
`
`In short, the ’868 patent and the extrinsic record are unambiguous: a POSA
`
`would understand a signed software application to be a software application that is
`
`14
`
`

`

`IPR2017-01619 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`signed, i.e., the signature is of the software application or a unique transformation
`
`of the software application, such as a hash or an abridging function.
`
`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” (All Claims)
`
`In its Petition, Petitioner proposed a construction of this term 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-14. Petitioner’s focus in advancing this construction is the “corresponding
`
`to” requirement. See id. Petitioner argues, however, that “the prior art discloses
`
`the challenged claims under” its construction or a broader construction. Pet. 14.
`
`Because Petitioner’s “corresponding to” requirement does not appear relevant to
`
`the issues raised in this proceeding, the Board need not determine the construction
`
`of the broader “determining” phrase as suggested by Petitioner. See Vivid Techs.,
`
`Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999) (terms need only
`
`be construed to resolve a controversy and only to the extent necessary to resolve
`
`the controversy).
`
`15
`
`

`

`IPR2017-01619 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`C.
`
` “Sensitive API” (All Claims) / “Non-Sensitive API” (Claims 112
`and 139)
`
`The broadest reasonable interpretation of a “sensitive API” is an API
`
`classified as implicating a security concern.4 Ex. 2002, ¶¶61-67. The broadest
`
`reasonable interpretation of a “non-sensitive API” is likewise an API that is not
`
`classified as implicating a security concern. See id., ¶68. The term “sensitive
`
`API” is not a term of art in this context, and the ’868 patent uses the word
`
`“sensitive” as a classification for certain APIs compared to non-sensitive APIs that
`
`do not implicate the same 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 APIs may be
`
`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
`
`
`
`4 Patent Owner’s Preliminary Response proposed that “sensitive API” was an API
`
`that implicated a security concern relative to non-sensitive APIs. Paper 8 at 6.
`
`Patent Owner clarifies this construction to reflect the ’868 patent’s discussion of
`
`“sensitive APIs” as a classification of APIs that implicate security concerns.
`
`16
`
`

`

`IPR2017-01619 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`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. Ex. 2002,
`
`¶¶62-63. The ’868 patent, therefore, describes numerous ways of protecting APIs
`
`classified as sensitive, including, 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).
`
`The ’868 patent explains that “any API may be classified as sensitive by a
`
`mobile device manufacturer, or possibly by an API author, a wireless network
`
`operator, or device owner or operator, or some other entity that may be affected by
`
`a virus or malicious code in a device software application.”