Ex Parte Deierling et al

Patent Trial and Appeal Board

Aug 30, 2016

12854117 (P.T.A.B. Aug. 30, 2016)

UNITED STA TES p A TENT AND TRADEMARK OFFICE
APPLICATION NO. FILING DATE
12/854, 117 08/10/2010
95240 7590 09/01/2016
Silver Spring Networks, Inc,
c/o Buchanan Ingersoll & Rooney PC
PO Box 1404
Alexandria, VA 22313-1404
FIRST NAMED INVENTOR
Kevin Deierling
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
ATTORNEY DOCKET NO. CONFIRMATION NO.
0072045-000160/SSN-145 7151
EXAMINER
SHERR, MARIA CRISTI OWEN
ART UNIT PAPER NUMBER
3685
NOTIFICATION DATE DELIVERY MODE
09/01/2016 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):
ADIPDOC 1@BIPC.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte KEVIN DEIERLING, ADITI DUBEY,
ALEXANDER GOSTRER, and KUN ALP ANKAJ SHAH
Appeal2014-007570 1
Application 12/854, 117
Technology Center 3600
Before MURRIEL E. CRAWFORD, JOSEPH A. FISCHETTI, and
MICHAEL W. KIM, Administrative Patent Judges.
CRAWFORD, Administrative Patent Judge.
DECISION ON APPEAL
STATEMENT OF CASE
Appellants seek our review under 35 U.S.C. § 134 from the
Examiner's final rejection of claims 1-20. We have jurisdiction under 35
U.S.C. § 6(b).
We AFFIRM-IN-PART.
1 Appellants identify Silver Spring Networks, Inc. as the real party in
interest. Appeal Br. 2.
Appeal2014-007570
Application 12/854, 117
Appellants' invention relates generally to performing secure program
upgrades. Spec., para. 2.
Claim 1 is illustrative:
1. A network device comprising:
a processor; and
a memory having program instructions stored therein that,
when executed by the processor, cause the device to perform the
following operations in response to receiving an update object
having an associated update signature:
determine whether a predefined location of the memory
includes a predetermined value;
store, based on said determination, the received update
object in the memory;
verify the authenticity of the update object stored in the
memory using the received update signature; and
perform an operation to cause the processor to use update
information in the verified update object in lieu of other
information stored in the memory.
Appellants appeal the following rejection: Claims 1-20 are rejected
under 35 U.S.C. § 102(b) as anticipated by Zurawka (US 2006/0248172 Al,
pub. Nov. 2, 2006).
ANALYSIS
Claims l, 2, 5, 8, 9, 13, 14, 19, and20
Appellants do not advance argument directed to dependent claims 2,
5, 8, 9, 13, 14, 19, and 20, so these claims stand or fall with claim 1. See
Appeal Br. 8.
We are not persuaded by Appellants' argument that Zurawka fails to
disclose "determination of a predefined location in memory including said
2
Appeal2014-007570
Application 12/854, 117
value," because instead, Zurawka authenticates whether a user has a right to
access memory. Appeal Br. 4---6; see also Reply Br. 1-3.
The Examiner finds the language of claim 1 anticipated by an
"electronic control unit" in Zurawka. Final Act. 3. Zurawka discloses the
control unit, such as in a vehicle, can be reprogrammed using a "flash
programming tool." Zurawka, para. 2. Zurawka additionally discloses
multiple states of operation (para. 11 ), various memory arrays (para. 19), and
the use of digital keys and signatures for authentication (para. 20). The
Examiner finds Zurawka discloses it will "determine whether a predefined
location of the memory includes a predetermined value" as part of its
authentication step mentioned in paragraph 11. Final Act. 3.
Zurawka further explains the authentication, in that a "digital key is
used to check whether a user of flash programming tool 13 is authorized to
conduct a software update." Zurawka, para. 20. We interpret this passage to
mean that the controller checks a digital key in the programming tool, to see
if it will permit the tool to update the controller. In checking the key, the
key is data in memory. In order to seek and read the key for interpreting it,
the controller must go to a location where it expects to find the key. In
doing so, the controller must seek a "predefined location in memory," as
claimed. The controller does not authenticate the actual user, such as with
biometric checks, but instead uses the digital key in a predetermined
memory location as a proxy for the user.
The Zurawka controller, thus, meets the "determining" language
without actually concerning itself directly with a "user," as argued.
We are also not persuaded by Appellants' argument that the "check"
in Zurawka is a data consistency check, and not based on "determination of
3
Appeal2014-007570
Application 12/854, 117
whether a predefined location of the memory includes a predetermined
value," as claimed. Reply Br. 3--4; see also Appeal Br. 7. Zurawka
discloses "flash segments are deleted in a step 17 and the corresponding
flash segments are subsequently programmed in a step 18 only after
successful completion of the check." Zurawka, para. 20. The check is a
signature check where "data consistency of the program or data stock to be
reprogrammed is checked." Id.
However, the data consistency signature check is performed only after
the successful authentication, and, thus, the signature step is merely an extra
step after the claimed "determining" and before the claimed "storing," such
that Zurawka meets the claimed determining and storing language. Id.
For these reasons, we sustain the rejection of claim 1, as well as of
dependent claims 2, 5, 8, 9, 13, 14, 19, and 20.
Claim 3
Dependent claim 3 recites "comparing a first data to a second data, the
first data determined by applying, to an update signature received in
association with the update object, a public key of the network device, the
second data determined by processing the update object."
Claim 3, thus, requires a public key being applied to an update
signature in an update object, and the result of the applying compared to data
obtained by "processing" the update object. The Examiner cites to
paragraphs 10, 11, 20, and 21 of Zurawka as disclosing the claim language.
See Final Act. 4, Answer 8.
4
Appeal2014-007570
Application 12/854, 117
We are persuaded by Appellants' argument that Zurawka discloses
having the claimed first data, but fails to disclose comparing the first data to
the determined second data. Reply Br. 5---6.
Zurawka discloses
a flash programming tool uses a further digital key to check
whether the program stock or the data stock to be reprogrammed
matches the control unit hardware and whether the program stock
or data stock to be reprogrammed has been improperly
manipulated after delivery by the vehicle manufacturer to the
service organization.
Zurawka, para. 10; see also para. 20. Zurawka, thus, discloses a first data in
the form of a first digital key, which is matched to data representing the
control unit hardware identification. The control unit hardware data is not
"an update signature received in association with the update object," as
claimed. But the application of the digital key to determine if the update
"stock" has been improperly manipulated, in Zurawka, meets the claim
language of applying a public key to an update signature received in
association with the update object.
The claim, however, further requires comparing that data to second
data from the update object. Although Zurawka discloses processing the
update object, such as with a signature check (para. 20, 21 ), we do not find a
disclosure of comparing the first and second data, as claimed.
Because we find no comparing of the first and second data, one of
which results from a claimed "applying" and one which results from a
claimed "processing," we do not sustain the rejection of claim 3.
5
Appeal2014-007570
Application 12/854, 117
Claim 4
Dependent claim 4 recites "verifying the authenticity of update
information within the verified update object using other information within
the verified update object."
We are not persuaded by Appellants' argument that Zurawka does not
verify the authenticity of an update object, and certainly not using
information within the update object. Appeal Br. 9. Zurawka discloses
verifying data consistency, as well as whether the data was manipulated, in a
signature check and check using a digital key. Zurawka, para. 20. The
signature and other information within the update object is. Thus. used to
verify the authenticity of the update object, as claimed.
We therefore sustain the rejection of claim 4.
Claim 6
Dependent claim 6 recites "comparing a first data to a second data, the
first data determined by applying the key to the signature and the second
data determined by processing the update information."
Although claim 6 incorporates limitations in claims 4 and 5, it is
otherwise substantially similar to the language of claim 3.
We are persuaded by Appellants' arguments that the rejection of claim
6 is in error for the same reasons as claim 3. Appeal Br. 9-10; see also
Reply Br. 7. We, thus, do not sustain the rejection of claim 6, for the same
reasons we set forth above at claim 3.
6
Appeal2014-007570
Application 12/854, 117
Claim 7
Dependent claim 7 recites "the operation of verifying the authenticity
of the update information further includes using a second key, a second
signature and the update information included in the verified update object."
We are not persuaded by Appellants' argument that Zurawka does not
disclose a second key and second signature as part of the verification of the
authenticity of an update object. Appeal Br. 10. The Examiner responds
that Zurawka discloses multiple keys and signature checks, in Figure 3, at
elements 24, 28, and 31. Answer 10. Appellants argue in response that the
multiple signature checks pertain to different "program blocks," and, thus, is
not a second signature for a single update object. Reply Br. 7-8.
Zarawka discloses that "the program stock and the data stock are each
stored in a different segment of the flash memory." Zurawka, para. 9. The
update object, therefore, includes both program and data segments. Zurawka
further discloses a signature check on the program segment, followed by a
second signature check on the reprogrammed program segment, followed by
a third signature check on the data segment. Zurawka, para. 21. Zurawka,
thus, meets the claim language, because it uses a second signature for
subsequent signature checks. Zurawka also discloses using a second key, in
that using a "further digital key, flash programming tool 13 checks whether
the program or data stock to be reprogrammed matches the control unit
hardware and whether the program or data stock to be reprogrammed has
been improperly manipulated since its delivery." Zurawka, para. 20.
For these reasons, we sustain the rejection of claim 7.
7
Appeal2014-007570
Application 12/854, 117
Claim 10
Dependent claim 10 recites "wherein the program instructions cause
the device to sign the received update object using a private key
corresponding to the received key."
We are persuaded by Appellants' argument that the cited section of
Zurawka fails to disclose signing an object using a private key, and fails to
even mention any use of a private key. Appeal Br. 11. The portions of
Zurawka the Examiner relies on, paragraphs 9 and 20 (Final Act. 5, Reply
Br. 10-11), do not disclose signing any object, and although Zurawka
discloses the use of a digital key (see, e.g., para. 9), there is no
differentiation between a public key and a private key.
In response, the Examiner asserts that Zurawka is "capable of
performing this step." Answer 10-112. Zurawka discloses calculating a
signature, which we interpret as evidence that Zurawka is capable of signing
an object. Typically an object is signed with a personal key, but it is not
necessarily the case, because other ways of signing, such as with a public
key, are possible. Because an anticipation rejection requires more than what
is usually done, the cited evidence and rationale are insufficient to establish
anticipation.
The Examiner has thus failed to establish a prima facie case of
anticipation. For this reason, we do not sustain the rejection of claim 10.
Claim 11
2 The Examiner also raises an antecedent basis issue with a "received key,"
but does not make a rejection under 35 U.S.C. § 112. Answer 10-11.
8
Appeal2014-007570
Application 12/854, 117
Dependent claim 11 recites "wherein the second and third portions of
said memory are located in a secure area of the device."
We are not persuaded by Appellants' argument that the Examiner has
not established that the flash and RAM memories are in a "secure area of the
device" as claimed. Appeal Br. 12; see also Reply Br. 9. The term "secure
area" does not appear to be defined or limited in meaning by the
Specification, which variously describes "secure" as "cannot be changed by
an attacker" (para. 26), "non-volatile," that does not "persist[ ] across a
hardware reset" (para. 31 ), "read-only" except when in an update mode or
state (para. 32), "hardwired firmware" (para. 40), and placed such that
"reprogramming by an attacker would be very time consuming and/or
expensive, and would also require physical access to controller 210 by the
attacker" (para. 45). The ordinary and customary meaning of "secure" is
"protected from danger or harm." (Merriam-Webster Online Dictionary, last
retrieved on Aug. 26, 2016 from http://www.merriam-
webster.com/dictionary/secure ).
Zurawka discloses "non-programmable" (para. 9) and "non-erasable"
(para. 22) memory locations, which protects data from the danger of being
written over unintentionally, and is, thus, a secure area of the device, as
claimed ..
For this reason we sustain the rejection of claim 11.
Claim 12
Dependent claim 12 recites "wherein the device is a node in a smart
grid network."
9
Appeal2014-007570
Application 12/854, 117
We are persuaded by Appellants' argument that Zurawka does not
mention any type of network its device may be part of, and, thus, does not
disclose it being in a smart grid network. Appeal Br. 12-13. The portions
of Zurawka the Examiner cites, paragraphs 5 and 11 (Final Act. 6), do not
mention any network.
In response, the Examiner asserts the language receives no patentable
weight, and that the device in Zurawka is "capable of' being in such a
network. Answer 11. The Examiner has provided no explanation of the
reason no patentable weight would be given to this claim language, and we
see no reason for it on our own. In addition, the Examiner has provided no
evidence that the vehicle controller disclosed in Zurawka is capable of being
in a network3.
For these reasons, we do not sustain the rejection of claim 12.
Claim 15
Dependent claim 15 recites "wherein the program instructions cause
the device to transmit a request to join the network4 after rebooting using the
information received in the update object."
We are persuaded by Appellants' argument that Zurawka fails to
request rejoining a network after a reboot (caused in claim 13), because there
is no network disclosed. Appeal Br. 13; see also Reply Br. 11-12. The
3 Although the Specification describes by example "a wireless smart-grid
network that monitors and controls an electrical power generation and
distribution service" (para. 17), the Examiner has not established that this is
the meaning of the claim term "smart grid network."
4 Although the claim recites "the network," this is the first occurrence of a
network in the body of the claim, so there may be an antecedent basis issue.
10
Appeal2014-007570
Application 12/854, 117
Examiner indicates the device in Zurawka is capable of rebooting (Answer
12), but this does not address the shortcoming of requesting to join a
network that is not disclosed in Zurawka.
For this reason, we do not sustain the rejection of claim 15.
Claims 16--18
Dependent claim 16 recites "a state machine characterized by a
plurality of states, said states including a first state in which the device is
configured to prevent the processor from modifying information recorded in
the memory."
We are persuaded by Appellants' arguments that although Zurawka
discloses a number of states, including an update state, Zurawka does not
disclose a state that prevents the processor from modifying recorded
information. Appeal Br. 14; see also Reply Br. 12-13. Paragraphs 7-12 of
Zurawka, cited by the Examiner (Final Act. 6), disclose a "starting state," a
"normal state," and a "software update state" (para. 7), but do not describe a
state where the processor is prevented from modifying information.
Zurawka discloses concepts such as read-only memory and non-
programmable memory (id.), but not in conjunction with any particular state.
It is, thus, unclear whether Zurawka's device is capable of having a state that
prevents information from being modified, or if non-programmable memory
is a feature of the memory, rather than a state established by a state machine,
as claimed.
For this reason, we do not sustain the rejection of claim 16, nor of
claims 17 and 18 that depend from claim 16.
11
Appeal2014-007570
Application 12/854, 117
DECISION
We affirm the rejection of claims 1, 2, 4, 5, 7-9, 11, 13, 14, 19, and
20.
We reverse the rejection of claims 3, 6, 10, 12, and 15-18.
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a)(l )(iv).
AFFIRMED-IN-PART
12