FORD GLOBAL TECHNOLOGIES, LLCDownload PDFPatent Trials and Appeals BoardDec 30, 20202019004661 (P.T.A.B. Dec. 30, 2020) Copy Citation UNITED STATES PATENT AND TRADEMARK OFFICE UNITED STATES DEPARTMENT OF COMMERCE United States Patent and Trademark Office Address: COMMISSIONER FOR PATENTS P.O. Box 1450 Alexandria, Virginia 22313-1450 www.uspto.gov APPLICATION NO. FILING DATE FIRST NAMED INVENTOR ATTORNEY DOCKET NO. CONFIRMATION NO. 15/420,373 01/31/2017 Daniel Joseph MADRID 83728107 1079 28395 7590 12/30/2020 BROOKS KUSHMAN P.C./FGTL 1000 TOWN CENTER 22ND FLOOR SOUTHFIELD, MI 48075-1238 EXAMINER WU, DAXIN ART UNIT PAPER NUMBER 2191 NOTIFICATION DATE DELIVERY MODE 12/30/2020 ELECTRONIC Please find below and/or attached an Office communication concerning this application or proceeding. The time period for reply, if any, is set in the attached communication. Notice of the Office communication was sent electronically on above-indicated "Notification Date" to the following e-mail address(es): docketing@brookskushman.com PTOL-90A (Rev. 04/07) UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD Ex parte DANIEL JOSEPH MADRID, SANGEETHA SANGAMESWARAN, JASON MICHAEL MILLER, JOHN NAUM VANGELOV, and ALDI CAUSHI Appeal 2019-004661 Application 15/420,373 Technology Center 2100 Before JOSEPH L. DIXON, DAVID M. KOHUT, and JON M. JURGOVAN, Administrative Patent Judges. KOHUT, Administrative Patent Judge. DECISION ON APPEAL Pursuant to 35 U.S.C. § 134(a), Appellant1 appeals from the Examiner’s decision to reject claims 1–14, 17, and 18.2,3 We have jurisdiction under 35 U.S.C. § 6(b). 1 We use the word “Appellant” to refer to “applicant” as defined in 37 C.F.R. § 1.42. Appellant identifies the real party in interest as Ford Global Technologies, LLC. Appeal Br. 1. 2 Throughout this Decision we refer to the Final Office Action mailed September 5, 2018 (“Final Act.”), the Appeal Brief filed January 22, 2019 (“Appeal Br.”), and the Examiner’s Answer mailed March 21, 2019 (“Ans.”). 3 Claims 15 and 16 were canceled. Final Act. 2. Appeal 2019-004661 Application 15/420,373 2 We AFFIRM. INVENTION The present invention relates to “systems and methods for securing over-the-air (OTA) software updates provided to a plurality of vehicle controllers” by decrypting received software updates using a decryption key received with update instructions indicative of available software updates, and installing the decrypted updates in response to detecting that a first signature, included with the encrypted software updates, matches a second signature generated by a vehicle controller using a signature verification key. Spec. ¶ 1, Abstr. Claim 1 is representative of the invention and is reproduced below. 1. A system for a vehicle comprising: a processor of a controller programmed to: receive encrypted software updates including a first signature, decrypt the received software updates using a decryption key received with update instructions indicative of available software updates, and install the decrypted updates in response to detecting that the first signature matches a second signature generated by the controller using a signature verification key. Appeal Br., (Claims App. A-1 to A-3). Appeal 2019-004661 Application 15/420,373 3 REFERENCES The prior art relied upon by the Examiner is: Name Reference Date Link, II (“Link”) US 2009/0119657 A1 May 7, 2009 Abraham et al. (“Abraham”) US 2013/0318357 A1 Nov. 28, 2013 Smereka et al. (“Smereka”) US 2016/0013934 A1 Jan. 14, 2016 Abraham et al. (“Abraham Patent”) US 9,276,752 B2 Mar. 1, 2016 REJECTIONS Claims 1–12 are rejected under 35 U.S.C. § 103 as being unpatentable over Abraham4 in view of Smereka. Final Act. 6–11. Claims 13, 14, 17, and 18 are rejected under 35 U.S.C. § 103 as being unpatentable over Smereka in view of Link. Final Act. 12−16; Ans. 9–13.5 4 The Examiner’s rejection references both Abraham (US 2013/0318357 A1) and the Abraham Patent (US 9,276,752 B2) (see Final Act. 6), where the first Abraham mentioned is the patent application publication of Application No. 13/984,572, which issued into the Abraham Patent. However, the Examiner makes no mention of the Abraham Patent in the body of the rejection except to reference “an automotive vehicle” in Abraham Patent’s claims 1 and 9 (see Final Act. 6)—the “vehicle” also mentioned in paragraph 50 (“Examples of such targets . . . include . . . automotive vehicles”) of Abraham (US 2013/0318357 A1). Therefore, we address the rejection with reference only to the patent application publication US 2013/0318357 A1 (“Abraham”).. 5 Although the Examiner’s rejection statement in the Final Office Action includes the Abraham Application (see Final Act. 12), the Abraham Application is not mentioned in the description of the rejection (see Final Act. 12–16) nor is the Abraham Application included in the Examiner’s Answer (see Ans. 9−13). Therefore, we review the rejection of claims 13, 14, 17, and 18 without the inclusion of Abraham Application. Appeal 2019-004661 Application 15/420,373 4 OPINION § 103 Rejection of Claims 1–12 Appellant argues the combination of Abraham and Smereka does not teach “decrypt the received software updates using a decryption key received with update instructions indicative of available software updates,” as recited in independent claim 1. Appeal Br. 5–7. With respect to Abraham, Appellant argues the utility 112 of Abraham maintains “half of a public/private asymmetrical key pair” and “various components stored on medium 120 have been encrypted with the other half of the public/private key pair corresponding to keys 116, 118.” (Emphasis added.) Nevertheless, Abraham fails to even suggest the recitations of claim 1 of “a decryption key received with update instructions indicative of available software updates,” let alone disclose “decrypt the received software updates using a decryption key received with update instructions indicative of available software updates.” . . . While Abraham discloses authenticating the update package using one-half of the encrypted session key, Abraham nevertheless fails to disclose or suggest the recitations of claim 1 of “a decryption key received with update instructions indicative of available software updates” and, in any event, fails to disclose or suggest “decrypt the received software updates using a decryption key received with update instructions indicative of available software updates,” as recited in claim 1 in the context of the claim. (Emphasis added.) Appeal Br. 6. With respect to Smereka, Appellant argues “the Final Office Action did not indicate any portion of Smereka that discloses, and, in any event, Smereka does not disclose, ‘decrypt[ing] the received software updates using a decryption key received with update instructions indicative of available software updates.’” Appeal Br. 7. Appeal 2019-004661 Application 15/420,373 5 We do not agree with Appellant’s arguments. Instead, we agree with the Examiner’s findings. Final Act. 6–9; Ans. 14–16. Particularly, we agree with the Examiner that Abraham teaches a processor programmed to “decrypt the received [encrypted] software updates using a decryption key received with update instructions indicative of available software updates,” as recited in claim 1. Id. (citing Abraham ¶¶ 3, 26–27, 30–31, 40, 44, 46– 48, Figs. 1–3). For example, Abraham describes an update initiation utility 112 on a target device 110 (which may part of a vehicle, see Abraham ¶ 50), wherein Utility 112 has access to decryption/signature keys 116, 118, which each form a half of a public/private asymmetrical key pair used in the secure software update. Key 116 is a private decryption key of a public/private asymmetrical encryption/ decryption key pair while key 118 is a public signature key of a public/private asymmetrical signature key pair. Keys 116, 118 are respectively used to decrypt and to authenticate information provided on medium 120 for the software update. See Abraham ¶ 30 (emphases added), Fig. 1. Public signature key 118 on the target device is used to authenticate a “digital signature 126, which is formed with encrypted symmetrical key 124” which can, in turn, be “decrypted using private key 116 to obtain the session key used to provide security features for the software update.” See Abraham ¶ 30; see also Abraham ¶¶ 44–48 (“The public signature key is used to decrypt the digital signature to obtain a second data block that represent the encrypted session key. . . . The encrypted session key is decrypted using the private decryption key” (emphases added)), Fig. 3. Thus, Abraham’s target device uses various decryption keys (public signature key 118, private decryption key 116) to decrypt software updates received from software update media 120. Ans. 14–15; Final Act. 7. Appeal 2019-004661 Application 15/420,373 6 Appellant’s arguments emphasize, “the utility 112 of Abraham maintains ‘half of a public/private asymmetrical key pair’ and ‘various components stored on medium 120 have been encrypted with the other half of the public/private key pair corresponding to keys 116, 118.” Appeal Br. 6. Appellant’s claim 1, however, does not preclude the vehicle system from maintaining half of the keys required for decryption or authentication of software updates. Appellant also seeks to distinguish claim 1 over Abraham on the basis of the decryption key being “received with update instructions indicative of available software updates.” Appeal Br. 6. However, as claimed, the “update instructions” are merely information content bearing no functional or structural relationship to the claimed processor. The processor’s mere receipt of this information (“update instructions indicative of available software updates”) is not enough to constitute a patentable distinction. “Claim limitations directed to the content of information and lacking a requisite functional relationship are not entitled to patentable weight.” Praxair Distribution, Inc. v. Mallinckrodt Hospital Products IP Ltd., 890 F.3d 1024, 1032 (Fed. Cir. 2018). Accordingly, the claimed “update instructions” lack patentable weight to distinguish over Abraham. Even if we did give patentable weight to the claimed “update instructions,” Abraham teaches decryption keys (e.g., public signature key 118, private decryption key 116) received with update instructions indicative of available software updates, as claim 1 recites. For example, Abraham describes the “public signature key, which has been provided to the target device previously” and “the private decryption key [that] was previously provided to the target device as part of the update utility” (¶¶ 44, 46 Appeal 2019-004661 Application 15/420,373 7 (emphases added)), and Abraham’s paragraphs 31–32 explain how the keys were provided to the target device: Update executable file 128 and/or update files 130 [on software update media 120] may include new versions of components used by utility 112 [of target device 110] to initiate and verify the software update. For example, a new version of . . . private encryption key 116 and/or public signature key 118 may be installed in device 110, potentially along with a new version of utility 112, during the installation and update process. The installation and update process may prepare device 110 for a further update at a future date by being able to provide a unique utility 112 for initiating and performing verification for a future software update. See Abraham ¶¶ 31–32; Ans. 15. Appellant’s arguments regarding Smereka are also unpersuasive, as they do not substantively address the Examiner’s findings. Instead, Appellant repeats the claim language and asserts the recited limitations are not found in Smereka (see Appeal Br. 7), without addressing Smereka’s paragraphs 38, 43, 44, 48, and 101–103 relied upon by the Examiner for the claimed decrypting using a decryption key (Smereka’s first-factor information 212 and second-factor information 214). See Final Act. 8 (citing Smereka ¶¶ 43–44); Ans. 15–16 (citing Smereka ¶¶ 38, 43, 48, 101– 103, Fig. 9). Accordingly, Appellant’s arguments have not persuaded us of error in the Examiner’s rejection, and we sustain the Examiner’s obviousness rejection of independent claim 1, independent claim 7 argued for substantially the same reasons, and dependent claims 2–6 and 8–12 not separately argued. Appeal Br. 7–8. Appeal 2019-004661 Application 15/420,373 8 § 103 Rejections of Claims 13, 14, 17, and 18 Appellant argues the combination of Abraham and Smereka does not teach or suggest “responsive to detecting that a vehicle identifier included in instructions indicative of available software updates matches a vehicle identifier assigned to the vehicle . . . decrypt the downloaded software updates using a decryption key included in the instructions” (recited in independent claim 13) “[a]t least for reasons similar to those given above for patentability of independent claim 1.” Appeal Br. 8. Appellant further argues Link fails to even mention “a decryption key included in the instructions,” let alone disclose “responsive to detecting that a vehicle identifier included in instructions indicative of available software updates matches a vehicle identifier assigned to the vehicle . . . decrypt the downloaded software updates using a decryption key included in the instructions,” as recited in claim 13 in the context of the claim. Appeal Br. 9. We do not agree with Appellant’s arguments. Instead, we agree with the Examiner’s findings. Ans. 18–19. Particularly, we agree with the Examiner that Smereka’s verification of software updates decrypts downloaded software updates using a decryption key included in instructions indicative of available software updates, as recited in claim 13. Ans. 18 (citing Smereka ¶ 103, Fig. 9). In particular, Smereka’s paragraph 103 describes a “vehicle 31 [that] decrypts the second level of encryption of the software update 206 [received over a network or through a data connection of a nomadic device 53, such as a cell phone with wireless connectivity] using the second-factor information 214 [received from an update server 210, via nomadic device 53].” See Smereka ¶ 103; see also Smereka ¶¶ 95, Appeal 2019-004661 Application 15/420,373 9 99, 101–102, Fig. 9 (steps 908 and 910). Thus, Smereka’s second-factor information 214 teaches a “decryption key” used to decrypt downloaded software updates, as claimed. Ans. 18. Smereka also teaches the downloaded software updates are decrypted responsive to detecting a match based on a vehicle identifier included in instructions indicative of available software updates, as claimed. Ans. 18 (citing Smereka ¶ 102, Figs. 8–9); Final Act. 12–13 (citing Smereka ¶¶ 46, 68). In particular, Smereka’s process for installing multi-factor encrypted software updates by a vehicle (Figure 9) includes operation 906, [where] the vehicle 31 requests the second-factor information 214 from the update server 210. . . . The request may include, for example, one or more vehicle 31 identifier such as VIN. The request may further include an indication of the software update 206 for which the second-factor information 214 is being requested. In some cases, the request may also include an indication of the associated nomadic device 53 to be used by the update server 210 in responding to the request, while in other cases the update server 210 may identify the associated nomadic device 53 using other information included in the request (e.g., VIN). . . . At operation 908, the vehicle 31 receives the second-factor information 214 from the associated nomadic device 53. For example, the update management application 220 may receive the second-factor information 214 from the update verification application 222 of the nomadic device 53 upon verification by the user of the nomadic device 53 that the software update 206 should be installed. . . . At operation 910, the vehicle 31 decrypts the second level of encryption of the software update 206 using the second-factor information 214. For example, the update management application 220 may utilize the second-factor information 214 received from the nomadic device 53 to complete the decryption of the encryption performed by the update server 210 to the software update 206. Appeal 2019-004661 Application 15/420,373 10 See Smereka ¶¶ 101–103, Fig. 9. Although Appellant’s arguments for claim 13 refer to “reasons similar to those given above for patentability of independent claim 1” (see Appeal Br. 8), Appellant’s claim 1 arguments did not address the “vehicle identifier” features that appear in claim 13. We are also unpersuaded by Appellant’s argument that Link fails to teach “a decryption key included in the instructions” or the claimed “responsive to detecting” limitation of claim 13. See Appeal Br. 9. As the Examiner finds, Link describes provision of a key to decrypt a software package update (see Link ¶ 84) and a telematics controller (VTU) programmed to decrypt downloaded software updates responsive to detecting a match based on a vehicle identifier (see Link ¶¶ 7, 76, 84, 89, Abstr., Figs. 4, 5, and 7). Ans. 18–19 (citing Link ¶¶ 7, 40, 84, 89, Abstr., Figs. 4, 5, and 7); Final Act. 13–14 (citing Link ¶ 76). Accordingly, Appellant’s arguments have not persuaded us of error in the Examiner’s rejections of claim 13, and we sustain the Examiner’s obviousness rejections of independent claim 13, and dependent claims 14, 17,6 and 18 not separately argued. Appeal Br. 9. CONCLUSION The Examiner’s decision rejecting claims 1–14, 17, and 18 under 35 U.S.C. § 103 is affirmed. DECISION SUMMARY In summary: 6 Note that claim 17 depends from canceled claim 15, which was dependent upon independent claim 13 before being canceled. Appeal 2019-004661 Application 15/420,373 11 Claims Rejected 35 U.S.C. § Reference(s)/ Basis Affirmed Reversed 1–12 103 Abraham, Smereka 1–12 13, 14, 17, 18 103 Smereka, Link 13, 14, 17, 18 Overall Outcome 1–14, 17, 18 TIME PERIOD FOR RESPONSE No time period for taking any subsequent action in connection with this appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R. § 1.136(a)(1)(iv). AFFIRMED Copy with citationCopy as parenthetical citation