`
`
`
`
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`_________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`_________________
`
`GOOGLE LLC,
`Petitioner,
`
`v.
`
`BLACKBERRY LTD.,
`Patent Owner.
`
`_________________
`
`Case IPR2017-01620
`Patent 8,489,868 B2
`_________________
`
`PETITIONER’S REPLY
`
`
`
`
`
`
`

`

`IPR2017-01620
`Patent 8,489,868 B2
`
`
`
`I.
`
`INTRODUCTION ........................................................................................... 1
`
`TABLE OF CONTENTS
`
`II.
`
`CLAIM CONSTRUCTION ............................................................................ 1
`
`III. THE CHALLENGED CLAIMS ARE OBVIOUS ......................................... 2
`
`A.
`
`Lin’s Description of Figures 2 and/or 6 Discloses a “Signed
`Software Application” That Includes a “Digital Signature” ................. 2
`
`1.
`
`2.
`
`3.
`
`Lin’s Description of Figure 6 ...................................................... 2
`
`Lin’s Description of Figures 2 and 6 .......................................... 5
`
`A POSA Would at Once Envisage the Claimed
`Arrangement ................................................................................ 7
`
`B.
`
`C.
`
`Lin Discloses Allowing Access to Resources “Based Upon
`Verifying the Digital Signature” ........................................................... 8
`
`Lin Discloses “Wherein the Private Key Is Not Accessible to
`the Mobile Device” .............................................................................11
`
`D.
`
`Lin Discloses Claims 78 and 81 ..........................................................13
`
`E.
`
`F.
`
`G.
`
`H.
`
`I.
`
`J.
`
`Lin Discloses Claims 85 and 104 ........................................................14
`
`Lin Discloses Claim 95 .......................................................................15
`
`The Lin-Garst Combination Discloses Claims 13 and 88 ..................15
`
`The Lin-Garst Combination Discloses Claim 98 ................................16
`
`The Lin-Davis Combination Discloses Claims 77, 79, and 82 ...........17
`
`The Lin-Sibert Combination Discloses Claim 86 ...............................18
`
`K.
`
`The Lin-Gong Combination Discloses Claim 112 ..............................20
`
`IV. GONG WAS PUBLICLY AVAILABLE .....................................................21
`
`CONCLUSION ..............................................................................................25
`
`V.
`
`
`i
`
`

`

`IPR2017-01620
`Patent 8,489,868 B2
`
`
`Federal Cases
`
`TABLE OF AUTHORITIES
`
` Page(s)
`
`Blue Calypso, LLC v. Groupon, Inc.,
`815 F.3d 1331 (Fed. Cir. 2016) ............................................................................ 7
`
`Ford Motor Co. v. Cruise Control Techs. LLC,
`No. IPR2014-00291, Paper 44 (PTAB June 29, 2015) ...................................... 22
`
`Jazz Pharms., Inc. v. Amneal Pharms., LLC,
`No. 17-1671, 2018 WL 3400764 (Fed. Cir. Jul. 13, 2018) ................................ 23
`
`SRI Int’l, Inc. v. Internet Sec. Sys.,
`511 F.3d 1186 (Fed. Cir. 2008) .......................................................................... 23
`
`Voter Verified, Inv. v. Premier Election Solutions, Inc.,
`698 F.3d 1374 (Fed. Cir. 2012) .......................................................................... 25
`
`
`
`
`
`ii
`
`

