FORD GLOBAL TECHNOLOGIES, LLC

Patent Trials and Appeals Board

Dec 30, 2020

2019004661 (P.T.A.B. Dec. 30, 2020)

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