Irdeto B.V.Download PDFPatent Trials and Appeals BoardNov 30, 20212020003465 (P.T.A.B. Nov. 30, 2021) Copy Citation 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 Copy with citationCopy as parenthetical citation