`

`IPR2017-01620
`Patent 8,489,868 B2
`
`
`Ex. 1001 U.S. Patent No. 8,489,868
`
`LIST OF EXHIBITS
`
`
`Ex. 1002 Declaration of Patrick D. McDaniel, Ph.D.
`
`Ex. 1003 Curriculum Vitae of Patrick D. McDaniel, Ph.D.
`
`Ex. 1004 Prosecution History of U.S. Patent No. 8,489,868
`
`Ex. 1005 U.S. Provisional Application No. 60/270,663
`
`Ex. 1006 U.S. Provisional Application No. 60/235,354
`
`Ex. 1007 U.S. Provisional Application No. 60/234,152
`
`Ex. 1008 The Authoritative Dictionary of IEEE Standards Terms, IEEE Std.
`100-2000 (7th ed. 2000)
`Ex. 1009 Bruce Schneier, “Applied Cryptography” (2nd ed. 1996)
`
`Ex. 1010 BlackBerry’s First Amended Complaint, BlackBerry LTD. v. Blu
`Products, Inc., Case No. 1:16-cv-23535 (S.D. Fla.)
`Ex. 1011 U.S. Patent No. 6,766,353 (“Lin”)
`
`Ex. 1012 U.S. Patent No. 6,188,995 (“Garst”)
`
`Ex. 1013 U.S. Patent No. 5,844,986 (“Davis”)
`
`Ex. 1014 U.S. Patent No. 5,724,425 (“Chang”)
`
`Ex. 1015 U.S. Patent No. 7,243,236 (“Sibert”)
`
`Ex. 1016 Li Gong, “Inside Java 2 Platform Security Architecture: Cryptography,
`APIs, and Implementation” (1999) (“Gong”)
`Ex. 1017 U.S. Patent No. 6,131,166 (“Wong-Insley”)
`
`Ex. 1018 U.S. Patent No. 5,657,378 (“Haddock”)
`
`Ex. 1019 U.S. Provisional Patent Application No. 60/146,426
`
`Ex. 1020 Gary McGraw et al., “Securing Java” (1999)
`
`Ex. 1021 U.S. Patent No. 6,298,354 (“Saulpaugh”)
`
`iii
`
`

`

`IPR2017-01620
`Patent 8,489,868 B2
`
`Ex. 1022 U.S. Patent No. 5,680,619 (“Gudmundson”)
`
`Ex. 1023 U.S. Patent No. 5,421,013 (“Smith”)
`
`Ex. 1024 Dorothy E. Denning, “Cryptography and Data Security” (1982)
`
`Ex. 1025 U.S. Patent No. 5,845,282 (“Alley”)
`
`Ex. 1026 PCT Publication No. WO 97/09813 (“Nguyen”)
`
`Ex. 1027 PCT Publication No. WO 99/41520 (“Huang”)
`
`Ex. 1028 Scott Oaks, “Java Security” (Feb. 1999)
`
`Ex. 1029 U.S. Patent No. 6,721,809 (“Roy”)
`
`Ex. 1030 U.S. Patent No. 6,678,887 (“Hallman”)
`
`Ex. 1031 David Flanagan, “Java in a Nutshell” (Nov. 1999)
`
`Ex. 1032 Bill Venners, “Inside the Java 2 Virtual Machine” (1999)
`
`Ex. 1033 NCSU Libraries Online Catalog: Inside Java 2 Platform Security:
`Architecture, API Design, and Implementation,
`http://catalog.lib.ncsu.edu/record/NCSU1050269
`
`Ex. 1034 MARC 21 Format for Bibliographic Data: 050: Library of Congress
`Call Number, http://www.loc.gov/marc/bibliographic/bd050.html
`
`Ex. 1035 MARC 21 Format for Bibliographic Data: 005: Date and Time of
`Latest Transaction, http://www.loc.gov/marc/bibliographic/bd005.html
`
`Ex. 1036 NCSU Cataloging Policies & Procedures, Symphony Policy tools,
`Sirsi-Batch loading,
`https://staff.lib.ncsu.edu/confluence/display/MNC/Sirsi-Batch+loading
`
`Ex. 1037 Li Gong, “Inside Java 2 Platform Security Architecture: Cryptography,
`APIs, and Implementation” (1999) (Library of Congress excerpts)
`
`Ex. 1038 NCSU Libraries Online Catalog: Inside Java 2 Platform Security:
`Architecture, API Design, and Implementation,
`https://catalog.lib.ncsu.edu/record/NCSU1050269
`
`iv
`
`

`

`IPR2017-01620
`Patent 8,489,868 B2
`
`Ex. 1039 Amazon.com: A Glance: Inside Java 2 Platform Security:
`Architecture, API Design, and Implementation, archived at Internet
`Archive Wayback Machine on November 14, 1999, at
`https://web.archive.org/web/19991114194120/http:/www.amazon.com
`/exec/obidos/ASIN/0201310007/
`
`Ex. 1040 Live On-line Chat with Addison Wesley Author, archived at Internet
`Archive Wayback Machine on January 15, 2000, at
`https://web.archive.org/web/20000115153655/http:/www.awl.com/cse
`ng/authors/chats/septemberchats.shtml
`
`Ex. 1041 ACM Digital Library, Inside Java 2 Platform Security: Architecture,
`API Design, and Implementation,
`https://dl.acm.org/citation.cfm?id=310688&preflayout=flat
`
`Ex. 1042 Emin G. Sirer et al., “Design and Implementation of a Distributed
`Virtual Machine for Networked Computers,” Univ. of Wash. (1999)
`
`Ex. 1043 Gianluigi Ferrari et al., “Mobile Agents Coordination in Mobadtl,”
`Univ. of Pisa (2000)
`
`Ex. 1044 Declaration of Jodi L. Gregory
`
`Ex. 1045 Declaration of Dr. Li Gong
`
`Ex. 1046 Deposition Transcript of Dr. George T. Ligler (July 10, 2018)
`
`v
`
`

`

