`
`
`
`
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`_________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`_________________
`
`GOOGLE LLC,
`Petitioner,
`
`v.
`
`BLACKBERRY LTD.,
`Patent Owner.
`
`_________________
`
`Case IPR2017-01619
`Patent 8,489,868 B2
`_________________
`
`PETITIONER’S REPLY
`
`
`
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`
`
`I.
`II.
`
`TABLE OF CONTENTS
`
`3.
`
`INTRODUCTION ........................................................................................... 1
`CLAIM CONSTRUCTION ............................................................................ 1
`A.
`“Signed Software Application” (All Claims) ........................................ 1
`B.
`“Sensitive API” (All Claims) / “Non-Sensitive API” (Claims
`112 and 139) .......................................................................................... 4
`“Abridged Version of the Software Application” (Claim 86) .............. 9
`C.
`III. THE CHALLENGED CLAIMS ARE OBVIOUS ....................................... 10
`A. Garst Alone or in Combination with Gong Discloses a “Signed
`Software Application” ......................................................................... 10
`1.
`Garst Discloses a “Signed Software Application” ................... 10
`2.
`Garst’s License Key Satisfies the Characteristics of a
`Digital Signature ....................................................................... 11
`The Combination of Garst and Gong also Discloses a
`“Signed Software Application”................................................. 12
`B. Garst Alone or in Combination with Gong Discloses a
`“Sensitive API” ................................................................................... 16
`The Combination of Garst and Gong Discloses Claim 112 ............... 17
`The Combination of Garst, Gong, and Davis Discloses Claims
`77, 79, 80, and 82 ................................................................................ 18
`The Combination of Garst, Gong, and Sibert Discloses Claim
`86 ......................................................................................................... 19
`IV. GONG WAS PUBLICLY AVAILABLE ..................................................... 21
`V.
`CONCLUSION .............................................................................................. 25
`
`
`C.
`D.
`
`E.
`
`
`
`i
`
`
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`
`TABLE OF AUTHORITIES
`
` Page(s)
`
`Federal Cases
`Allied Erecting and Dismantling Co., Inc. v. Genesis Attachments,
`LLC,
`825 F.3d 1373 (Fed. Cir. 2016) .......................................................................... 15
`Berkheimer v. HP,
`881 F.3d 1360 (Fed. Cir. 2018) ............................................................................ 8
`Datamize, LLC v. Plumtree Software, Inc.,
`417 F.3d 1342 (Fed. Cir. 2005) ............................................................................ 8
`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) ................................ 22
`In re Keller,
`642 F.2d 413 (C.C.P.A. 1981) ...................................................................... 13, 18
`In re Mouttet,
`686 F.3d 1322 (Fed. Cir. 2012) .................................................................... 13, 18
`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) .......................................................................... 24
`
`
`
`
`
`
`
`ii
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`
`LIST OF EXHIBITS
`
`
`Ex. 1009
`Ex. 1010
`
`Ex. 1001 U.S. Patent No. 8,489,868
`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)
`Bruce Schneier, “Applied Cryptography” (2nd ed. 1996)
`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
`
`iii
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`RESERVED
`Ex. 1020
`Ex. 1021 U.S. Patent No. 6,298,354 (“Saulpaugh”)
`Ex. 1022
`RESERVED
`Ex. 1023
`RESERVED
`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
`RESERVED
`Ex. 1030
`RESERVED
`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
`
`iv
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`Ex. 1037
`
`Ex. 1040
`
`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
`
`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.co
`m/exec/obidos/ASIN/0201310007/
`
`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
`
`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)
`
`Ex. 1042
`
`v
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`I.
`
`INTRODUCTION
`PO’s Response (Paper 16, “Resp.”) fails to overcome the arguments and
`
`substantial evidence in the Petition (Paper 1, “Pet.”) establishing the
`
`unpatentability of claims 1, 13, 76-95, 98, 100, 104, 108, 112, 113, 137-39, and
`
`142-44 (“the challenged claims”) of the ’868 patent. With respect to the
`
`independent claims, PO’s arguments entirely depend on overly narrow claim
`
`constructions that are inconsistent with the disclosure of the ’868 patent. Under any
`
`proposed construction, however, the prior art of record discloses all of the
`
`limitations of these claims. PO’s arguments with respect to the dependent claims
`
`likewise fail. 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 CONSTRUCTION
`A.
`“Signed Software Application” (All Claims)
`PO’s proposed construction of “signed software application,” which requires
`
`signing the software application code itself (Resp., 7-8), should be rejected because
`
`it is inconsistent with the claims and the specification of the ’868 patent.
`
`Independent claims 1 and 76 state only that the “signed software application
`
`includes a digital signature generated using a private key of a private key-public
`
`key pair.” These claims do not state what information is signed using the private
`
`1
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`key. Nor do these claims mention software application code. Therefore, while the
`
`signed information may need to be associated with the application, the plain and
`
`ordinary meaning of the claims does not require signing the application code itself.
`
`This understanding of the claims is confirmed by the specification of the
`
`’868 patent. For example, consistent with the claim language, the specification
`
`explains that “signed software application Y 22” is the result of appending a digital
`
`signature generated using “private key 18” to “software application Y 14.” (Ex.
`
`1001, 4:36-45.) The specification discloses schemes for generating the digital
`
`signature that involve signing application Y 14, but—as PO and its expert admit
`
`(Resp., 6; Ex. 2002, ¶45)—the specification explicitly states that application Y 14
`
`is merely one example of the type of information that can be signed: “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.” (Ex. 1001, 4:45-55
`
`(emphasis added).) In light of this disclosure, a “signed software application” may
`
`include a digital signature generating by signing information other than application
`
`code.
`
`PO attempts to diminish the significance of this portion of the specification,
`
`stating that it “describes digital signature algorithms generally.” (Resp., 10-11.)
`
`But this portion of the specification is describing ways to generate “the digital
`
`signature” using “the private signature key” and refers to “the application Y 14”
`
`2
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`(Ex. 1001, 4:45-55 (emphasis)), all of which are discussed in the previous
`
`sentences when describing “signed software application Y 22” (id., 4:36-45). Thus,
`
`PO’s attempt to drive a wedge between two related parts of the same paragraph
`
`should be rejected because it is clear that these two parts together describe different
`
`ways to create a signed software application.
`
`PO’s arguments based on the testimony of Petitioner’s expert, Dr. McDaniel,
`
`(Resp. 11-13) are also misplaced. PO argues that the five characteristics of digital
`
`signatures described by Dr. McDaniel “confirm that the ‘signed software
`
`application’ cannot merely include the digital signature of something else.” (Id.,
`
`12-13.) As an initial matter, Petitioner does not argue that the software application
`
`can include any digital signature, but rather argues that the digital signature need
`
`not be generated using the application code. Moreover, these five characteristics
`
`relate to the information that is actually signed using the private key to create the
`
`digital signature, not other information that the digital signature is appended to.
`
`(Ex. 1002, ¶39.) An example illustrating this point can be found in the
`
`specification of the ’868 patent, which explains that “the software developer may
`
`have the software application Y signed” by generating a digital signature using
`
`only an “abridged version of the software application Y.” (Ex. 1001, 6:26-36.) In
`
`this example, while the specification states that software application Y is signed,
`
`the digital signature only satisfies the five characteristics with respect to the
`
`3
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`portion of application Y used to create the digital signature (i.e., the abridged
`
`version of application Y). (See Ex. 1002, ¶¶39-41.)
`
`The prior art referenced by PO (Resp. 13-15) does not alter this conclusion.
`
`While these references describe signed data that includes digital signatures
`
`generated using the data itself (see, e.g., Ex. 1012, 5:30-57), there is no basis to
`
`read these references to mean that a digital signature for signing a message could
`
`not have been generated using any other data, especially when the ’868 patent
`
`itself explicitly describes a signed software application as including a digital
`
`signature generated using “information” and refers to “software application Y 14”
`
`merely as an example of what that information may be. (Ex. 1001, 4:50-55.)
`
`Accordingly, PO’s construction of “signed software application” should be
`
`rejected in favor of the plain and ordinary meaning of this term, as applied in the
`
`Petition. (See Pet., 22-27; Ex. 1002, ¶¶141, 144, 147.)
`
`B.
`
`“Sensitive API” (All Claims) / “Non-Sensitive API” (Claims 112
`and 139)
`PO argues that a “sensitive API” is “an API classified as implicating a
`
`security concern” and “non-sensitive API” is “an API that is not classified as
`
`implicating a security concern.” (Resp., 16.) PO’s constructions should be rejected
`
`because they are inconsistent with the ’868 patent and would render the challenged
`
`claims indefinite. Properly construed, a “sensitive API” is an API to which access
`
`4
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`is restricted on an application-by-application basis, and a “non-sensitive API” is an
`
`API to which access is not restricted on an application-by-application basis,
`
`consistent with the Board’s construction of “sensitive API” in its institution
`
`decision (Dec. (Paper 9), 10-12) and as applied in the Petition (Pet. at 21, 47-49).
`
`Claims 1 and 76 of the ’868 patent explicitly state that a “sensitive API” is
`
`an API “to which access is restricted” (Ex. 1001, 14:46-48, 20:6-8), and dependent
`
`claims make clear that access to a “non-sensitive API” is not restricted (id., 22:28-
`
`31, 22:41-44, 22:51-65, 24:32-46). The specification confirms this understanding
`
`of the claims by broadly stating that “any API may be classified as sensitive” (id.,
`
`3:46-50 (emphasis added)), and that access to a sensitive API is restricted to signed
`
`software applications (id., 3:54-61). In contrast, the specification does not describe
`
`restricting access to non-sensitive APIs. This is consistent with the claim language
`
`discussed above and with the testimony of PO’s expert, Dr. Ligler, who confirmed
`
`that access to non-sensitive APIs in general is not limited to signed applications.
`
`(Ex. 1046, 140:4-141:5.) The Board came to the same conclusion in its institution
`
`decision. (Dec., 10-12.)
`
`PO’s position that the terms “sensitive” and “non-sensitive” must relate to
`
`security concerns is a blatant attempt to avoid the prior art. It is also unsupported
`
`by the disclosure of the ’868 patent. The claims, for example, do not mention
`
`5
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`security. Instead, as discussed above, the claims use these terms merely to
`
`distinguish between APIs based on access restrictions.
`
`The specification explains that the determination as to whether an API
`
`should be classified as “sensitive” or “non-sensitive” is discretionary. (Ex. 1001,
`
`3:46-50.) While this determination may consider whether an application includes
`
`“a virus or other destructive code,” the inclusion of such code is only one of “a
`
`number of criteria” that may be considered. (Id., 5:54-63.) Indeed, as the Board
`
`recognized (Dec., 10), protecting against destructive code is only one goal of the
`
`’868 patent. (Ex. 1001, 1:39-43.) The ’868 patent also seeks to “ensure that a
`
`software application…will properly interact with the device’s native application
`
`and other resources.” (Id., 1:36-39.) Thus, the specification makes clear that
`
`various criteria other than the inclusion of destructive code may be considered
`
`when determining whether an API should be classified as sensitive.
`
`Of these other criteria, PO only addresses the business arrangement
`
`criterion, arguing that such arrangements are meant to provide “an acceptable level
`
`of trust to allow the developer access to sensitive APIs.” (Resp., 18-19.) The
`
`specification is not so limiting. For example, with respect to Figure 2, the
`
`specification describes an embodiment where the determination of whether to
`
`provide access to a sensitive API may depend on “whether or not the developer has
`
`a contractual obligation or other business arrangement.” (Ex. 1001, 5:51-65.) In
`
`6
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`this embodiment, the business arrangement is not tied to trust. The need for a
`
`“registration process” for trusted software developers is described with respect to
`
`an alternative embodiment, which, unlike the embodiment described above, “does
`
`not enable the code signing authority to thoroughly review the software application
`
`for viruses or other destructive code” because only a transformed version of the
`
`application is provided. (Id., 6:16-48.) Thus, considering the full scope of the
`
`disclosure, business arrangements are not solely to ensure that developers are
`
`trusted.
`
`PO’s construction of “sensitive API” also fails because neither the
`
`specification nor the prosecution history of the ’868 patent even mentions the
`
`phrase “security concern,” and PO and Dr. Ligler neglect to explain what this
`
`phrase means. It is also unclear what it means to “implicat[e]” a security concern.
`
`Thus, a POSA is left to guess how one would determine that an API implicates a
`
`security concern.
`
`Dr. Ligler’s deposition testimony underscores these problems with PO’s
`
`construction. For example, Dr. Ligler explained that the specification of the ’868
`
`patent does not contain any guidance for a POSA to determine whether an API
`
`implicates a security concern. (Ex. 1046, 131:16-132:3.) Instead, according to Dr.
`
`Ligler, the decision whether to classify an API as sensitive would be left to the
`
`subjective judgment of the API author (or other entity). (Id., 129:7-130:3, 132:4-
`
`7
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`11, 134:12-135:2.) Indeed, Dr. Ligler did not dispute that two authors of the same
`
`API may disagree on whether the API should be classified as sensitive. (Id., 130:4-
`
`13.) Accordingly, PO’s construction, if accepted by the Board, would render the
`
`challenged claims indefinite. See, e.g., Berkheimer v. HP, 881 F.3d 1360, 1364
`
`(Fed. Cir. 2018); Datamize, LLC v. Plumtree Software, Inc., 417 F.3d 1342, 1348
`
`(Fed. Cir. 2005).
`
`As discussed above, the only point of comparison provided by the ’868
`
`patent for determining whether an API is “sensitive” or “non-sensitive” is whether
`
`or not access to the API is restricted. PO, however, argues that the meaning of
`
`“sensitive” and “non-sensitive” cannot center on access control because the ’868
`
`patent “describes access restrictions for ‘non-sensitive’ APIs” using a “global
`
`signature.” (Resp., 19-20.) But this argument ignores the distinction between
`
`global digital signatures (as recited in dependent claims 8 and 83) and the API-
`
`specific digital signatures recited in claims 1 and 76, as explained in the Petition
`
`and by Dr. McDaniel. (Pet., 11 n.6; Ex. 1002, ¶64.) Global signatures are simply
`
`not relevant in determining the meaning of “sensitive” and “non-sensitive” APIs.
`
`PO makes a similar argument based on claim 112. (Resp., 20.) According to
`
`PO, this claim allows access to non-sensitive APIs “only after verifying the digital
`
`signature.” (Id.) As discussed in Section III.C, however, PO’s argument is not
`
`supported by the claim language and is inconsistent with the specification.
`
`8
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`
`For these reasons, PO’s constructions should be rejected in favor of the
`
`interpretations applied in the Petition and by the Board. (Pet., 21, 47-49; Dec., 10-
`
`12.)
`
`C.
`“Abridged Version of the Software Application” (Claim 86)
`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., 21.) PO’s construction should
`
`be rejected for several reasons. First, PO’s construction improperly introduces
`
`limitations based on the specification’s discussion of an “abridging scheme or
`
`algorithm.” (Id. (citing Ex. 1001, 6:32-41).) Claim 86 simply does not claim any
`
`abridging scheme or algorithm. Second, the term “transformation” is not defined
`
`by the specification of the ’868 patent or by PO and therefore is vague and
`
`ambiguous. Nor does the specification refer to an abridged version of the software
`
`application as a transformation.
`
`According to 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, ¶71 (citing Ex. 2005, 3).) 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., 56-60.)
`
`9
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`III. THE CHALLENGED CLAIMS ARE OBVIOUS
`PO’s Response raises a handful of arguments concerning the prior art; all are
`
`unavailing.
`
`A. Garst Alone or in Combination with Gong Discloses a “Signed
`Software Application”
`1.
`Garst Discloses a “Signed Software Application”
`PO’s argument that Garst fails to disclose the claimed “signed software
`
`application” is premised on its incorrect construction of this term. (Resp., 24-25.)
`
`Accordingly, if the Board rejects PO’s construction, the Board should also reject
`
`PO’s argument related to Garst.
`
`Even if PO’s construction is adopted, however, PO’s argument still fails.
`
`According to PO, “Garst discloses ‘a digital signature of the license text string that
`
`is used to authenticate the license text string,’ not the application program.” (Resp.,
`
`25.) Yet, PO concedes that LicenseAgreementString 904 (i.e., the license text
`
`string) and LicenseKeyString 902 (i.e., the digital signature) are “stored in a
`
`‘property list area…of the application program code.’” (Id., 25-26 (quoting Ex.
`
`1012, 13:52-65).) In Figure 9, the property list area is the “constant declarations
`
`area 901 of the application program’s source code.” (Ex. 1012, 9:17-21.)
`
`According to Garst, the developer places strings 902 and 904 “in the source code”
`
`so that they are “compiled” and bound into the “executable code” of the program.
`
`10
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`(Id., 9:48-58.) Thus, strings 902 and 904 are part of the software application, as
`
`confirmed by Dr. Liger during his deposition. (Ex. 1046, 176:5-177:12.)
`
`Accordingly, PO and Dr. Ligler both acknowledge that Garst describes
`
`generating a digital signature by signing the portion of the application code
`
`containing the license agreement string. This description is sufficient to disclose
`
`the claimed “signed software application,” as construed by PO. Indeed, PO’s
`
`construction does not require the entire application code be signed or specify
`
`which portion of the code must be signed in order to achieve a “signed software
`
`application.” This description is also consistent with the embodiments in the
`
`specification of the ’868 patent where an abridged version of the software
`
`application (as opposed to the entire application) is used to generate the digital
`
`signature. (See, e.g., Ex. 1001, 6:16-41.)
`
`2.
`
`Garst’s License Key Satisfies the Characteristics of a Digital
`Signature
`PO’s argument that Garst does not disclose a “signed software application,”
`
`as construed by PO, because the LicenseKeyString 902 does not satisfy the
`
`characteristics of a digital signature (Resp., 29-31) also fails.
`
`For example, PO argues that “Garst’s license key would be reusable because
`
`it does not depend on the specific content of the software application.” (Id., 29-30.)
`
`As discussed above, however, Garst’s LicenseKeyString 902 is generated by
`
`11
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`signing the portion of the application code containing LicenseAgreementString
`
`904, and therefore does depend on the specific content of the software application.
`
`(Ex. 1012, 9:17-21, 9:48-58.) Thus, LicenseKeyString 902 could not be moved to
`
`another software application, because that software application would not include
`
`the LicenseAgreementString 904 needed to verify LicenseKeyString 902. (See Ex.
`
`2004, 62:15-63:22.)
`
`PO also argues that “the license key would not render the software
`
`application unalterable after the signature was created.” (Resp., 30-32.) Again, PO
`
`ignores that Garst’s LicenseKeyString 902 is generated by signing the portion of
`
`the application code containing LicenseAgreementString 904. (Ex. 1012, 9:17-21,
`
`9:48-58.) This portion of the application code is unalterable—i.e., it cannot be
`
`altered or else verification of LicenseKeyString 902 will fail. (See Ex. 2004, 67:19-
`
`68:9.)
`
`3.
`
`The Combination of Garst and Gong also Discloses a
`“Signed Software Application”
`Even if Garst does not disclose a “signed software application,” as construed
`
`by PO, it would have been obvious to sign the application code based on the
`
`teachings of Garst and Gong. (Pet., 25-27.) PO disputes whether such a
`
`combination would have been obvious, but does so by attacking Garst and Gong
`
`individually rather than the combination of these references (Resp., 33-38), which
`
`12
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`is improper. See In re Mouttet, 686 F.3d 1322, 1333 (Fed. Cir. 2012); In re Keller,
`
`642 F.2d 413, 426 (C.C.P.A. 1981).
`
`The Petition and evidence supports Petitioner’s obviousness rationale. As
`
`explained in the Petition (Pet., 25-27), Garst describes a license key string
`
`generated by signing the license agreement string using the API vendor’s private
`
`key (Ex. 1012, 12:26-42). This prevents “unauthorized modification of the text
`
`string from extending use of a resource library to an unlicensed program.” (Id.,
`
`12:35-42.) Additionally, by using the API vendor’s private key, Garst’s “invention
`
`can be used to enforce a ‘per-program’ licensing scheme.” (Id., 3:2-6; id., 2:50-54,
`
`9:5-12.) As a result, the API vendor can increase licensing revenue. (Id., 2:40-54.)
`
`But, as discussed in the Petition, Garst’s licensing scheme does not verify
`
`that there were no changes to the code of an application that is licensed to use an
`
`API. (Pet., 26.) Instead, the scheme involves confirming that (i) there were no
`
`changes to the license agreement string by verifying the license key string and (ii)
`
`that the terms of the license agreement string are met. (See, e.g., Ex. 1012, 11:5-
`
`13.) To confirm that these strings are not reused by an unlicensed program, the API
`
`merely checks that the name of the calling application is the same as the name of
`
`the licensed application specified in the license agreement string. (See, e.g., id.,
`
`11:38-41.) Thus, Garst’s scheme leaves open the possibility of an unlicensed
`
`program with the same name accessing an API. (Pet., 26.) It also increases the
`
`13
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`likelihood that a licensed application has been modified to include malicious code.
`
`(Id., 27.)
`
`Indeed, both PO and Dr. Ligler recognize these vulnerabilities in Garst’s
`
`scheme. For example, PO explains that, with Garst’s scheme, “[a]n unscrupulous
`
`developer could simply rename their program to have the same name as the
`
`license, or maliciously alter the behavior of the application without invalidating the
`
`license.” (Resp., 32-34; id., 30.) Dr. Ligler expressed the same concerns. (Ex.
`
`2002, ¶¶84, 86.) Moreover, during his deposition, Dr. Ligler confirmed that any
`
`application having the same name as a licensed application would be able to access
`
`the API. (Ex. 1046, 182:3-185:14.)
`
`There were, however, well known ways to mitigate such vulnerabilities. For
`
`example, as explained in the Petition, “[b]y signing the application code, the
`
`integrity of the code can...be verified” (Pet., 26), which “would have furthered
`
`Garst’s goal of preventing the ‘use of a resource library [by] an unlicensed
`
`program’” (id., 26-27 (quoting Ex. 1012, 12:35-42)) and “verif[ied] that the signed
`
`application code has not been modified to include malicious code (e.g., a virus)”
`
`(Pet., 27). Even PO and Dr. Ligler suggested that signing the code would have
`
`prevented access by unlicensed programs and malicious code when describing the
`
`14
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`consequences of signing only the license agreement string.1 (Resp., 30, 32-33.) As
`
`explained in the Petition, Gong describes such a code signing scheme. (Pet., 26.)
`
`Accordingly, to improve Garst’s scheme, a POSA would have been motivated to
`
`combine the teachings of Garst and Gong. (Id., 26-27.)
`
`PO also protests that Petitioner does not “describe how such a proposed
`
`modification would work in practice.” (Resp., 36-37.) As an initial matter, no such
`
`description is required. See Allied Erecting and Dismantling Co., Inc. v. Genesis
`
`Attachments, LLC, 825 F.3d 1373, 1381 (Fed. Cir. 2016). And, in any event, the
`
`Petition (supported by the testimony of Dr. McDaniel) does explain how the
`
`modification could have worked. For example, the Petition explains that the API
`
`vendor’s private key could have been used to sign the application code. (Pet., 26-
`
`27 (citing Ex. 1002, ¶150 n.7).) Given that the API vendor’s key is private, and
`
`therefore cannot be shared with the application developer, the application code
`
`
`1 During his deposition, Dr. Ligler admitted that additional steps could have been
`
`taken to mitigate such vulnerabilities, but when asked if a possible step would have
`
`been to sign the software application code, he refused to answer, one way or the
`
`other, instead retreating to a position that Garst accepts the risk that unlicensed
`
`applications can access restricted APIs (Ex. 1046 at 185:15-189:3), despite Garst’s
`
`unmistakable objective to prevent it (Ex. 1012 at 2:40-54, 2:67-3:6, 8:66-9:12).
`
`15
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`necessarily would have been provided to the API vendor (e.g., in hash form) for
`
`signing. (Pet., 23-24; Ex. 1002, ¶¶33, 38, 142, 150 n.7; Ex. 1046, 85:23-86:12.)
`
`B. Garst Alone or in Combination with Gong Discloses a “Sensitive
`API”
`PO argues that Garst fails to disclose the term “sensitive API.” (Resp., 38-
`
`41.) However, PO’s argument is based on its improper construction of this term.
`
`(Id.; Section II.B.) Therefore, if the Board rejects PO’s construction, there is no
`
`dispute that Garst discloses this term.
`
`Even if the Board adopts PO’s construction, the term “sensitive API” would
`
`have been obvious based on the combination of Garst and Gong for the reasons
`
`described in the Petition. For example, the Petition explains that Garst describes a
`
`licensing scheme for controlling access to APIs, and Gong describes schemes for
`
`controlling access to such resources for security reasons. (Pet., 16-18.)
`
`“Accordingly, given Garst similarly discloses techniques for controlling access to
`
`system resources, albeit for licensing purposes, a POSA would have recognized
`
`that an access control scheme such as that described in Garst would have also been
`
`beneficially applicable in the context of mobile device security, as taught in
`
`Gong.” (Id., 18-19 (citing Ex. 1002, ¶¶127-28).)
`
`PO argues that Petitioner “fails to tie this analysis to any particular element
`
`of the claims.” (Resp., 42.) To the contrary, with respect to the element “wherein at
`
`16
`
`
`
`IPR2017-01619
`Patent 8,489,868 B2
`
`least one API comprises a sensitive API to which access is restricted,” the Petition
`
`explains that “it would have been obvious to a POSA for one of the plurality of
`
`