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

`

`IPR2017-01620 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`TABLE OF CONTENTS
`
`I.
`
`II.
`
`Introduction ...................................................................................................... 1
`
`The ’868 Patent ................................................................................................ 1
`
`A. Overview of the ’868 Patent .................................................................. 1
`
`B.
`
`Person of Ordinary Skill in the Art ....................................................... 5
`
`III. Claim Construction .......................................................................................... 5
`
`A.
`
`“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) .......................................... 6
`
`B.
`
`“Abridged Version of a Software Application” (Claim 86) ................. 8
`
`IV. The Challenged Claims Are Patentable Over Lin ......................................... 10
`
`A. Overview of Lin (Ex.1011) ................................................................. 10
`
`i.
`
`ii.
`
`iii.
`
`Lin’s Proposed Solution for Authenticating Applications on
`Devices With Limited Resources ............................................. 10
`
`Components of Lin’s Signed ADF ........................................... 11
`
`Lin’s Method of Separately Downloading a Signed ADF and
`Associated Application ............................................................. 14
`
`Petitioner Improperly Combines Lin’s Distinct Embodiments .......... 17
`
`Lin Fails to Expressly or Inherently Disclose “Based Upon Verifying
`the Digital Signature at the Mobile Device, the Mobile Device
`Allowing the Software Application Access to the Sensitive API” ..... 25
`
`Lin Fails to Expressly or Inherently Disclose “Wherein the Private
`Key Is Not Accessible to the Mobile Device” .................................... 32
`
`B.
`
`C.
`
`D.
`
`i
`
`