`IPR2017-01620
`Patent 8,489,868 B2
`
`I.
`
`INTRODUCTION
`
`PO’s Response (Paper 16, “Resp.”) fails to overcome the arguments and
`
`evidence in the Petition (Paper 1, “Pet.”) establishing the unpatentability of claims
`
`1, 13, 76-86, 88-95, 98, 100, 104, 112, 113, 137, 139, and 142 (“challenged
`
`claims”) of the ’868 patent. PO’s shotgun approach raises a series of arguments
`
`that lack merit and should be rejected. Accordingly, the challenged claims should
`
`be found unpatentable for at least the reasons set forth in the Petition and
`
`accompanying exhibits, and the additional reasons provided below.
`
`II. CLAIM CONSTRUCTION1
`
`PO argues that the meaning of “abridged version of the software
`
`application” in claim 86 is “a unique transformation of the software application
`
`that is smaller than the software application.” (Resp., 8.) PO’s construction should
`
`be rejected because it improperly introduces limitations based on the
`
`specification’s discussion of an “abridging scheme or algorithm.” (Id.) Claim 86
`
`does not claim any abridging scheme or algorithm. Additionally, the specification
`
`
`1 In co-pending IPR2017-01619, which also involves the ’868 patent, PO proposed
`
`constructions of “signed software application,” “sensitive API,” and “non-sensitive
`
`API.” PO does not propose constructions for these terms in this proceeding and
`
`admits that it does not present any arguments based on these constructions. (Resp.,
`
`6.)
`
`1
`
`

`

`IPR2017-01620
`Patent 8,489,868 B2
`
`does not refer to an abridged version of the software application as a
`
`“transformation,” and neither the specification nor PO explains what
`
`“transformation” means.
`
`According to PO’s expert, Dr. Ligler, the ordinary meaning of “abridged”
`
`means “to reduce in scope, extent, etc.; shorten” and “to shorten by using fewer
`
`words but keeping the main contents; condense.” (Ex. 2002, ¶45.) This ordinary
`
`meaning should apply here—i.e., an abridged version of the software application is
`
`a shortened version of the software application, which is the interpretation applied
`
`in the Petition. (Pet., 47-50.)
`
`III. THE CHALLENGED CLAIMS ARE OBVIOUS
`
`PO raises numerous arguments concerning the prior art; all are unavailing.
`
`A.
`
`Lin’s Description of Figures 2 and/or 6 Discloses a “Signed
`Software Application” That Includes a “Digital Signature”
`
`Despite PO’s arguments to the contrary (Resp., 17-25), Lin discloses a
`
`“signed software application” that includes a “digital signature.”
`
`1.
`
`Lin’s Description of Figure 6
`
`PO is wrong that Lin’s description of Figure 6 only describes transmitting
`
`the signed ADF and the application code separately. (Id., 24.)
`
`Citing Lin’s description of Figure 6, the Petition explains that Lin’s “mobile
`
`device downloads and authenticates the application file 204.” (Pet., 24 (citing, e.g.,
`
`Ex. 1011, 5:6-30).) As part of this cited description, Lin explains that the
`
`2
`
`

`

`IPR2017-01620
`Patent 8,489,868 B2
`
`application code may be transferred to the client device “[i]f it was not already
`
`received,” meaning the signed ADF and the application code may be transferred
`
`together or separately. (Ex. 1011, 5:13-19.) Lin confirms that “it” in “[i]f it was not
`
`already received” refers to the application code in the next sentence, where Lin
`
`describes the procedure that is performed “[u]pon receiving the application code.”
`
`(Id., 5:20-21.) Thus, Lin’s description of Figure 6 teaches transferring the signed
`
`ADF and application code together or separately. (Ex. 1002, ¶78.)
`
`PO’s footnote argument that “it” refers to the “network location of the
`
`application code” is inconsistent with Lin’s disclosure.2 (Resp., 22 n.4.) In Lin, the
`
`network location of the application is always received by the client device in the
`
`signed ADF. As explained in Lin, the signed ADF includes ADF 302, which
`
`“contains a pointer to the network location of the application” (Ex. 1011, 3:25-39,
`
`5:1-4, FIG. 3). Thus, at step 610, the device has received the network location in
`
`
`2 PO contends that its understanding of Figure 6 is also right because it is
`
`consistent with Lin’s discussion of authenticating applications on smaller device.
`
`(Resp., 19-20.) But PO ignores Lin’s explanation that the application code “can be
`
`very small.” (Ex. 1011, 5:33-37.) PO also ignores that Lin’s discussion of Figure 2
`
`(which PO admits discloses combined transmission (Resp., 18)) also addresses
`
`authenticating applications on smaller device. (Ex. 1011, 3:16-20.)
`
`3
`
`

`

