`
`
`
`
`
`
`
`
`
`
`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
`
`
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
