Mordetsky, Joseph Martin. et al.

Patent Trials and Appeals Board

Dec 8, 2020

2019005319 (P.T.A.B. Dec. 8, 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.
12/792,184 06/02/2010 Joseph Martin Mordetsky UN-NP-CP-013 4217
96051 7590 12/08/2020
Uniloc USA Inc.
102 N. College Avenue
Suite 303
Tyler, TX 75702
EXAMINER
DAVIS, ZACHARY A
ART UNIT PAPER NUMBER
2492
NOTIFICATION DATE DELIVERY MODE
12/08/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):
kris.pangan@unilocusa.com
sean.burdick@unilocusa.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________

Ex parte JOSEPH MARTIN MORDETSKY
and CRAIG STEPHEN ETCHEGOYEN
____________

Appeal 2019-005319
Application 12/792,184
Technology Center 2400
____________

Before JOHN A. JEFFERY, BRADLEY W. BAUMEISTER, and DENISE
M. POTHIER, Administrative Patent Judges.

JEFFERY, Administrative Patent Judge.

DECISION ON APPEAL
This application returns to us after we affirmed the Examiner’s
decision to reject then-pending claims 1–8 and 10–20. Ex parte Mordestsky,
Appeal 2013-010166 (PTAB Dec. 14, 2015) (“Bd. Dec.”). Prosecution
reopened after that decision, and Appellant now appeals under 35 U.S.C.
§ 134(a) from the Examiner’s subsequent decision to reject claims 10–17
and 21–23. We have jurisdiction under 35 U.S.C. § 6(b).
We AFFIRM.

Appeal 2019-005319
Application 12/792,184

2
STATEMENT OF THE CASE
Appellant’s invention protects computer software from unauthorized
tampering. See Abstract. Before distribution, part of the software is
encrypted, and after installation, the encrypted portions are decrypted at run
time. Some software functions will not work if decryption fails. See Spec.
¶¶ 8–9. Claim 10 is illustrative:
10. A method for secure execution of an executable software object
at a client device, comprising:
executing a first code portion of the executable software object to
identify (i) a location of data extractable from a second code portion of the
executable software object wherein the second code portion of the
executable software object comprises software protection functions; and
(ii) an algorithm defining computational steps for computing a cryptographic
key from the extractable data;
extracting the data from the second code portion;
computing the cryptographic key from the extracted data using the
algorithm, said cryptographic key being useful for decryption only if said
extracted data from the second code portion was unaltered;
decrypting a third code portion of the executable software object using
the cryptographic key to provide an executable third code portion that is
distinct from the first code portion and the second code portion of the
executable software object;
and
executing the executable third code portion using a computer
processor to perform a processing function.

RELATED APPEAL
As noted previously, this appeal is related to an earlier appeal in this
application where we affirmed the Examiner’s decision to reject then-
pending claims 1–8 and 10–20. See Bd. Dec. 1–8. In that proceeding, the
Sorensen reference, cited in full below, was at issue—a reference that is also
at issue here.
Appeal 2019-005319
Application 12/792,184

3
THE REJECTIONS
The Examiner rejected claims 10, 11, 21, and 22 under 35 U.S.C.
§ 103 as unpatentable over Boesgaard Sorensen (US 2009/0249492 Al;
published Oct. 1, 2009) (“Sorensen”) and Chou (US 5,337,357; issued
Aug. 9, 1994). Final Act. 5–7.1
The Examiner rejected claims 12 and 13 under 35 U.S.C. § 103 as
unpatentable over Sorensen, Chou, and Cook (US 2009/0328227 Al;
published Dec. 31, 2009). Final Act. 8–10.
The Examiner rejected claims 14–17 under 35 U.S.C. § 103 as
unpatentable over Sorensen, Chou, and LeVine (US 2002/0144153 Al;
published Oct. 3, 2002). Final Act. 10–11.
The Examiner rejected claim 23 under 35 U.S.C. § 103 as
unpatentable over Sorensen, Chou, and Applicant admitted prior art (APA)
or, alternatively, over Sorensen, Chou, and Riddick (US 2003/0046568 Al;
published Mar. 6, 2003). Final Act. 12–13.