`IPR2017-01620
`Patent 8,489,868 B2
`
`ADF 302 and simply obtains the location from ADF 302 if the application code
`
`was not already received. (Id., 6:36-39.) This understanding is further supported by
`
`Lin’s explanation that the client device “obtains” the network location but
`
`“transmits a request to the server” to receive the application code if it was not
`
`already received. (Id., 5:13-16.) Nowhere does Lin describe obtaining the network
`
`location from a server or, for that matter, anywhere other than ADF 302.
`
`PO is also wrong that the signed ADF may not include ADF 302 (and
`
`therefore the network location). The sole basis for PO’s argument is one sentence
`
`in Lin that states that the signed ADF “[p]referably” contains ADF 302. (Resp., 22
`
`n.4 (citing Ex. 1011, 5:1-4).) As Dr. Ligler testified, however, Lin fails to describe
`
`a single embodiment in which the signed ADF does not include ADF 302 or how
`
`Lin’s system would work without ADF 302. (Ex. 1046, 224:18-227:10.) In fact,
`
`without ADF 302, it is unclear whether Lin’s system would work at all, because
`
`ADF 302 describes the device resources that are “required” or “necessary” to
`
`execute the application. (Ex. 1011, 3:29-42.)
`
`Thus, Lin’s disclosure does not support PO’s argument that “it” in “[i]f it
`
`was not already received” refers to the network location of the application code. In
`
`context, “it” clearly refers to the application code itself, especially in view of Lin’s
`
`explanation that the application code may be transferred separately. (Id., 2:67-3:5,
`
`3:21-25, FIGS. 2, 3; Ex. 2004, 190:8-191:13.)
`
`4
`
`

`

`IPR2017-01620
`Patent 8,489,868 B2
`
`
`Finally, whether the signed ADF and application code are transferred
`
`separately or together in Figure 6 is irrelevant, because these two parts of the
`
`application file when transferred separately are reconstructed in the virtual
`
`machine of the client device to form a “signed software application [that] includes
`
`a digital signature,” as claimed. (Ex. 2004, 198:17-202:4; Ex. 1011, 2:66-3:16,
`
`5:13-52, FIGS. 2, 6.)
`
`2.
`
`Lin’s Description of Figures 2 and 6
`
`Even if Lin’s description related to Figure 6 does not teach transmitting the
`
`signed ADF and the application code together, PO admits that Lin’s description
`
`related to Figure 2 does. (Resp., 18.) But PO argues that the Petition cannot rely on
`
`Lin’s descriptions of both Figure 2 and 6 because “doing so improperly combines
`
`elements from two distinct embodiments.” (Id., 17.)
`
`The descriptions of Figures 2 and 6, however, must be read in the context of
`
`the rest of Lin’s disclosure, which provides a “DETAILED DESCRIPTION OF A
`
`PREFERRED EMBODIMENT.” (Ex. 1011, 2:10-11.) As confirmed during the
`
`deposition of Dr. Ligler, each of Lin’s figures corresponds to different but related
`
`aspects of Lin’s preferred embodiment, not isolated embodiments. (Ex. 1046,
`
`195:8-201:5, 219:14-221:4.) For example, Figure 1 shows a network over which a
`
`client device and a server interact. (Ex. 1011, 2:42-65, FIG. 1.) Figure 2 shows a
`
`detailed representation of a client device receiving an application file, which
`
`5
`
`