`

`IPR2017-01620 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`V.
`
`Lin Fails to Disclose How Its System Would Behave If the Signed ADF Did
`Not Include a Digital Signature or the Digital Signature Is Not Successfully
`Verified (Claims 78 and 81) .......................................................................... 37
`
`VI. Lin’s Developer Signature Is Not Generated by Applying a Private Key to a
`Hash of the Software Application and Cannot Be Verified by Generating a
`Hash of the Software Application (Claims 85 and 104) ............................... 40
`
`VII. Lin’s Developer Signature Fails to Provide an Audit Trail to the Developer
`(Claim 95) ...................................................................................................... 43
`
`VIII. Lin in View of Garst Fails to Render Obvious Claims 13, 88, and 98 ......... 45
`
`A.
`
`B.
`
`There Is No Reason to Use Garst’s Denied Access Messages After
`Lin’s System Has Already Determined Access Should Be Granted
`(Claims 13 and 88) .............................................................................. 45
`
`Verifying Lin’s Developer Signature Each Time the Software
`Application Is Loaded for Execution Does Not Verify the Integrity of
`the Application Code and Runs Counter to Lin’s Concern for Devices
`With Limited Resources (Claim 98) ................................................... 47
`
`IX. Lin Fails to Disclose Any Embodiment Where the Signed ADF Does Not
`Include a Digital Signature and There Is No Reason in Lin to Purge the
`Software Application Upon Unsuccessful Verification of a Digital Signature
`(Claims 77, 79, and 82) ................................................................................. 48
`
`X.
`
`Lin’s Developer Signature In Petitioner’s Proposed Modification Is Not
`Generated by Applying a Private Key to an Abridged Version of the
`Software Application and Cannot Be Verified by Generating an Abridged
`Version of the Software Application (Claim 86) .......................................... 51
`
`XI. Lin in View of Gong Fails to Render Obvious Claims 93, 100, 112, and
`139 ................................................................................................................. 56
`
`A.
`
`The Petition Fails to Show Gong is a Printed Publication (Claims 93,
`100, 112, and 139) ............................................................................... 56
`
`i.
`
`Petitioner Fails to Show When Gong Was Publicly
`Accessible ................................................................................. 58
`
`ii
`
`

`

`IPR2017-01620 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`ii.
`
`Petitioner Fails to Show Gong Was Sufficiently Indexed ........ 61
`
`B.
`
`Lin in View of Gong Fails to Render Obvious Claim 112 Because
`Gong Grants Access to Non-Sensitive APIs Regardless of Whether a
`Digital Signature Is Verified ............................................................... 63
`
`XII. Reservation of Rights .................................................................................... 64
`
`XIII. Conclusion ..................................................................................................... 64
`
`
`
`
`
`
`
`
`
`
`
`iii
`
`

`

`IPR2017-01620 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`TABLE OF AUTHORITIES
`
` Page(s)
`
`Cases
`Abiomed, Inc. v. Maquet Cardiovascular, LLC,
`IPR2017-01204, IPR2017-01205, Paps. 8,9, 10-11 (PTAB Oct. 23,
`2017) ................................................................................................................... 23
`ABS Glob., Inc. v. Inguran, LLC,
`IPR2016-00927, Pap.33 (PTAB Oct. 2, 2017) ............................................. 59, 62
`Bettcher Indus. v. Bunzl USA, Inc.,
`661 F.3d 629 (Fed. Cir. 2011) ............................................................................ 36
`Blue Calypso, LLC v. Groupon, Inc.,
`815 F.3d 1331 (Fed. Cir. 2016) .................................................................... 57, 61
`In re Cronyn,
`890 F.2d 1158 (Fed. Cir. 1989) .......................................................................... 61
`Elec. Frontier Found. v. Pers. Audio,
`LLC, IPR2014-00070, Pap.21, 20-24 (PTAB Apr. 18, 2014) ............................ 56
`Ex parte Gundrum,
`Appeal No. 2015-7620 ........................................................................................ 51
`In re Klopfenstein,
`380 F.3d 1345 (Fed. Cir. 2004) .......................................................................... 56
`L-3 Commc’n Holdings, Inc. v. Power Survey, LLC,
`IPR2014-00832, Pap.9, 12 (PTAB Nov. 14, 2014) ............................................ 56
`In re Lister,
`583 F.3d 1307 (Fed. Cir. 2009) ........................................................ 57, 61, 62, 63
`Microsoft Corp. v. Biscotti, Inc.,
`878 F.3d 1052 (Fed. Cir. 2017) .......................................................................... 22
`Microsoft Corp. v. Proxyconn, Inc.,
`789 F.3d 1292 (Fed. Cir. 2015), overruled on other grounds, Aqua
`Prods., Inc. v. Matal, 872 F.3d 1290 (Fed. Cir. 2017) (en banc) ......................... 5
`
`iv
`
`

`

`IPR2017-01620 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`Net MoneyIN, Inc. v. VeriSign, Inc.,
`545 F.3d 1359 (Fed. Cir. 2008) .................................................................... 17, 25
`Nidec Motor Corp. v. Zhongshan Broad Ocean Motor Co. Ltd.,
`851 F.3d 1270 (Fed. Cir. 2017) .......................................................................... 36
`Oil States Energy Services, LLC v. Greene’s Energy Group, LLC,
`639 F. App’x 639 (Fed. Cir. 2016), cert. granted, No. 16-712 (U.S.
`June 12, 2017) ..................................................................................................... 64
`Square, Inc. v. Unwired Planet, LLC,
`CBM2014-00156, Pap.22, 5 (PTAB Feb. 26, 2015) .......................................... 58
`Symantec Corp. v. RPost Commc’ns Ltd.,
`IPR2014-00357, Pap.14, 20 (PTAB Jul. 15, 2014) ............................................ 17
`Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc.,
`200 F.3d 795 (Fed. Cir. 1999) .............................................................................. 6
`Statutes
`35 U.S.C. § 102(b) ................................................................................................... 57
`35 U.S.C. § 311(b) ................................................................................................... 56
`35 U.S.C. § 316(e) ..................................................................................................... 1
`Other Authorities
`37 C.F.R. § 42.6(3) .................................................................................................. 29
`37 C.F.R. § 42.123(a) ............................................................................................... 57
`
`
`
`
`v
`
`

`

`IPR2017-01620 (US. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`EXHIBIT LIST
`
`m 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 Ligler
`
`2003
`
`CV of Dr. George Ligler
`
`2004 Deposition Transcript of Dr. Patrick D. McDaniel (Feb. 21, 2018)
`
`2005 Webster’s NewWorld Dictionary (1984)
`
`
`
`
`
`Vi
`
`

`

`IPR2017-01620 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`I.
`
`Introduction1
`
`Patent Owner BlackBerry Limited (“PO”) submits this Response to the
`
`Petition for inter partes review (Pap.1, “Pet.”) of U.S. Patent 8,489,868 (“’868
`
`patent” or “’868”). In its Institution Decision (Pap.9, “Dec.”), the Board instituted
`
`trial on eight grounds of unpatentability: (1) claims 1, 76, 78, 81, 84, 85, 90-92, 95,
`
`104, 113, 137, and 142 as anticipated by Lin; (2) claims 13, 88, and 98 as obvious
`
`over Lin and Garst; (3) claims 93, 100, 112, and 139 as obvious over Lin and
`
`Gong; (4) claims 77, 79, 80, and 82 as obvious over Lin and Davis; (5) claim 83 as
`
`obvious over Lin and Chang; (6) claim 86 as obvious over Lin and Sibert; (7)
`
`claim 89 as obvious over Lin and Wong-Insley; and claim 94 as obvious over Lin
`
`and Haddock. Dec.23. 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 claims priority to
`
`
`
`1 All emphasis/annotations added unless otherwise indicated.
`
`1
`
`

`

`IPR2017-01620 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`provisional application Nos. 60/234,152 (filed 9/21/2000), 60/235,354 (filed
`
`9/26/2000), 60/270,663 (filed 2/20/2001). Petitioner does not dispute that the ’868
`
`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. It 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 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-01620 (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, Fig. 3; see also id., 7:19-23.
`
`To protect against unauthorized access to sensitive APIs, the ‘868 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-01620 (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 one or more appended
`
`digital signatures is downloaded onto the mobile device, the mobile device may
`
`verify the one or more digital signatures before granting access to any API library
`
`whether or not the API library has been classified as “sensitive.” Ex.1001, 3:61-
`
`4:12, 4:66-5:3, 8:55-61. For example, where a software application is signed with
`
`multiple signatures “all APIs are restricted and locked until a ‘global’ signature is
`
`4
`
`

`

`IPR2017-01620 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`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 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 in the Art
`
`A person of ordinary skill (“POSA”) 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. Ex.2002¶¶4-12, 35-38.
`
`III. Claim Construction
`
`Under the broadest reasonable interpretation (“BRI”) standard, claims are
`
`evaluated using the plain and ordinary meaning of their words from the perspective
`
`of a POSA 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 Prods.,
`
`Inc. v. Matal, 872 F.3d 1290 (Fed. Cir. 2017) (en banc).
`
`5
`
`

`

`IPR2017-01620 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`In a concurrent proceeding involving claims of the ’868 (IPR2017-01619),
`
`PO proposes claim constructions for the following terms:
`
`PO’s Proposed Construction
`Term
`“a signed software application” a software application that is itself signed
`“a sensitive API”
`an API classified as implicating a security
`concern
`an API that is not classified as implicating a
`security concern
`
`“non-sensitive API”
`
`PO does not, however, present any arguments in this proceeding that depend on the
`
`construction of these terms. Therefore, PO does not address the proper
`
`constructions of these terms here. 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).
`
`A.
`
`“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)
`
`The Petition proposed an improperly narrow 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. While urging the Board to adopt its proposed construction, Petitioner also
`
`6
`
`

`

`IPR2017-01620 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`acknowledged that its Petition fails under its own proposed construction. Pet.6
`
`(arguing only “the concurrently-filed petition…relies on prior art that discloses the
`
`claims under [both parties’ interpretations] of the ‘determining’ phrase”), 14
`
`(arguing present petition applies only under “PO’s interpretation,” while prior art
`
`filed in IPR2017-01619 discloses claims under both constructions).
`
`In PO’s Preliminary Response (Pap.8, “POPR”), PO raised the inconsistency
`
`in Petitioner’s positions and explained why Petitioner’s proposed construction was
`
`incorrect. See POPR11-14. At Institution, the Board declined to construe this term
`
`based on Petitioner’s alleged assertion that “the ‘petition demonstrates how the
`
`prior art discloses all of the limitations of the challenged claims under [both
`
`Petitioner’s and] PO’s interpretation,’ where Patent Owner’s interpretation would
`
`include a key pair generated by an application developer.” Dec.9-10 (citing
`
`Pet.14). But Petitioner did not assert in this proceeding that the Petition
`
`demonstrates how the prior art discloses the challenged claims under both
`
`interpretations. Rather, on the same page the Board cites, the Petition expressly
`
`notes that it demonstrates how the prior art discloses the challenged claims only
`
`under PO’s proposed construction. Pet.14. Petitioner further notes that the
`
`concurrently-filed petition (in IPR2017-01619) demonstrates how the prior art
`
`discloses the challenged claims under both Petitioner’s and PO’s proposed
`
`constructions. Pet.14. Petitioner’s expert, Dr. McDaniel, confirmed that his
`
`7
`
`

`

`IPR2017-01620 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`declaration opinions, on which the Petition relies, apply to the broader (PO’s)
`
`construction of the “determining” phrase and that he did not consider or have an
`
`opinion on whether prior art Lin discloses the “determining” phrase under
`
`Petitioner’s proposed construction. Ex.1002¶71; Ex.2004, 238:24-240:3.
`
`The Board’s institution of review in this proceeding, in view of Petitioner’s
`
`admissions that its Petition fails under its own proposed construction of the
`
`“determining” phrase, necessarily means that the Board rejected Petitioner’s
`
`narrow proposed construction in favor of a broader construction. If the Board
`
`adopts Petitioner’s proposed construction of the “determining” phrase, the
`
`Petition—by Petitioner’s own admission (e.g., Pet.6, 14) and in view of
`
`Petitioner’s reliance on developer’s digital signature 312 as the claimed digital
`
`signature (Pet.24 (“signature 312 discloses the claimed ‘digital signature’ under
`
`PO’s interpretation”))—necessarily fails to establish that any of the challenged
`
`claims are unpatentable.
`
`B.
`
`“Abridged Version of a Software Application” (Claim 86)
`
`The BRI of an “abridged version of a software application” is a unique
`
`transformation of the software application that is smaller than the software
`
`application. Ex.2002¶¶43-46. The ’868 discusses the concept of an “abridging
`
`scheme or algorithm,” which is used like a hash function to “generate different
`
`outputs for different inputs.” Ex.1001, 6:32-37. This abridging function is an
`
`8
`
`

`

`IPR2017-01620 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`example of the application-specific “transformed version of the information” that
`
`the ’868 describes when explaining the process through which signatures are
`
`generated. Id., 4:50-55, 10:64-11:2 (“[T]he digital signature is preferably
`
`generated from a hash or otherwise transformed version of the software application
`
`and is therefore application-specific.”).
`
`Like a hash function, an abridging function “generates different outputs for
`
`different inputs,” thus ensuring “that every software application will have a
`
`different abridged version and thus a different signature.” Id., 6:37-41. The ’868
`
`explains that the abridging schemes it refers to in the context of this signing
`
`process have this characteristic: an “abridged version [of the software program]
`
`may similarly be used to generate the digital signature, provided that the abridging
`
`scheme or algorithm, like a hashing algorithm, generates different outputs for
`
`different inputs.” Id., 6:32-37. In the context of the ’868 patent, an abridging
`
`function, like a hash function, thus generates a unique transformation of the
`
`software application to be used in a signature process. Ex.1001, 4:50-55, 6:32-41,
`
`10:64-11:2. This transformation is “unique” to the software application because,
`
`like a hash function, “every software application will have a different abridged
`
`version.” Id., 6:32-41. The broadest reasonable interpretation of an “abridged
`
`version of a software application” is therefore a unique transformation of the
`
`software application that is smaller than the software application.
`
`9
`
`

`

`IPR2017-01620 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`IV. The Challenged Claims Are Patentable Over Lin
`
`Petitioner fails to demonstrate that Lin anticipates independent claims 1 and
`
`76. In addition, the remaining challenged claims all depend from either claim 1 or
`
`76, and all of the anticipation and obviousness grounds set forth by the Petition for
`
`those dependent claims rely on its analysis regarding Lin’s alleged anticipation of
`
`independent claims 1 and 76. In each of its obviousness grounds, the Petition
`
`relies on the secondary references in each of those grounds only for the additional
`
`limitations recited in the dependent claims. Because, as further detailed below, Lin
`
`does not anticipate claims 1 and 76, each of the Petition’s challenges to the
`
`dependent claims fails for the same reasons. Ex.2002¶47.
`
`A. Overview of Lin (Ex.1011)
`
`Lin, entitled “Method for Authenticating Java Archive (JAR) for Portable
`
`Devices,” was filed on July 11, 2000—just over two months before the earliest
`
`provisional application to which the ’868 patent claims priority was filed.
`
`i.
`
`Lin’s Proposed Solution for Authenticating Applications on
`Devices With Limited Resources
`
`Lin explains that prior art methods of authenticating whether an application
`
`originated from a trusted source were designed for desktop personal computers,
`
`and not well-suited for small, portable devices (e.g., mobile communication
`
`devices) due to the limited memory resources available on those devices. Ex.1011,
`
`1:40-58. In particular, Lin notes that compared to the limited memory resources of
`
`10
`
`

`

`IPR2017-01620 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`smaller mobile devices, the X.509 certificates widely used by desktop computers
`
`are large files and “since the certificate comes bundled with the application
`
`typically, the device must load both the application and the certificate.” Id., 1:50-
`
`56.
`
`Thus, Lin proposes solving the problem of downloading and authenticating
`
`an application on a client device with limited computing resources by creating a
`
`file that is substantially smaller than the prior art signed JAR file format—an
`
`application descriptor file (“ADF”) that contains information associated with an
`
`application and information against which the application can be authenticated.
`
`Ex.1011, 2:32-35, 3:16-20. Lin calls this file a “signed ADF.” Unlike in the prior
`
`art, where the certificate was bundled with the application, the signed ADF may be
`
`downloaded first onto the client device separately from the application. Id., 2:24-
`
`29, 2:67-3:5, 4:66-5:1.
`
`ii.
`
`Components of Lin’s Signed ADF
`
`The “signed ADF” includes an application descriptor file (ADF) 302, file
`
`hash 304 of the JAR file, a developer descriptor file (DDF), 306, a developer
`
`certificate 308, a time stamp 310, and a developer signature 312. Ex.1011, 3:25-
`
`29. Figure 3 shows a block diagram 300 of a signed ADF along with an associated
`
`11
`
`

`

`IPR2017-01620 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`JAR file 301 containing the code to be installed on the client device.2 Ex.1011,
`
`3:21-25, Fig. 3.
`
`
`
`Lin describes the information that each element of the signed ADF contains
`
`and/or how the element is generated:
`
`•
`
`ADF 302 includes a pointer to the network location of the application
`
`and describes the resources required by the application, including an indication of
`
`
`
`2 In the Institution Decision, the Board stated that “signed ADF 300 includes a JAR
`
`file 301” (Dec.15; see also id., 16), but Lin states block diagram 300 includes a
`
`signed ADF and a JAR file. Ex.1011, 3:21-25 (“Referring now to FIG. 3, there is
`
`shown a block diagram 300 of a signed application descriptor file (ADF)..., along
`
`with an associated JAR file 301....”). Lin does not disclose any embodiment where
`
`the signed ADF includes a JAR file.
`
`12
`
`

`

`IPR2017-01620 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`the amount of memory required to execute the application, security policy 314
`
`identifying the resources the application needs permission to use, and license
`
`policy 316 used to set how the application may be used (e.g., number of uses).
`
`Ex.1011, 3:29-42.
`
`•
`
`File Hash 304 is a hash of JAR file 301 and can be used to
`
`authenticate the JAR file. Ex.1011, 3:42-48.
`
`•
`
`DDF 306 is obtained from a developer administrator via a code
`
`signing certificate authority and contains information about the JAR file and
`
`developer. Ex.1011, 3:48-50, 4:42-45.
`
`•
`
`Developer Certificate 308, issued to the developer by a code signing
`
`certificate authority, may include developer’s public key 318, identity of the
`
`developer, certificate’s validity period, issuing certificate authority, and issuing
`
`date. Ex.1011, 3:50-53, 4:30-53, Fig. 5. The developer obtains developer
`
`certificate 308 after sending a request to the code signing certificate authority,
`
`which in turn sends the developer information to a developer administration server.
`
`Ex.1011, 4:30-53.
`
`•
`
`Time stamp 310 is a signed timestamp that the developer receives
`
`from a certificate authority. Ex.1011, 3:56-61, 3:67-4:12. The developer first
`
`sends a request, containing a hash of ADF 302 and the developer certificate, to the
`
`authority for a signed timestamp. Ex.1011, 3:67-4:5. The authority then verifies
`
`13
`
`

`

`IPR2017-01620 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`the developer certificate, signs ADF hash files and timestamps it. Ex.1011, 4:7-9.
`
`The developer receives a signed timestamp back from the certificate authority.
`
`Ex.1011, 4:9-12.
`
`•
`
`Developer Signature 312 is generated when the developer signs a
`
`concatenated file that includes the ADF 302, file hash 304, DDF 306, developer
`
`certificate 308, and timestamp 310. Ex.1011, 4:12-20. The signed ADF is then
`
`placed on a distribution server. Ex.1011, 4:18-20. The associated JAR file is also
`
`placed on either the same or a different distribution server. Ex.1011, 4:18-20,
`
`5:16-18.
`
`iii.
`
`Lin’s Method of Separately Downloading a Signed ADF and
`Associated Application
`
`Figure 6 and its associated disclosures describe a “sequence” for
`
`“downloading a signed ADF and a portable application or JAR file from a
`
`distribution server to a network client device in accordance with the invention.”
`
`Ex.1011, 4:56-63; see also id., 2:6-8.
`
`14
`
`

`

`IPR2017-01620 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`
`
`Prior to beginning this sequence, “the client device has had a code signing
`
`certificate authority public key and a time stamping root key placed in the client
`
`device.” Ex.1011, 4:60-63. Lin explains the security of its system is accomplished
`
`by providing the client device with these two keys. Ex.1011, 5:40-43. The
`
`sequence then proceeds through the following steps:
`
`•
`
`step 602: “To begin the method, the client device transmits (602) a
`
`request to a distribution server for the application.” Ex.1011, 4:64-66.
`
`•
`
`step 604: “The distribution server transmits the signed ADF for the
`
`desired application, which is received by the client device (604).” Ex.1011, 4:66-
`
`5:1.
`
`•
`
`step 606: “Upon receiving the signed ADF, the client device verifies
`
`the developer certificate with the code signing certificate authority’s public key
`
`(606).” Ex.1011, 5:6-8.
`
`15
`
`

`

`IPR2017-01620 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`•
`
`step 608: “The client may also authenticate the signed time stamp
`
`with the time stamping root key (608).” Ex.1011, 5:8-10. The verified timestamp
`
`is used to check whether the ADF file 302 is signed within the valid period of the
`
`developer certificate. Ex.1011, 5:10-12; see also id., 3:67-4:12. The developer
`
`certificate and signed timestamp “must be verified.” Id., 5:6-13.
`
`•
`
`step 610: “If it was not already received, the client device obtains the
`
`network location of the application code or JAR file, and transmits a request to the
`
`server, specifying the particular application desired (610).” Ex.1011, 5:13-16.
`
`•
`
`step 612: “The server transmits the application code to the client
`
`device (612).” Ex.1011, 5:18-19.
`
`•
`
`step 614: The client device “compares the hash received in the signed
`
`ADF with the hash of the application, and may also verify attributes such as file
`
`size....If the hash of the application received in the signed ADF matches the hash
`
`of the received application file (in step 6123), the client device loads the application
`
`
`
`3 A POSA would have understood that Lin’s reference to “step 612” here is a
`
`typographical error and should instead refer to “step 614” because Lin already
`
`refers to step 612 earlier in the passage to describe the step where the “server
`
`transmits the application code to the client device (612),” which description is
`
`consistent with the arrow from “Distribution Server” to “Network Client Device”
`
`16
`
`

`

`IPR2017-01620 (U.S. Patent No. 8,489,868)
`
`Patent Owner’s Response
`
`into the virtual machine environment for execution according to the security and
`
`license policies, if any were present in the ADF.” Ex.1011, 5:20-30.
`
`B.
`
`Petitioner Improperly Combines Lin’s Distinct Embodiments
`
`Petitioner asserts that Lin anticipates independent ’868 patent claims 1 and
`
`76, but in doing so improperly combines elements from two distinct embodiments.
`
`Net MoneyIN, Inc. v. VeriSign, Inc., 545 F.3d 1359, 1371 (Fed. Cir. 2008) (for
`
`anticipation, “it is not enough that the prior art reference...includes multiple,
`
`distinct teachings that the artisan might somehow combine to achieve the claimed
`
`invention”); Symantec Corp. v. RPost Commc’ns Ltd., IPR2014-00357, Pap.14, 20
`
`(PTAB Jul. 15, 2014) (denying institution on anticipation ground where Petition
`
`cited to different embodiments in prior art for different claim elements).
`
`
`
`in Figure 6’s step 612. Ex.1011,