Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Detailed Action
This office action is a Final office action in response to the communication filed on January 15, 2026. Claims 1-4, 9, 15-16 and 20 are amended. Claim 6 is canceled. Claims 1-5 and 7-20 are pending and addressed below.
Response to Amendment
Applicant’s amendment and response to the claims 1 and 3 are sufficient to overcome the objection set forth in the previous office action. Examiner has withdrawn the objection as applicant amended the claims.
Response to Arguments
Applicant’s arguments filed January 15, 2026 have been fully considered but they are not persuasive for the following reasons:
Applicant’s arguments with respect to the rejections of amended claim 1 under 35 U.S.C 103 have been fully considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. A new ground of rejection under 35 U.S.C 103 is made in view of the combination of prior art of Dore et al. (US PG-PUB No. 20190158286 A1), Anand et al (US PG-PUB No. 20150264153 A1) and Pensak et al (US PG-PUB No. 20090328003 A1) (see below rejection details).
Therefore, claim 1 is rejected under 35 U.S.C 103. As claims 2-5 and 7-8 are dependent directly or indirectly on claim 1, applicant’s argument with respect to the rejections of claim 2-5 and 7-8 are moot.
As per the prior art rejection of amended claim 9 under 35 U.S.C 103 on page 8, applicant argues that Pensak fails to disclose, teach or suggest the amendment “wherein the purging selects between one of at least three options of overwriting the decrypted code in the second storage portion with: an empty value, an illegal instruction or the encrypted code”. The Examiner respectfully disagrees. The amendment does not add new limitation to the existing claim “wherein the purging comprises overwriting the decrypted code in the second storage portion with at least one of empty values, the encrypted code, or other encrypted code” which is disclosed by Pensak in the previous office action (see below rejection details). Therefore, the 35 U.S.C 103 rejection to the amended claim 9 is maintained. As claims 10-14 are dependent directly or indirectly on claim 9, applicant’s argument with respect to the rejections of claim 10-14 are moot.
As per the prior art rejection of amended claim 15 under 35 U.S.C 103 on page 8, applicant argues that Anand fails to disclose, teach or suggest the amendment “wherein the purge threshold specifies a frequency of use of the decrypted code in the second storage portion, wherein the purging comprises overwriting the decrypted code”. The Examiner respectfully disagrees. Anand teaches “the purge threshold specifies a number of executions of the decrypted code” (see previous office action or below rejection for details). One of ordinary skill in the art would agree that “the number of executions of the decrypted code” is the same as “a frequency of use of the decrypted code”. Therefore, the 35 U.S.C 103 rejection to the amended claim 15 is maintained. As claims 16-20 are dependent directly or indirectly on claim 15, applicant’s argument with respect to the rejections of claim 16-20 are moot.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-5 and 7-20 are rejected under 35 U.S.C. 103 as being unpatentable over Dore et al (US PG-PUB No. 20190158286 A1) in view of Anand et al (US PG-PUB No. 20150264153 A1), and in further view of Pensak et al (US PG-PUB No. 20090328003 A1).
Regarding claim 1, Dore teaches a system, comprising: a memory that stores computer executable components; and a processor that executes one of the computer executable components that: in response to an indication being received that encrypted code in a first storage portion of a code block of an executable binary is to be used for execution, temporarily decrypts the encrypted code of the code block into decrypted code in a second storage portion of the code block for execution of the decrypted code in an unencrypted state (Paragraph [0003]: “An example of such a technique is known as “on-demand code decryption”. According to this technique, some elements, or “chunks”, of the code are delivered in an encrypted form (indication being received that encrypted code of a code block is to be used). These are decrypted (temporarily decrypts the encrypted code of the code block into decrypted code for use of the decrypted code in an unencrypted state) just prior to execution and then purged afterwards (the “elements or chunks of the code” are the first and second storage portions of the code block of an executable binary is to be used for execution).”);
Dore fails to explicitly teach purge threshold and the purge process.
However, Anand teaches determines a purge threshold for initiating purging of the decrypted code from the second storage portion of code block, wherein the purge threshold specifies a number of executions of the decrypted code that the decrypted code can remain decrypted in the second storage portion; and in response to determining that the purge threshold has been satisfied for the decrypted code, purges the decrypted code from the second storage portion of the code block (Paragraph [0062]: “If at 802 it is determined that the purge confirmation has not been received, at 806 it is determined whether a retry limit has been reached (The retry limit of purge confirmation is the purge threshold).The retry limit may be associated with a threshold amount of time since a first attempt of the purge instruction of a purge request (e.g., received in 702 of FIG. 7) has been issued to the node and/or a number of times the purge instruction of the same purge request has been issued to the node (purge threshold specifies number of executions). For example, the retry limit is reached after a predetermined amount of time after the purge request has been received and/or after a predetermined number of times a purge instruction has been issued for the same purge request to the node.”; Paragraph [0064]: “If at 806 it is determined the retry limit has been reached (in response to determining that the purge threshold has been satisfied for the decrypted code), at 810 the node is identified as unavailable and the process ends (purges the decrypted code from the second storage portion of the code block).”).
Dore and Anand are both considered to be analogous to the claimed invention because they are in the same field of protecting code for content distribution. Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system disclosed by Dore with adding purging process and purge threshold disclosed by Anand.
One of the ordinary skills in the art would have been motivated to reduce the amount of time required to confirm a purge of desired content, as suggested by Anand in paragraph [0002].
Dore and Anand fail to explicitly teach, but Pensak teaches wherein the purging overwrites the decrypted code in the second storage portion with empty values (Paragraph [0048]: “Upon encountering breakpoints, the Execution Controller checks any previously-decrypted customer application functions and purges (Purging the previously decrypted code) or re-encrypts any that have completed execution 1035. The Execution Controller can determine whether any such functions have finished by comparing the instruction counter of the Main Process main thread to a map of active function entry and return points. The Execution Controller can overwrite completed routines with cipher-text versions (Purging comprises overwriting the decrypted code with the encrypted code). The cipher text can be retrieved from long term storage or retained in more readily-accessible memory by the Execution Controller (the previously encrypted code). If the nature of the function includes changing local variables, the Execution Controller can re-encrypt the module with current variable values (other encrypted code). Re-encryption can be accomplished using software on a specialized hardware device”; Pensak teaches the purging overwrites the decrypted code in the second storage portion with the encrypted code or the other encrypted code. Pensak does not explicitly teach the purging overwrites the decrypted code with empty values. However, one of ordinary skill in the art would understand that purging is essentially the deleting process, wherein empty (null) values are typically used to overwrite the previous value when memory is cleared or deleted.).
Dore, Anand and Pensak are all considered to be analogous to the claimed invention because they are in the same field of protecting code from reverse engineering attacks. Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the purging process disclosed by Dore and Anand with adding the purging overwrites the decrypted code in the second storage portion with empty values disclosed by Pensak.
One of the ordinary skills in the art would have been motivated to better address piracy, theft and tampering threats without slowing down the software development process and delaying product releases, and to provide a simpler and more comprehensive approach to application security, as suggested by Pensak in paragraph [0004].
Regarding claim 2, Dore, Anand and Pensak, hereinafter DAP, teaches all of the features with respect to claim 1, as outlined above.
Dore further teaches wherein the one of the computer executable components further obtains and encrypts code of the code block at compile time of the code block to generate the encrypted code (Paragraph [0032]: “In addition, the object-to-object transformation may generate an intermediate source file fib.shellcode.c. This intermediate source file is used to encrypt the code to be protected (generate the encrypts code of the code block) using an encryption operation matching the decryption operation injected during the source-to-source transformation and a give secret key.”; Paragraph [0033]: “The intermediate source file is compiled (encryption at compile time) during the object-to-object transformation to generate a second output object file, referred to as “fib.shellcode.o” in FIG. 4. The second object file carries the encrypted (provide the encrypted code) or otherwise obscured code to be protected in a data section.”; Paragraph [0036]: “ultimate .bin binary wrapper (include object files) is obtained at step s51 and the relevant function code (i.e. the code that has been protected) (encrypted code) can be retrieved.”).
Regarding claim 3, DAP teaches all of the features with respect to claim 2, as outlined above.
Dore further teaches wherein the encrypting the code comprises: writing a trigger marker into the encrypted code (Paragraph [0030]: “In particular, the source-to-source transformation isolates and marks the code to be protected with markers (writing a trigger marker into the encrypted code). The operation “fibWrapped” identifies this code.”).
Regarding claim 4, DAP teaches all of the features with respect to claim 1, as outlined above.
Dore further teaches wherein the one of the computer executable components further: recognizes a trigger marker at the encrypted code of the code block, and initiates the decryption of the encrypted code in response to the recognition (Paragraph [0031]: “FIG. 4 illustrates an example of the object-to-object transformation. Here input object file fib.s2s.o contains markers (trigger marker) “fibWrapped” and “fibWrappedEnd” allowing the object-to-object transformation to identify the code to be protected (recognizes a trigger marker at the encrypted code of the code block). This code is extracted and replaced with fake code within the object file fib.s2s.o.”; Paragraph [0036]: “FIG. 5 illustrates a process of on-demand decryption subsequently carried out when the software is run (initiates the decryption in response to the recognition). Firstly, ultimate .bin binary wrapper is obtained at step s51 and the relevant function code (i.e. the code that has been protected) (encrypted code) can be retrieved. This is decrypted at step s52 and then patched at step s53 into its source location, replacing the fake code that had been located there. The program may then be run, at step s54. Subsequently, the function code is unpatched at step s55, once again obscuring this code from static analysis.”).
Regarding claim 5, DAP teaches all of the features with respect to claim 1, as outlined above.
Dore further teaches wherein the executable binary comprises a group of code blocks (Paragraph [0003]: “An example of such a technique is known as “on-demand code decryption”. According to this technique, some elements, or “chunks”, of the code (a group of code blocks) are delivered in an encrypted form. These are decrypted just prior to execution and then purged afterwards (the executable binary comprises a group of code blocks).”).
Regarding claim 7, DAP teaches all of the features with respect to claim 1, as outlined above.
Dore further teaches wherein the code block is one of an instruction, a page, a function or a basic block of a software (Paragraph [0036]: “FIG. 5 illustrates a process of on-demand decryption subsequently carried out when the software is run. Firstly, ultimate .bin binary wrapper is obtained at step s51 and the relevant function code (i.e. the code that has been protected) can be retrieved (decryption is performed for the code block at a function level of a software).”).
Regarding claim 8, DAP teaches all of the features with respect to claim 1, as outlined above.
Dore further teaches wherein the encrypted code is part of a group of encrypted code of the code block (Paragraph [0003]: “An example of such a technique is known as “on-demand code decryption”. According to this technique, some elements, or “chunks”, of the code are delivered in an encrypted form (the encrypted code is part of a group of encrypted code of the code block). These are decrypted just prior to execution and then purged afterwards”).
Regarding claim 9 and 15, Dore teaches a computer-implemented method and a computer program product, the method comprising: temporarily decrypting, by a system operatively coupled to a processor, in response to an indication being received that encrypted code in a first storage portion of a code block of an executable binary is to be used for execution, the encrypted code of the code block into decrypted code in a second storage portion of the code block for execution of the decrypted code in an unencrypted state (Paragraph [0003]: “An example of such a technique is known as “on-demand code decryption”. According to this technique, some elements, or “chunks”, of the code are delivered in an encrypted form (indication being received that encrypted code of a code block is to be used). These are decrypted (temporarily decrypts the encrypted code of the code block into decrypted code for use of the decrypted code in an unencrypted state) just prior to execution and then purged afterwards (the “elements or chunks of the code” are the first and second storage portions of the code block of an executable binary is to be used for execution).”);
Dore fails to explicitly teach purge threshold.
However, Anand teaches determining, by the system, a purge threshold for initiating purging of the decrypted code from the second storage portion of the code block, wherein the purge threshold specifies one of a number of executions (a frequency of use) of the decrypted code that the decrypted code can remain decrypted in the second storage portion or a defined amount of time that the decrypted code can remain decrypted in the second storage portion, and in response to determining that the purge threshold has been satisfied for the decrypted code, purging, by the system, the decrypted code from the second storage portion of the code block (Paragraph [0062]: “If at 802 it is determined that the purge confirmation has not been received, at 806 it is determined whether a retry limit has been reached (The retry limit of purge confirmation is the purge threshold, determines a purge threshold).The retry limit may be associated with a threshold amount of time (purge threshold specifies a defined amount of time) since a first attempt of the purge instruction of a purge request (e.g., received in 702 of FIG. 7) has been issued to the node and/or a number of times the purge instruction of the same purge request has been issued to the node (purge threshold specifies a number of executions or the frequency of use of the decrypted code in the second storage portion). For example, the retry limit is reached after a predetermined amount of time after the purge request has been received and/or after a predetermined number of times a purge instruction has been issued for the same purge request to the node.”; Paragraph [0064]: “If at 806 it is determined the retry limit has been reached (in response to determining that the purge threshold has been satisfied for the decrypted code), at 810 the node is identified as unavailable and the process ends (purges the decrypted code from the second storage portion of the code block).”).
Dore and Anand fail to explicitly teach the purging comprises overwriting the decrypted code in the second storage portion with one of empty values, the encrypted code, or other encrypted code;
However, Pensak teaches the purging comprises overwriting the decrypted code in the second storage portion with at least one of empty values, the encrypted code, or other encrypted code (Paragraph [0048]: “Upon encountering breakpoints, the Execution Controller checks any previously-decrypted customer application functions and purges (Purging the previously decrypted code) or re-encrypts any that have completed execution 1035. The Execution Controller can determine whether any such functions have finished by comparing the instruction counter of the Main Process main thread to a map of active function entry and return points. The Execution Controller can overwrite completed routines with cipher-text versions (Purging comprises overwriting the decrypted code with the encrypted code). The cipher text can be retrieved from long term storage or retained in more readily-accessible memory by the Execution Controller (the previously encrypted code). If the nature of the function includes changing local variables, the Execution Controller can re-encrypt the module with current variable values (other encrypted code). Re-encryption can be accomplished using software on a specialized hardware device”);
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have 1) modified the computer-implemented method and the computer program product disclosed by Dore with adding purging process and purge threshold disclosed by Anand; 2) modified the purging process disclosed by Dore and Anand with adding overwriting the decrypted code in the second storage portion with at least one of empty values, the encrypted code, or other encrypted code disclosed by Pensak.
One of the ordinary skills in the art would have been motivated to reduce the amount of time required to confirm a purge of desired content, as suggested by Anand in paragraph [0002], and to better address piracy, theft and tampering threats without slowing down the software development process and delaying product releases, and to provide a simpler and more comprehensive approach to application security, as suggested by Pensak in paragraph [0004].
Regarding claim 10 and 16, DAP teaches all of the features with respect to claim 9 and 15 accordingly, as outlined above.
Dore further teaches the computer-implemented method and the computer program product further comprising, obtaining and encrypting, by the system, code of the code block at compile time of the code block to generate the encrypted code, and wherein different portions of the code block are decrypted or purged simultaneously (Paragraph [0032]: “In addition, the object-to-object transformation may generate an intermediate source file fib.shellcode.c. This intermediate source file is used to encrypt the code to be protected (generate the encrypts code of the code block) using an encryption operation matching the decryption operation injected during the source-to-source transformation and a give secret key.”; Paragraph [0033]: “The intermediate source file is compiled (encryption at compile time) during the object-to-object transformation to generate a second output object file, referred to as “fib.shellcode.o” in FIG. 4. The second object file carries the encrypted (provide the encrypted code) or otherwise obscured code to be protected in a data section.”; Paragraph [0036]: “ultimate .bin binary wrapper (include object files) is obtained at step s51 and the relevant function code (i.e. the code that has been protected) (encrypted code) can be retrieved.”).
Regarding claim 11 and 17, DAP teaches all of the features with respect to claim 10 and 16 accordingly, as outlined above.
Dore further teaches wherein the encrypting the code comprises: writing a trigger marker into the encrypted code (Paragraph [0030]: “In particular, the source-to-source transformation isolates and marks the code to be protected with markers (writing a trigger marker into the encrypted code). The operation “fibWrapped” identifies this code.”).
Regarding claim 12 and 18, DAP teaches all of the features with respect to claim 9 and 15 accordingly, as outlined above.
Dore further teaches wherein the temporarily decrypting the encrypted code comprises: recognizes, by the system, a trigger marker at the encrypted code of the code block, and decrypting, by the system, the encrypted code in response to the recognition (Paragraph [0031]: “FIG. 4 illustrates an example of the object-to-object transformation. Here input object file fib.s2s.o contains markers (trigger marker) “fibWrapped” and “fibWrappedEnd” allowing the object-to-object transformation to identify the code to be protected (recognizes a trigger marker at the encrypted code of the code block). This code is extracted and replaced with fake code within the object file fib.s2s.o.”; Paragraph [0036]: “FIG. 5 illustrates a process of on-demand decryption subsequently carried out when the software is run (initiates the decryption in response to the recognition). Firstly, ultimate .bin binary wrapper is obtained at step s51 and the relevant function code (i.e. the code that has been protected) (encrypted code) can be retrieved. This is decrypted at step s52 and then patched at step s53 into its source location, replacing the fake code that had been located there. The program may then be run, at step s54. Subsequently, the function code is unpatched at step s55, once again obscuring this code from static analysis.”).
Regarding claim 13 and 19, DAP teaches all of the features with respect to claim 9 and 15 accordingly, as outlined above.
Dore further teaches wherein the executable binary comprises a group of code blocks (Paragraph [0003]: “An example of such a technique is known as “on-demand code decryption”. According to this technique, some elements, or “chunks”, of the code (a group of code blocks) are delivered in an encrypted form. These are decrypted just prior to execution and then purged afterwards (the executable binary comprises a group of code blocks).”).
Regarding claim 14 and 20, DAP teaches all of the features with respect to claim 9 and 15 accordingly, as outlined above.
Dore further teaches wherein the purging further comprises: overwriting the decrypted code in the second storage portion with one of empty values, illegal instructions, or the encrypted code (Paragraph [0031]: “This code is extracted and replaced with fake code (overwrites the decrypted code with illegal instructions) within the object file fib.s2s.o. The fake code can be selected to resemble real code, and may be, for example, junk code, real code or seemingly meaningful code. In other examples, the fake code may be random code.”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. (see form PTO-892).
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JASMINE DAY whose telephone number is (571)272-0204. The examiner can normally be reached Monday - Friday 9:00 - 5:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Philip Chea can be reached at 571-272-3951. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/J.M.D./Examiner, Art Unit 2499 /PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499