`

`IPR2017-01620
`Patent 8,489,868 B2
`
`includes a signed ADF and application code. (Id., 2:66-3:20, FIG. 2.) Figure 3
`
`shows a detailed diagram of a signed ADF. (Id., 3:21-64, FIG. 3.) Figure 4 shows a
`
`sequence for creating a signed ADF. (Id., 3:65-4:29, FIG. 4.) Figure 5 shows a
`
`sequence for obtaining a developer’s certificate, which is included in the signed
`
`ADF. (Id., 4:30-53, FIG. 5.) And, finally, Figure 6 shows a sequence for
`
`downloading a signed ADF and application code from a server to a client device.
`
`(Id., 4:54-5:30.) Thus, Lin’s figures are related and build upon one another to
`
`describe a method to authenticate distributed application code. Indeed, even PO
`
`and its expert, Dr. Ligler, repeatedly refer to different figures when describing Lin.
`
`(See, e.g., Resp., 13 (referring to FIGS. 3-6 regarding the signed ADF), 16
`
`(referring to FIGS. 3 and 6 regarding the signed time stamp), 22 n.4 (referring to
`
`FIGS. 3 and 6 regarding the signed ADF and ADF 302).) Accordingly, it was
`
`appropriate for Petitioner to rely on the descriptions of both Figures 2 and 6.
`
`Additionally, PO does not argue that the concept of transferring a signed
`
`ADF and application code together and the procedure shown in Figure 6 are
`
`disclosed in a manner that they could not have been used together by a POSA. In
`
`fact, as confirmed by Dr. Ligler, the procedure shown in Figure 6 would operate in
`
`the same way regardless of whether the signed ADF and application code are
`
`transmitted separately or together. (Ex. 1046, 222:5-16; Ex. 1011, 4:60-5:13.)
`
`6
`
`

`

