Irdeto B.V.

Patent Trials and Appeals Board

Nov 30, 2021

2020003465 (P.T.A.B. Nov. 30, 2021)

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/300,133 09/28/2016 Yuan Xiang Gu 16-30085-US 1169
128144 7590 11/30/2021
Rimon PC
420 West Main Street
Suite 101B
Boise, ID 83702-7358
EXAMINER
DHRUV, DARSHAN I
ART UNIT PAPER NUMBER
2498
NOTIFICATION DATE DELIVERY MODE
11/30/2021 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.rimonlaw@clarivate.com
eofficeaction@appcoll.com
patentdocketing@rimonlaw.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte YUAN XIANG GU and HAROLD JOHNSON
Appeal 2020-003465
Application 15/300,133
Technology Center 2400
Before JEREMY J. CURCURI, HUNG H. BUI, and
GREGG I. ANDERSON, Administrative Patent Judges.
CURCURI, Administrative Patent Judge.
DECISION ON APPEAL
STATEMENT OF THE CASE
Pursuant to 35 U.S.C. § 134(a), Appellant1 appeals from the
Examiner’s decision to reject claims 1–13, 15–23, 26, and 28. We have
jurisdiction under 35 U.S.C. § 6(b).
We REVERSE.

1 We use the word Appellant to refer to “applicant” as defined in 37 C.F.R.
§ 1.42(a). Appellant identifies the real party in interest as Irdeto B.V. Appeal
Br. 2.
Appeal 2020-003465
Application 15/300,133
2
CLAIMED SUBJECT MATTER
The claims are directed to “protecting an item of software so as to
obfuscate a condition which causes a variation in control flow through a
portion of the item of software dependent on whether the condition is
satisfied, wherein satisfaction of the condition is based on evaluation of one
or more condition variables.” Spec. 1:6–9. Claim 1, reproduced below, is
illustrative of the claimed subject matter:
1. A method, implemented by one or more computer
hardware processors, of creating a protected item of software so
as to obfuscate a condition which causes a variation in control
flow through a portion of an item of software dependent on
whether the condition is satisfied, wherein satisfaction of the
condition is based on evaluation of one or more condition
variables, the method comprising:
modifying the item of software such that the control flow
through said portion is not dependent on whether the condition
is satisfied;
inserting a plurality of identity transformations into
expressions in said portion of the modified item of software,
wherein the identity transformations are defined and inserted
such that, in the absence of tampering, they maintain the results
of the expressions when the condition is satisfied and such that
they alter the results of the expressions when the condition is
not satisfied, wherein each identity transformation is directly or
indirectly dependent on at least one of the one or more
condition variables; and
saving a result of the modifying and inserting steps as the
protected item of software.
REFERENCES
The prior art relied upon by the Examiner is:
Appeal 2020-003465
Application 15/300,133
3
Name Reference Date
Collberg US 6,668,325 B1 Dec. 23, 2003
Horning US 2005/0183072 A1 Aug. 18, 2005
Eker US 2010/0199354 A1 Aug. 5, 2010
Hriljac US 2013/0097431 A1 Apr. 18, 2013