THE OBVIOUSNESS REJECTION OVER SORENSEN AND CHOU
Regarding independent claim 10, the Examiner finds that Sorensen
discloses, among other things, executing a first code portion to identify (1) a
location of data extractable from an executable software object’s second
code portion, and (2) an algorithm defining computational steps for
computing a cryptographic key from the extractable data. Final Act. 5.

1 Throughout this opinion, we refer to (1) the Final Rejection mailed July 27,
2018 (“Final Act.”); (2) the Appeal Brief filed January 28, 2019 (“Appeal
Br.”); (3) the Examiner’s Answer mailed May 2, 2019 (“Ans.”); and (4) the
Reply Brief filed July 2, 2019 (“Reply Br.”).
Appeal 2019-005319
Application 12/792,184

4
According to the Examiner, because Sorensen’s random key generator
initialization vector (IV) provides software protection functions, the data
from which the key is computed is extracted from a portion of executable
code comprising software protection functions. Ans. 6–8. The Examiner
also cites Chou for teaching decrypting a first code portion of software using
a first key, and concludes that the claim would have been obvious over
Sorensen’s and Chou’s collective teachings. See Final Act. 5–6.
Appellant argues that Sorensen does not teach that file decryption
depends on unaltered extracted data from software code as claimed, but
rather that the hardware profile of the computer seeking to decrypt files
matches the hardware profile of the computer that wrote the files. Appeal
Br. 6–11; Reply Br. 2–7. Appellant adds that Sorensen does not teach that
the extracted data from which the cryptographic key is computed is extracted
from a portion of executable code comprising software protection functions.
Appeal Br. 11–15. According to Appellant, Sorensen uses a key extracted
from hardware profile data to ensure a different hardware device does not
attempt to read the encrypted files. Appeal Br. 14; Reply Br. 6–7.

ISSUE
Under § 103, has the Examiner erred in rejecting claim 10 by finding
that Sorensen and Chou collectively would have taught or suggested
(1) executing a first code portion of an executable software object at a client
device to identify a location of data extractable from the object’s second
code portion containing software protection functions; and (2) computing a
cryptographic key from data extracted from the second code portion, where
the key is useful for decryption only if the extracted data was unaltered?
Appeal 2019-005319
Application 12/792,184

5
ANALYSIS
We begin by noting that the Examiner’s reliance on the secondary
reference to Chou is undisputed, as is the cited references’ combinability.
Rather, as noted above, this dispute turns solely on the Examiner’s reliance
on Sorensen for teaching the disputed limitations noted above. Therefore,
we confine our discussion to Sorensen.
As noted previously, Sorensen was at issue in the earlier appeal in
connection with an anticipation rejection of then-pending claim 1. That
claim recited, in pertinent part, processing first compiled software to
generate a cryptographic key, where the first compiled software is
configured to perform software protection functions, and the key is
computed from a first portion of the first compiled software, where that
portion is extracted from executable code compiled from the software
protection functions. Bd. Dec. 2 (reproducing then-pending claim 1). The
claim further recited, in pertinent part, encrypting a second portion of the
first compiled software using the cryptographic key to produce second
compiled software comprising the first portion in unencrypted form and a
second encrypted portion. Id.
Although then-pending claim 1 recited an encryption step unlike the
decryption step in independent claim 10 at issue here, both claims
nevertheless recite similar features, namely (1) software protection
functions, and (2) extracting data from which a cryptographic key is
computed, as emphasized above.
Turning to the rejection, we see no error in the Examiner’s reliance on
Sorensen for at least suggesting executing a first code portion of an
executable software object to identify a location of data extractable from the
Appeal 2019-005319
Application 12/792,184

6
object’s second code portion containing software protection functions as
claimed. See Ans. 6–7. As Sorensen’s paragraph 95 explains, unique
strings can be embedded into executable program files, where the strings can
be used as parameters to a key extractor to generate cryptographic keys.
Sorensen also describes an embodiment where an encrypted file is
created by (1) storing a random key generator IV in a file; (2) generating two
purpose keys using a key generator; (3) encrypting and authenticating a
payload using the generated keys; and (4) storing the encrypted and
authenticated payload in the file. Sorensen ¶¶ 282–87. The file is then read
by (1) reading the key generator IV; (2) generating encryption and
authentication keys; (3) calculating an authentication tag over the encrypted
payload using the authentication key; and (4) decrypting the payload using
the encryption key. Sorensen ¶¶ 288–93.
This functionality at least suggests (1) automatically identifying a
location of data that is extractable from a code portion comprising software
protection functions, namely the random key generator IV2; (2) extracting
data from that code portion using an identified algorithm; and (3) computing
a cryptographic key from the extracted data. That is, ordinarily skilled
artisans would understand from this functionality that reading the random
key generator IV in Sorensen’s paragraph 289 would (1) identify the
location of data in the file corresponding to the random key generator IV,
and (2) extract that data to read it. To the extent Appellant contends
otherwise (see Appeal Br. 11–15; Reply Br. 2–7), such arguments are
unavailing and not commensurate with the scope of the claim.