`IPR2017-01620
`Patent 8,489,868 B2
`
`
`3.
`
`A POSA Would at Once Envisage the Claimed
`Arrangement
`
`PO’s argument also fails because, even if Lin “does not expressly spell out
`
`all the limitations arranged or combined as in the claim,” a POSA, reading Lin,
`
`“would at once envisage the claimed arrangement or combination.” Blue Calypso,
`
`LLC v. Groupon, Inc., 815 F.3d 1331, 1341-44 (Fed. Cir. 2016) (internal quotation
`
`marks, brackets, and citations omitted). As PO admits (Resp., 18-20), Lin describes
`
`only two options for transferring application code: the code is transferred either (i)
`
`together with the signed ADF or (ii) separately from the signed ADF. (Ex. 1011,
`
`2:67-3:5, 5:13-21.) Lin also states that “[n]umerous modifications, changes,
`
`variations, substitutions and equivalents will occur to those skilled in the art
`
`without departing from the spirit and scope of the present invention.” (Id., 5:53-
`
`59.) Thus, Lin explicitly contemplates transferring the signed ADF and application
`
`code together in the procedure shown in Figure 6, and Dr. McDaniel testified that a
`
`POSA would read Lin in such a way. (Ex. 2004, 190:8-191:13, 194:2-195:3,
`
`197:25-203:18.) As discussed above, there is also no dispute that the procedure
`
`shown in Figure 6 would have worked if the signed ADF and application code
`
`were transferred together. (See Ex. 1046, 222:5-16.) Thus, Lin discloses the
`
`disputed claim limitations. See Blue Calypso, 815 F.3d at 1341-44 (finding
`
`anticipation even though the disclosed elements were not arranged as claimed
`
`7
`
`

`

`IPR2017-01620
`Patent 8,489,868 B2
`
`because the combination of the disclosed elements was contemplated by the prior
`
`art, supported by expert testimony, and within the ability of a POSA).
`
`B.
`
`Lin Discloses Allowing Access to Resources “Based Upon
`Verifying the Digital Signature”
`
`PO wrongly argues that Lin does not describe that access to resources 212 is
`
`“based upon verifying” digital signature 312, as required by challenged claims 1
`
`and 76. (Resp., 25-32.)
`
`As explained in the Petition (Pet., 15, 20-24), Lin’s disclosure is related to
`
`“security” and “authentication” of application code. (See Ex. 1011, 1:6-11; id.,
`
`1:19-29.) Security and authentication is provided using a signed ADF, which
`
`includes a developer signature 312 created by signing a hash of elements
`
`302/304/306/308/310. (Id., 3:21-29, 3:62-64, 5:1-4, 5:45-48, 6:6-12, 6:18-26.) Lin
`
`explicitly states that signature 312 is what “allows the client device to authenticate
`
`the ADF.” (Id., 3:62-64.) Specifically, as explained by Dr. McDaniel, verification
`
`of signature 312 using the developer’s public key 318 confirms that elements
`
`302/304/306/308/310 have not been altered after signature 312 was created. (Ex.
`
`1002, ¶¶174-75.) This is consistent with Lin’s explanation that “developers
`
`provide[] their public key in the signed ADF so that client devices can use them to
`
`further establish a trusted chain.” (Ex. 1011, 5:43-45; Ex. 1046, 45:2-49:9.) For
`
`example, if signature 312 is not verified, it is not possible to confirm the integrity
`
`8
`
`

`

`IPR2017-01620
`Patent 8,489,868 B2
`
`of the application code by comparing it to file hash 304, as file hash 304 may have
`
`been changed after signature 312 was created. (Ex. 1002, ¶175; Ex. 1046, 54:19-
`
`64:23.) For this reason, Lin explains that “preferably a signed hash” of the
`
`application is compared to the application code. (Ex. 1011, 5:45-48.) Accordingly,
`
`the “signed ADF allows devices…to easily authenticate the trustworthiness of an
`
`application” before it is executed. (Id., 5:37-40.)
`
`Other elements of the signed ADF confirm this understanding of Lin’s
`
`disclosure. For example, the signed ADF includes developer certificate 308 and
`
`time stamp 310, each of which provides a higher level of trust in developer
`
`signature 312. (Id., 3:25-29.) Among other things, certificate 308 includes public
`
`key 318 and a validity period. (Id., 3:50-56.) Verification of certificate 308 using
`
`the previously-provided certificate authority’s public key means the client device
`
`can safely assume public key 318 is valid and belongs to the developer. (Id., 4:60-
`
`63, 5:6-8.) Verification of time stamp 310 using the previously-provided time
`
`stamping root key means signature 312 was created during the valid period of the
`
`developer certificate. (Id., 3:56-61, 5:8-12.) If one or both of certificate 308 and
`
`time stamp 310 are not verified, one or both of public key 318 and signature 312
`
`cannot be trusted for purposes of verifying signature 312. (Id., 5:40-45.) Therefore,
`
`Lin explains that “security is accomplished by providing the client device with a
`
`9
`
`

`

`IPR2017-01620
`Patent 8,489,868 B2
`
`set of keys initially, such as the code signing certificate authority key and a time
`
`stamping root key.” (Id., 5:40-43.)
`
`PO argues that verification of certificate 308, time stamp 310, and file hash
`
`304 provides sufficient security in Lin’s system. (Resp., 31-32.) As Dr. McDaniel
`
`explained, however, the security provided by these elements “are dependent on
`
`performing the step of validating that signature.” (Ex. 2004, 230:13-231:10.) If
`
`signature 312 is not verified, Lin’s “system will not provide [the] security that it’s
`
`claiming.” (Id., 225:3-230:11.) Additionally, if signature 312 is not verified, many
`
`of the steps described in Lin “would be pointless.” (Id., 224:18-25.) This is
`
`because, as Dr. Ligler confirmed, certificate 308 and time stamp 310 only provide
`
`a higher level of trust in developer signature 312. (Ex. 1046, 45:2-49:9, 205:9-
`
`207:9, 207:14-208:9, 218:19-219:6.) That is, a verified certificate 308 provides
`
`assurance that public key 318 can be trusted for verifying signature 312 (id., 45:2-
`
`48:25, 205:9-207:9) and a verified time stamp 310 confirms that signature 312 was
`
`created during the valid period of certificate 308 (id., 207:14-208:9). Thus, the
`
`foundation of security in Lin’s system rests in verifying signature 312. Indeed, if
`
`signature 312 is not verified, signature 312 (and the described process for creating
`
`signature 312) is meaningless because it has no use in Lin’s system. (Id., 216:17-
`
`217:19)
`
`10
`
`

`

`IPR2017-01620
`Patent 8,489,868 B2
`
`
`Likewise, successful comparison of file hash 304 to the application code
`
`does not provide sufficient security. As Dr. McDaniel explained, verification of
`
`signature 312 is required to confirm that file hash 304 has not changed since
`
`signature 312 was created. (Ex. 1002, ¶175; Ex. 2004, 225:3-230:11.) Only then
`
`can file hash 304 confidently be used to confirm the integrity of the application
`
`code (Ex. 1002, ¶175), because, “[b]y themselves, the combination of an input and
`
`its hash is not secure,” as “even an extremely unimaginative cracker could simply
`
`replace both the input and the hash” (Ex. 1032, 69). Even Dr. Ligler acknowledged
`
`that the combination of an input and its hash is not secure unless combined with
`
`other security measures. (Ex. 1046, 54:19-64:23.)
`
`C.
`
`Lin Discloses “Wherein the Private Key Is Not Accessible to the
`Mobile Device”
`
`As it did in its institution decision (Dec., 17-18), the Board should reject
`
`PO’s argument that Lin does not inherently disclose “wherein the private key is not
`
`accessible to the mobile device” (Resp., 32-37).
`
`PO’s contention that Lin’s client devices may be trusted and therefore have
`
`access to the developer’s private key is unsupported. (Resp., 33.) Lin does not state
`
`that client devices are trusted, and Lin’s context confirms that they are not. As
`
`explained by Dr. McDaniel, Lin describes a conventional digital signature scheme
`
`where the client device must verify signature 312. (Ex. 1002, ¶¶162-75.)
`
`11
`
`

`

`IPR2017-01620
`Patent 8,489,868 B2
`
`Accordingly, consistent with Dr. Ligler’s testimony regarding such conventional
`
`schemes, a POSA would have understood that the private key is not accessible to
`
`the client device. (Id., ¶168; Ex. 1046, 85:23-89:8.) If it was, Lin’s security
`
`measures would be compromised and the digital signature could not be verified
`
`with confidence, as described in Lin. (Ex. 1002, ¶168; Ex. 1046, 85:23-89:8.)
`
`Dr. McDaniel confirmed this understanding of Lin during his deposition. For
`
`example, when asked about a hypothetical situation where a client device is trusted
`
`because it belongs to the application developer (e.g., a testing scenario), Dr.
`
`McDaniel explained that Lin does not describe such a situation and reiterated that
`
`Lin’s security model dictates that the client device does not have access to the
`
`private key. (Ex. 2004, 204:9-210:9.) According to Dr. McDaniel, “if the device
`
`had access to the private key, it would nullify any security provided by Lin.” (Id.,
`
`208:9-209:5.) He also explained that such a situation would result in Lin’s
`
`disclosure having no purpose because “there is no reason to check the signature
`
`because you already trust the phone.” (Id., 209:7-210:9.) This last point is
`
`consistent with the specification of the ’868 patent, which explains that a software
`
`developer can test its application “using a device simulator in which the digital
`
`signature verification function has been disabled.” (Ex. 1001, 5:43-48.)
`
`12
`
`

`

`IPR2017-01620
`Patent 8,489,868 B2
`
`
`Accordingly, in Lin, the private key is not accessible to the mobile device.3
`
`D.
`
`Lin Discloses Claims 78 and 81
`
`PO contends that Lin does not disclose the limitations of claim 78 because
`
`Lin does not describe any embodiments where the signed ADF “does not include a
`
`signature.” (Resp., 37-40.) To the contrary, as discussed in the Petition, Lin
`
`determines whether the requesting software application includes at least developer
`
`signature 312. (Pet., 29-30.)
`
`For example, before the application can be executed, Lin explains that the
`
`client device must “authenticate the signed time stamp” to determine “whether the
`
`ADF file is signed within the valid period.” (Ex. 1011, 5:6-13.) Contrary to PO’s
`
`assertion that this check is unrelated to signature 312 (Resp., 39-40), Lin explains
`
`that the time stamp is used to “determine when the application was signed.” (Ex.
`
`1011, 3:56-61.) Thus, verification of time stamp 310 determines whether the
`
`application includes a signature 312 generated within the valid period, which
`
`discloses the limitations of claim 78.
`
`3 PO claims that it distinguished a prior art reference during prosecution of the ’868
`
`patent “where the same device that provides access to APIs…also generates a
`
`digital signature.” (Resp., 35.) It is unclear how this supports PO. The reference
`
`allegedly overcome during prosecution is not the Lin reference at issue here, and
`
`PO has not argued that these two references have a similar disclosure.
`
`13
`
`

`

`IPR2017-01620
`Patent 8,489,868 B2
`
`
`Lin’s description of verifying signature 312 also discloses the limitations of
`
`claim 78. (Pet., 30.) Verification of signature 312 is required before the application
`
`is loaded for execution (see, e.g., Ex. 1011, 5:6-52, 6:18-20), and it would be
`
`impossible to verify signature 312 if it is not included. (Ex. 1002, ¶185.) Thus, the
`
`verification process for signature 312 determines whether the application includes
`
`a signature.
`
`PO next argues that Lin does not disclose “denying the software application
`
`access to the sensitive API,” as recited in claims 78 and 81, because Lin does not
`
`disclose how its system behaves absent a valid signature. (Resp., 38-39.) Yet, at
`
`the same time, PO admits that “Lin discloses the conditions that must be satisfied
`
`before a software application is permitted to execute and access resources 212.”
`
`(Id., 38.) As discussed above, these conditions include verification of time stamp
`
`310 and signature 312, which must be satisfied or else the application may not be
`
`permitted to access some or all of resources 212.
`
`E.
`
`Lin Discloses Claims 85 and 104
`
`PO’s arguments regarding claims 85 and 104, which center on Lin’s
`
`disclosure that the generation and verification of signature 312 uses a hash of
`
`elements 302/304/306/308/310, fail. (Resp., 40-43.) According to PO, a hash of
`
`elements 302/304/306/308/310 is not a “hash of the software application.” (Id.) PO
`
`does not dispute, however, that the hash of elements includes file hash 304, which
`
`14
`
`

`

`IPR2017-01620
`Patent 8,489,868 B2
`
`is a hash of the application. (Id., 41.) And the challenged claims do not preclude
`
`the “hash of the software application” from including additional information.
`
`Additionally, a hash of a hash of the software application is still a hash of the
`
`software application, as a hash is simply a fixed-length, cryptographic
`
`representation of data. (Ex. 2004, 63:11-64:9; Ex. 1009, 30-31; Ex. 1032, 69.)
`
`F.
`
`Lin Discloses Claim 95
`
`As explained in the Petition (Pet., 35), Lin’s signature 312 provides the
`
`claimed “audit trail” because it is generated using a hash of elements that identify
`
`the developer, including DDF 306 and certificate 308 (Ex. 1011, 4:12-20, 6:21-26).
`
`Despite this disclosure, PO argues that “signature 312 does not ‘identify[] a
`
`developer of the software application requesting access to the sensitive API,” but
`
`provides no rationale supporting its conclusion. (Resp., 43-45.) To the extent PO’s
`
`position is that signature 312 does not identify a developer because signature 312 is
`
`generated using a hash of elements, signature 312 is similar to the digital
`
`signatures providing an audit trail described in the ’868 patent, which are also
`
`generated using a hash of information. (See, e.g., Ex. 1001, 4:45-50.)
`
`G. The Lin-Garst Combination Discloses Claims 13 and 88
`
`PO argues that the Lin-Garst combination does not disclose “displaying a
`
`description string when the software application attempts to access the sensitive
`
`API,” because “the point at which Lin’s application attempts to access a sensitive
`
`15
`
`

`

`IPR2017-01620
`Patent 8,489,868 B2
`
`API is after Lin’s system has already determined that access should be granted.”
`
`(Resp., 45-47.) The claims, however, do not state that the string is displayed upon
`
`determining that access should be granted but rather when the application actually
`
`“attempts to access the sensitive API.” As explained in the Petition and by Dr.
`
`McDaniel, in Lin, unauthenticated applications may be executed but “may not
`
`access some or all of resources 212.” (Pet., 20-21; Ex. 1002, ¶150.) Thus, in
`
`Petitioner’s obviousness combination, such applications may display a string to
`
`“inform the user that an attempted access to an API was denied and why.” (Pet.,
`
`37-38.) Moreover, for authenticated applications, the Petition explains that “it was
`
`well known to display a message asking a user to grant or deny an application
`
`access to a resource for security purposes.” (Id., 38, Ex. 1002, ¶205.)
`
`H. The Lin-Garst Combination Discloses Claim 98
`
`PO argues that a POSA would not have modified Lin to verify signature 312
`
`“upon each access request” to ensure the ongoing authenticity and integrity of
`
`application code because verifying signature 312 does not confirm that the code
`
`has not changed. (Resp., 47.) PO’s argument is based on a misunderstanding of
`
`Petitioner’s obviousness combination and how conventional digital signatures
`
`worked.
`
`As explained in the Petition, signature 312 is generated and verified using a
`
`hash of elements, including file hash 304, which is a hash of the application code.
`
`16
`
`

`

`IPR2017-01620
`Patent 8,489,868 B2
`
`(Pet., 24-26.) By verifying signature 312, file hash 304 can confidently be
`
`compared to a hash of the application code produced by the client device to
`
`confirm the integrity of the code, as described in Lin. (Ex. 1002, ¶¶173-75; Ex.
`
`1011, 5:20-26.) Unlike PO and Dr. Ligler, Petitioner and Dr. McDaniel support
`
`this understanding of how Lin