REJECTIONS
Claims 1, 12, 18–23, 26, and 28 are rejected under 35 U.S.C. § 103 as
obvious over Eker and Horning. Final Act. 6–14.
Claims 2–11, 13, and 17 are rejected under 35 U.S.C. § 103 as
obvious over Eker, Horning, and Hriljac. Final Act. 14–26; see also Ans. 4
(withdrawing the rejection of claim 14).
Claims 15 and 16 are rejected under 35 U.S.C. § 103 as obvious over
Eker, Horning, and Collberg. Final Act. 26–30.
OPINION
The Examiner finds the combination of Eker and Horning teaches all
of the limitations of claim 1. Final Act. 6–9. In particular, the Examiner
finds Eker teaches “modifying the item of software such that the control
flow through said portion is not dependent on whether the condition is
satisfied” (claim 1). Final Act. 7 (citing Eker ¶¶ 23, 57).
Appellant presents the following pivotal arguments:
Eker does not teach “modifying the item of software such that the
control flow through said portion is not dependent on whether the condition
is satisfied” (claim 1 (emphasis added)) because Eker discloses “control flow
through the sequence 314 is dependent on whether the condition x==42 is
TRUE or FALSE. This is the opposite of what is recited in independent
claims 1, 26 and, 28.” Appeal Br. 5. “[T]he execution path merge taught by
Appeal 2020-003465
Application 15/300,133
4
Eker, does not indicate that the program flow does not depend on the
condition. Even after the merger, the control flow is dependent on the
condition.” Appeal Br. 6.
“As an example, shown in Appendix 1 of the subject application, the
initial portion of the item of software has a condition at [P1-Line 22],
namely If (check != 1) Then. The protected software, as shown in Appendix
2 of the subject application, no longer has this condition.” Appeal Br. 7. “In
Eker, the initial software has a conditional statement if (x==42), but the
protected software still uses conditional statements of if (cond) or if (!cond),
where cond = (x==42).” Appeal Br. 7.
In response, the Examiner explains “Eker teaches, transforming
conditional statement into plurality of statement where each of the plurality
of statement is executed at least partially, thus, clearly indicating control
flow of program does not depend on the conditional statement.” Ans. 5.
In reply, Appellant argues the Examiner “appears to overlook the fact
that there are instructions (e.g. instructions S 1) that are either executed or
not executed in dependence on the condition cond.” Reply Br. 4.
We review the appealed rejections for error based upon the issues
identified by Appellant, and in light of the arguments and evidence produced
thereon. Ex parte Frye, 94 USPQ2d 1072, 1075 (BPAI 2010) (precedential).
This appeal turns on the meaning of “control flow.”
Appellant’s Specification discloses “the control flow through the
portion of the item of software in P1-Line 22–44 [(Appendix 1)] varies
dependent on the value of check (is it 1 or not?).” Spec. 16:26–27; see also
Spec. Appendix 1.
Appellant’s Specification further discloses “[a]nother difference
between the protected item of software (P2) [(Appendix 2)] and the initial
Appeal 2020-003465
Application 15/300,133
5
item of software (P1) [(Appendix 1)] is that the code has been modified so
that the control flow is no longer dependent on whether the “check = 1”
condition is satisfied.” Spec. 19:22–24; see also Spec. Appendix 1, 2.
The term “control flow” is defined in the computer context as “[t]he
tracing of all possible execution paths in a program, often represented in the
form of a diagram.” MICROSOFT COMPUTER DICTIONARY 127 (5th
ed. 2002). We determine that this definition is consistent with Appellant’s
Specification, and adopt this definition as our own interpretation.
Given this interpretation of “control flow,” we determine the
Examiner erred in finding Eker teaches “modifying the item of software
such that the control flow through said portion is not dependent on whether
the condition is satisfied” (claim 1).
In Eker, in the transformed program code 314 (Eker, Fig. 3), the
tracing of possible execution paths is still dependent on whether the
condition x==42 is TRUE or FALSE.
We recognize that each transformed program statement 316 (Eker,
Fig. 3) is at least partially executed. This is exactly the point made by
Appellant—the condition (cond or !cond) is evaluated, and the action
statement (S1, S2, . . . , S N, S N+1, S N+2, . . . , S N+M) is or is not
executed based on the evaluation. Thus, the tracing of possible execution
paths is still dependent on whether the condition x==42 is TRUE or FALSE.
Put another way, the Examiner’s findings are based on an unreasonable and
overly-broad interpretation of “control flow.” For the same reasons
discussed above, the Examiner’s focus on semantics-preserving
transformation of program code (Eker ¶¶ 23, 57) does not teach or suggest
the argued limitation.
Appeal 2020-003465
Application 15/300,133
6
We, therefore, do not sustain the Examiner’s obviousness rejection of
claim 1 and, similarly, independent claims 26 and 28. For the same reasons,
we also do not sustain the Examiner’s obviousness rejection of claims 12
and 18–23, which depend from claim 1.
Likewise, we do not sustain the Examiner’s obviousness rejection of
(1) claims 2–11, 13, and 17 based on Eker, Horning, and Hriljac, and (2)
claims 15 and 16 based on Eker, Horning, and Colberg.

CONCLUSION
The Examiner’s decision to reject claims 1–13, 15–23, 26, and 28 is
reversed.
DECISION SUMMARY
In summary:
Claims
Rejected
35 U.S.C.
§
Reference(s)/Basis Affirmed Reversed
1, 12, 18–
23, 26, 28
103 Eker, Horning 1, 12, 18–
23, 26, 28
2–11, 13, 17 103 Eker, Horning,
Hriljac
2–11, 13, 17
15, 16 103 Eker, Horning,
Collberg
15, 16
Overall
Outcome
1–13,
15−23, 26,
28

REVERSED