2 Accord Bd. Dec. 5–6 (noting that Sorensen’s random key generator IV
provides software protection functions).
Appeal 2019-005319
Application 12/792,184

7
We also see no error in the Examiner’s finding that Sorensen also at
least suggests that the key is useful for decryption only if the extracted data
from which the key is computed was unaltered as claimed. See Final Act. 5–
6; Ans. 4–5. Because Sorensen’s key is computed from extracted data,
namely that associated with the random key generator IV, as noted above,
alterations of that data could compromise the integrity of the key computed
from that data—particularly in symmetric encryption that requires identical
keys as the Examiner indicates. See Ans. 4. That Sorensen’s paragraph 34
explains that symmetric encryption requires the same key to not only encrypt
and decrypt, but also create and verify authentication tags only underscores
this point. To the extent that there may be other scenarios where data used
to generate keys to encrypt and decrypt data are extracted from different
locations as Appellant contends (Appeal Br. 4)—a contention that is
unsubstantiated—ordinarily skilled artisans would nonetheless understand
that computing a key from data extracted at the same location, including
using symmetric encryption, would have been at least an obvious variation
in light of Sorensen.
We also find unavailing Appellant’s contention that Sorensen’s file
decryption ostensibly does not depend on unaltered extracted data from
software code, as claimed, but rather that the hardware profile of the
computer seeking to decrypt files matches the hardware profile of the
computer that wrote the files. Appeal Br. 6–11; Reply Br. 2–7. To be sure,
Sorensen’s paragraph 295 notes that, in one embodiment, stored data are
encrypted and authenticated with a key that depends on hardware profile
data. Our emphasis underscores that this disclosure pertains to a particular
embodiment in Sorensen—not every embodiment. That Sorensen
Appeal 2019-005319
Application 12/792,184

8
distinguishes various disclosed embodiments separately with the phrase “[i]n
one embodiment of the present invention” in paragraphs 280 to 282, 295,
296, 310, 331, and 332 only underscores these distinct embodiments.
Therefore, Appellant’s contentions that are premised on Sorensen’s
key depending on hardware profile data (see Appeal Br. 6–11; Reply Br. 2–
7) ignore the fact that this particular feature is merely a single embodiment
of Sorensen’s invention that is distinct from other disclosed embodiments—
including the one described in paragraphs 282 to 294. Nevertheless,
Sorensen at least suggests that the computed key would be useful only if the
data from which the key was computed was unaltered, as the Examiner
indicates (see Ans. 4), particularly given Sorensen’s disclosure of symmetric
encryption as noted previously.
Therefore, we are not persuaded that the Examiner erred in rejecting
claim 10, and claims 11, 21, and 22 not argued separately with particularity.

THE OTHER OBVIOUSNESS REJECTIONS
We also sustain the Examiner’s obviousness rejections of claims 12–
17, and 23. Final Act. 8–13. Because these rejections are not argued
separately with particularity, we are not persuaded of error in these
rejections for the reasons previously discussed.

CONCLUSION
In summary:
Claims
Rejected
35 U.S.C.
§
Reference(s)
/Basis
Affirmed Reversed
10, 11,
21, 22
103 Sorensen,
Chou
10, 11, 21,
22

Appeal 2019-005319
Application 12/792,184

9
12, 13 103 Sorensen,
Chou, Cook
12, 13
14–17 103 Sorensen,
Chou,
LeVine
14–17
23 103 Sorensen,
Chou, APA
23
23 103 Sorensen,
Chou,
Riddick
23
Overall
Outcome
10–17, 21–
23

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)(1).

AFFIRMED