Ex Parte Hyerle

Patent Trial and Appeal Board

Feb 8, 2016

13060487 (P.T.A.B. Feb. 8, 2016)

UNITED STA TES p A TENT AND TRADEMARK OFFICE
APPLICATION NO. FILING DATE FIRST NAMED INVENTOR
13/060,487 02/24/2011 Robert H yerle
56436 7590 02/10/2016
Hewlett Packard Enterprise
3404 E. Harmony Road
Mail Stop 79
Fort Collins, CO 80528
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.
82654165 9701
EXAMINER
KAPLAN, BENJAMIN A
ART UNIT PAPER NUMBER
2434
NOTIFICATION DATE DELIVERY MODE
02/10/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):
hpe.ip.mail@hpe.com
mkraft@hpe.com
chris.mania@hpe.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte ROBERT HYERLE
Appeal2014-002401
Application 13/060,487
Technology Center 2400
Before JOSEPH L. DIXON, JAMES R. HUGHES, and ERIC S. FRAHM,
Administrative Patent Judges.
DIXON, Administrative Patent Judge.
DECISION ON APPEAL
Appeal2014-002401
Application 13/060,487
STATEMENT OF THE CASE
Appellant appeals under 35 U.S.C. § 134 from a rejection of claims 1-
20. We have jurisdiction under 35 U.S.C. § 6(b).
We affirm-in-part.
The invention relates to a method and apparatus for storing and
verifying data shared among a group of users (see generally, Spec. 3:24--
5:20). Claims 1 and 7, reproduced below, are illustrative of the claimed
subject matter:
1. A method of storing data, comprising:
updating a counter, wherein operation of the counter is
generally available to users of a system and can be read or
updated to a next value in a defined sequence known to the users;
storing data and a value of the counter together in
encrypted form using an encryption key associated generally
with the users of the system; and
verifying that the stored data is current by matching the
value of the counter stored with the data against a current value
of the counter.
7. A method of verifying data, comprising:
decrypting stored data to recover a data element value;
comparing the data element value against a counter to verify the
stored data; and
if the stored data is not verified with a match between the data
element value and the counter, determining an extent to which the
stored data may be trusted based on a magnitude of a difference
between the data element value and the counter.
2
Appeal2014-002401
Application 13/060,487
REFERENCES
The prior art relied upon by the Examiner in rejecting the claims on
appeal is:
Heiden
Trapp
US 2002/0161742 Al Oct. 31, 2002
US 2008/0040620 Al Feb. 14, 2008
REJECTIONS
The Examiner made the following rejections:
Claims 7, 13, and 14 stand rejected under 35 U.S.C. §102(b) as being
anticipated by Heiden.
Claims 1---6 and 18-20 stand rejected under 35 U.S.C. §103(a) as
being unpatentable over Heiden and Trapp.
Claims 8-12 and 15-17 stand rejected under 35 U.S.C. § 103(a) as
being unpatentable over Heiden.
ANALYSIS
The Anticipation Rejection
The Examiner finds Heiden discloses all the limitations of claim 7,
including "if the stored data is not verified with a match between the data
element value and the counter, determining an extent to which the stored
data may be trusted based on a magnitude of a difference between the data
element value and the counter" (Final Act. 1 5---6). Appellant contends
"Heiden only determines whether the freshness counters actually match. If
they do not, Heiden does not teach or suggest considering a magnitude of the
difference between the counters, i.e., 'a magnitude of a difference between
1 The Final Action dated May 10, 2013.
3
Appeal2014-002401
Application 13/060,487
the data element value and the counter.' (Claim 7)." (App. Br. 10.) We
agree with Appellant.
The Examiner cites (Final Act. 6) the following for disclosing the
disputed limitations in claim 7:
[I]f an old customer record is sent to the cryptographic device 5
instead of a current updated customer record 6, the old customer
record's cryptographic signature 13 will be authenticated by the
cryptographic device 5. However, the Freshness Counter 21 and
corresponding Freshness Counter 11 obtained from the old
customer record will not match thereby providing evidence of a
replay attack and allowing appropriate action to be taken by the
proper authorities.
(Heiden, i-f 16.) Here, however, Heiden only discloses determining whether
the two counters match. There is no discussion of the amount of difference
between the counters. The Examiner responds in the Answer that the
magnitude of difference between Heiden' s two counters has two levels, zero
and greater than zero (Ans. 26-27).
We disagree that this interpretation of Heiden meets the claim 7
limitations "if the stored data is not verified with a match between the data
element value and the counter, determining an extent to which the stored
data may be trusted based on a magnitude of a difference between the data
element value and the counter." Claim 7 requires first determining whether
there is a match, then determining the difference between the data element
value and the counter if there is no match. The Examiner's finding in the
Answer conflates these two requirements and does not show Heiden
discloses both determining "if the stored data is not verified with a match"
and a "magnitude of a difference" between a non-matching data element
value and counter. Moreover, simply determining that a difference between
two counters is non-zero does not equate to determining a magnitude of the
4
Appeal2014-002401
Application 13/060,487
difference. It simply identifies that the two counters are different without
determining the amount (magnitude) of difference, which is required by the
term "magnitude."
We are, therefore, constrained by the record to find the Examiner
erred in rejecting independent claim 7, independent claim 13 which recites
commensurate limitations, and dependent claim 14 for similar reasons.
The Obviousness Rejections
Claims 1-6
Appellant contends "Heiden does not teach or suggest the claimed
method including 'updating a counter, wherein operation of the counter is
generally available to users of a system and can be read or updated to a next
value in a defined sequence known to the user.' (Claim 1 )"(App. Br. 13).
Appellant also contends:
like Heiden, Trapp appears to describe a counter that is secured
and not generally available to system users. In fact, there is
nothing in the cited portion of Trapp that would suggest that the
counter is generally available to system users. To the contrary,
the Trapp counter is held in a secure environment.
(App. Br. 14.) We disagree with Appellant.
We agree with the Examiner that the claim 1 language "operation of
the counter is generally available to users of a system" does not specify that
the counter be given to the user, rather we find it merely requires that the use
of the counter is somehow available to a user of the system, even if only
indirectly available (Ans. 28). We also agree with the Examiner that the
claim 1 language "can be read or updated to a next value in a defined
sequence known to the user" does not specify the details of how the user
interacts with the system (Ans. 28-29), rather we find it merely requires that
5
Appeal2014-002401
Application 13/060,487
the operations of the counter include being read and being updated, and that
a user be capable of ascertaining this information. With this understanding
of claim 1, we find the combination of Heiden and Trapp at least suggests
the disputed limitations.
Specifically, Trapp discloses:
An important feature of the invention is the use of a global
counter, timestamps and a hierarchy of check entries to
determine, inside a secure environment, whether a query to an
external data store returns the most up-to-date data (the freshest
data) .... The global counter is incremented each time a primary
item is written into the data store.
(Trapp, i-f 27.) One of ordinary skill in the art would know that some user
agency would be behind a query or write operation to the data store through
either the programming or use of Trapp' s application 101 which "executes
within (is logically located in) a secure environment" and which interacts
with the data store (see Trapp, i-fi-1 30-31 ). Moreover, we agree with the
Examiner's finding that the ability of a user to simply read the Specification
of the Trapp reference itself to learn how the global counter works meets the
claim 1 requirement that a user be capable of ascertaining knowledge of the
counter's operations (see Ans. 28-29). Accordingly, we find Trapp teaches
"wherein operation of the counter is generally available to users of a system
and can be read or updated to a next value in a defined sequence known to
the user," as recited in claim 1.
We are, therefore, not persuaded the Examiner erred in rejecting claim
1, and claims 2---6 not specifically argued separately.
6
Appeal2014-002401
Application 13/060,487
Claims 8-12 and 15-17
The Examiner has not shown the limitations of independent claims 7
and 13 which Heiden fails to anticipate as discussed above would have been
obvious over Heiden. Therefore, we reverse the obviousness rejections of
claims 8-12 and 15-1 7 for similar reasons as the rejection of independent
claims 7 and 13, from which claims 8-12 and 15-17 depend.
Claim 18
The Examiner finds the combination of Heiden and Trapp discloses
all the limitations of claim 18, including that Trapp teaches "anticipating the
next value in the defined sequence of the counter; storing the data with the
anticipated next value of the counter ... and, then, updating the counter to a
[sic] the next value in the defined sequence" (Final Act. 17-19). Appellant
contends Trapp fails to store data with the anticipated next value of a
counter, rather Trapp sets an item's timestamp to the actual virtual time (see
App. Br. 16-17; Reply Br. 9-11). We agree with Appellant.
Trapp' s Figure 5 shows the following steps in order: "increment
virtual time"; "set item's timestamp field to the actual virtual time"; "store
item to location." In contrast, the steps performed by claim 18 proceed as
follows: "anticipating the next value ... of the counter; storing the data with
the anticipated next value of the counter ... ; and, then, updating the
counter." As can be seen, the claimed invention first stores data with an
anticipated value of the counter, then actually updates the counter, whereas
Trapp first increments the timestamp, then sets an item's timestamp to the
already incremented timestamp.
We are, therefore, constrained by the record to find the Examiner
erred in rejecting claim 18.
7
Appeal2014-002401
Application 13/060,487
Claim 19
The Examiner finds Heiden discloses the limitations of claim 19
(Final Act. 19-20), which are similar to the limitations discussed above
regarding claim 7. For the same reasons already discussed with respect to
claim 7, we find Heiden fails to disclose the limitations of claim 19, and we
reverse the Examiner's rejection thereof.
Claim 20
Appellant contends the combination of Heiden and Trapp fails to
disclose "monotonically increasing or decreasing the counter by a number
greater than one to produce the defined sequence known to the users.
(Claim 20) (emphasis added)." (App. Br. 18.) We are not persuaded by
Appellant's argument.
Heiden discloses:
The counter used in one embodiment is simply an incremental
counter that goes up by one for each record transaction
performed by the cryptographic device. However, the freshness
data used can be any other data that is unique to the individual
transaction such as a randomly generated number, a time stamp,
or other nonce.
(Heiden, i-f 13) (emphasis added). Thus, while one embodiment uses a
counter that increments by one, Heiden suggests using any other data that
uniquely identifies a record transaction. We agree with the Examiner and
find one of ordinary skill in the art would have used a counter that
incremented by more than one in view of Heiden' s use of a counter and
8
Appeal2014-002401
Application 13/060,487
suggestion to use "any other data" than increments of one (see Final Act. 21;
Ans. 31-32).
We are, therefore, not persuaded the Examiner erred in rejecting claim
20.
CONCLUSIONS
Under 35 U.S.C. §102(b), the Examiner erred in rejecting claims 7,
13, and 14.
Under 35 U.S.C. § 103(a), the Examiner erred in rejecting claims 8-
12 and 15-19, but did not err in rejecting claims 1---6 and 20.
DECISION
For the above reasons, the Examiner's rejection of claims 7-19 is
reversed, and the Examiner's rejection of claims 1---6 and 20 is affirmed.
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § l .136(a)(l )(iv).
AFFIRMED-IN-PART
9