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 .
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. TW112144797, filed on November 20, 2023. Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Applicant cannot rely upon the certified copy of the foreign priority application to overcome this rejection because a translation of said application has not been made of record in accordance with 37 CFR 1.55. When an English language translation of a non-English language foreign application is required, the translation must be that of the certified copy (of the foreign application as filed) submitted together with a statement that the translation of the certified copy is accurate. See MPEP §§ 215 and 216. Examiner requests an English translation of the non-English priority document to ensure that the invention in the priority document is the same invention being claimed as in the patent application, with no new matter introduced since the filing of the priority document.
Specification
The use of the terms “Linux”, “Unix”, and “Windows”, which are trade names or marks used in commerce, has been noted in this application. The terms should be accompanied by the generic terminology; furthermore the term should be capitalized wherever it appears or, where appropriate, include a proper symbol indicating use in commerce such as ™, SM , or ® following the term.
Although the use of trade names and marks used in commerce (i.e., trademarks, service marks, certification marks, and collective marks) are permissible in patent applications, the proprietary nature of the marks should be respected and every effort made to prevent their use in any manner which might adversely affect their validity as commercial marks.
Claim Interpretation
1. The Examiner notes the broadest reasonable interpretation of claims that include a contingent limitation does not require the contingent limitation “if”, or the following limitations as the step happens in response to the contingent limitation, i.e. at least in claims 2, 3, 18, 19.
2. The broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent are not met. For example, assume a method claim requires step A if a first condition happens and step B if a second condition happens. If the claimed invention may be practiced without either the first or second condition happening, then neither step A or B is required by the broadest reasonable interpretation of the claim. If the claimed invention requires the first condition to occur, then the broadest reasonable interpretation of the claim requires step A. If the claimed invention requires both the first and second conditions to occur, then the broadest reasonable interpretation of the claim requires both steps A and B.
3. The broadest reasonable interpretation of a system (or apparatus or product) claim having structure that performs a function, which only needs to occur if a condition precedent is met, requires structure for performing the function should the condition occur. The system claim interpretation differs from a method claim interpretation because the claimed structure must be present in the system regardless of whether the condition is met and the function is actually performed.
4. . See MPEP § 2111.04.
In claim 1, Examiner notes that the broadest reasonable interpretation does not require the contingent limitations that follow the “if the first process is formed by the execution of the second executable file, the second executable file is encrypted […]” recitations.
In claim 2, Examiner notes that the broadest reasonable interpretation does not require the contingent limitations that follow the “if the shared library is encrypted” recitation.
In claim 5, Examiner notes that the broadest reasonable interpretation does not require the contingent limitations that follow the “if the first process is formed by execution of the second executable file […]” recitation.
In claim 6, Examiner notes that the broadest reasonable interpretation does not require the contingent limitations that follow the “if the first process is formed by execution of the second executable file […]” recitation.
In claim 8, Examiner notes that the broadest reasonable interpretation does not require the contingent limitations that follow the “if the contents of the page have not been decrypted […]” recitation.
In claim 9, Examiner notes that the broadest reasonable interpretation does not require the contingent limitations that follow the “if the first executable file is encrypted and the first process is allowed to […]” and “if the shared library is encrypted […]” recitations.
Claim Rejections - 35 USC § 112(b)
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-10 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The term “about to” in claim 1 is a relative term which renders the claim indefinite. The term “about to” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. The Specification does not appear to define the term “about to” with regards to executing a first executable file being executed, performing memory mapping that is encrypted, and a second process debugging the first process. As a result of the term not being defined, a person of ordinary skill in the art would not understand how to make or use the invention with the lack of a definition of “about to” in the invention of the Applicant.
Dependent claims 2-9 inherit the rejections of their respective independent claims, and as a result, claims 2-9 are rejected for similar reasons to claim 1 above.
Similar issues are also present in claim 2 and 5 regarding the term “about to” present in the recitation of the claims.
Claim 10 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. The phrase “configured for” in claim 10, line 2 is considered exemplary claim language. As stated in MPEP 2173.05(g), "Functional Limitations", use of language in the claims to get an intended result does not "provide a clear cut indication of scope because it imposed no structural limits”, and does not make it clear for a person of ordinary skill in the art as to whether executing an operating system (“OS”) and the protection method of claim 1 in the OS is a required aspect of the invention or not.
Claim Rejections - 35 USC § 103
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-2, and 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over Gilli (US 20180181729 A1), in view of Maeda et al. (US 20090307783 A1), hereinafter Maeda.
Regarding claim 1, Gilli discloses “a protection method for executable files and shared libraries, executed by at least one processor of an electronic device in an operating system of the electronic device, and the protection method comprising: determining, by the electronic device, whether a first process is being debugged or is formed by execution of a second executable file” ([0061] Fig. 3, step S24, launcher module 14 of protected computer program 10 on the computer system detects whether a debugger is active, which detects the first process being debugged.);
“if the first process is being debugged and is about to execute a first executable file that is encrypted, prohibiting the first process from executing the first executable file” ([0010] Computer program is protected by means of encryption. [0061] If the launcher module 14 detects a debugger being active, the launcher executable is terminated, as stated in [0062], corresponding to prohibiting execution of the first executable file.);
“if the first process is being debugged and is about to perform memory mapping on a shared library that is encrypted, prohibiting the first process from performing the memory mapping on the shared library” ([0010] Computer program is protected by means of encryption. [0040] Bootstrap module 20 contains functions for loading program libraries 22 and 26 into the virtual machine, which corresponding to performing of memory mapping, with program libraries 22 being encrypted. [0026] Launcher module detects a debugger used for reading executed program libraries, operation of the program may be terminated to prevent reading.);
Gilli does not appear to disclose, but Maeda teaches the limitation of “and if the first process is formed by the execution of the second executable file, the second executable file is encrypted, and a second process is about to debug the first process, prohibiting the second process from debugging the first process” ([0037] Secure debugger operates in the secure mode to prevent unauthorized analysis of the program, also described in paragraph [0004], corresponding to a second executable file being encrypted. [0164] The protected program 8 is kept encrypted until the execution start, as encrypted protected-program 73, Fig. 5. [0284]-[0291] Fig. 11, debugger 14 attaches to a normal program, and when a debugger-use switching driver is opened after debugger notifies of a debug function 7 opearting in protection mode, a protected program is loaded and executed, corresponding to a first process being formed by execution of the second executable file, being the debugger. [0293] S309 checks whether the stop flag for the process ID has been activated, and if active (S309: YES), the entry point of a protected program 8a has its instruction changed to a break instruction, corresponding to prohibiting second procerss from debugging the first process.).
Therefore, one of ordinary skill in the art would have been capable of applying the known methods of “and if the first process is formed by the execution of the second executable file, the second executable file is encrypted, and a second process is about to debug the first process, prohibiting the second process from debugging the first process” in a protection method for executable files and shared libraries and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated to further provide security to a program in a secure mode as debugging a target program in a secure mode to prevent unauthorized analysis, as two separate programs (one in normal mode, one in secure mode) cannot directly access each other, so a breakpoint is set for the entry instructions in the debugger (Maeda [0038], [0043]-[0045]).
Regarding claim 2, Gilli in view of Maeda teaches the method of claim 1 as recited above. Gilli also discloses “wherein after the first process performs the memory mapping on the shared library, the protection method further comprises: if the shared library is encrypted and the second process is about to debug the first process, prohibiting the second process from debugging the first process” ([0040] Bootstrap module 20 contains functions for loading program libraries 22 and 26 into the virtual machine, which corresponding to performing of memory mapping, with program libraries 22 being encrypted. [0026] Launcher module detects a debugger used for reading executed program libraries, operation of the program may be terminated to prevent reading. [0061] If the launcher module 14 detects a debugger being active, the launcher executable is terminated, as stated in [0062], corresponding to prohibiting execution of the first executable file.).
Regarding claim 9, Gilli in view of Maeda teaches the method of claim 1 as recited above. Gilli also discloses “further comprising: if the first executable file is encrypted and the first process is allowed to execute the first executable file” ([0010] Computer program is protected by means of encryption. [0061] If the launcher module 14 detects a debugger being active, the launcher executable is terminated, as stated in [0062]. This implies that when no debugger is detected, the first process is allowed to execute the first executable file.),
“and if the shared library is encrypted and the first process is allowed to perform the memory mapping on the shared library” ([0040] Bootstrap module 20 contains functions for loading program libraries 22 and 26 into the virtual machine, which corresponding to performing of memory mapping, with program libraries 22 being encrypted. [0026] Launcher module detects a debugger used for reading executed program libraries, and this implies that when no debugger is detected, the operation of the program is allowed to continue.);
Gilli does not appear to disclose, but Maeda teaches the limitations of “moving, by the electronic device, the first executable file out of a page cache of the operating system” ([0265] Fig. 8, S201, start up normal program and open switching driver, and in S202, protected OS loads encrypted protected-program. [0281] When protected program use is completed, S210 describes deletion of the protected program from the protected OS. [0157] Protected program 8 is temporarily stored in the storage area of the protected OS.).
and “moving, by the electronic device, the shared library out of the page cache” ([0265] Fig. 8, S201, start up normal program and open switching driver, and in S202, protected OS loads encrypted protected-program. [0281] When protected program use is completed, S210 describes deletion of the protected program from the protected OS. [0157] Protected program 8 is temporarily stored in the storage area of the protected OS.).
Therefore, one of ordinary skill in the art would have been capable of applying this known method of “moving, by the electronic device, the first executable file out of a page cache of the operating system” and “moving, by the electronic device, the shared library out of the page cache” in a protection method for executable files and shared libraries and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated to load the protected program and its components when no debugging is being performed when called by a normal program into the operating system (“OS”), and is deleted from the memory of the OS when it becomes unnecessary to keep in memory, and the debugger cannot be attached to a program that is not loaded into memory (Maeda, [0296], [0435]).
Regarding claim 10, Gilli in view of Maeda teaches the method of claim 1 as recited above. Gilli also discloses “a protection system for executable files and shared libraries” ([0059] System may be a PC and/or the launcher module 20 may use an X509 certificate to verify if it is allowed to run on the current computer.);
“and at least one processor configured for executing the protection method of claim 1” ([0069] A single processor or controller or other unit may fulfil the functions of several items recited in the claims.)
Gilli does not appear to disclose, but Maeda teaches the limitations of “a storage device where an operating system is installed” ([0446] Present invention can be a recording medium that can be recorded by a computer, such as a hard disk. Operating systems being installed on the hard disk is an inherent aspect of the data processing apparatus present in Fig. 1.);
and “executing the operating system […] and executing the method […] in the operating system” ([0446] Present invention can be a recording medium that can be recorded by a computer, such as a hard disk. Operating systems being installed on the hard disk is an inherent aspect of the data processing apparatus present in Fig. 1.).
Therefore, one of ordinary skill in the art would have been capable of applying this known method of "a storage device where an operating system is installed" and “executing the operating system […] and executing the method […] in the operating system” in a protection method for executable files and shared libraries and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated to have the medium be read on a computer that records the computer program, such as from a hard drive that can also contain the operating system, including as a digital signal recorded on a recording medium, such as optical media or semiconductor memory (Maeda, [0446]).
Claims 3-4 are rejected under 35 U.S.C. 103 as being unpatentable over Gilli in view of Dai et al. (US 20230244389 A1), hereinafter Dai.
Regarding claim 3, Gilli in view of Maeda teaches the method of claim 1 as recited above. Gilli also discloses “further comprising: determining, by the electronic device, whether the first executable file is encrypted” ([0061] If the launcher module 14 detects a debugger being active, the launcher executable is terminated.).
Gilli does not appear to disclose, but Dai teaches the limitation of “whether the first executable file is encrypted according to a flag field of a header of the first executable file” ([0024] Header includes several fields, including SIGN stated in paragraph [0025], which indicates if a file is encrypted, corresponding to a flag field of a header of files.).
Therefore, one of ordinary skill in the art would have been capable of applying this known method of “whether the first executable file is encrypted according to a flag field of a header of the first executable file” in a protection method for executable files and shared libraries and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated to include fields that encode an identifier for cryptography cipher suite and encryption block size used in a new encryption file, assisting in the identification on the type of encryption used in the file (Dai, [0127]).
Regarding claim 4, Gilli in view of Maeda teaches the method of claim 1 as recited above. Gilli also discloses “further comprising: determining, by the electronic device, whether the shared library is encrypted” ([0040] Program libraries 22 are encrypted. [0026] Launcher module detects a debugger used for reading executed program libraries, operation of the program may be terminated to prevent reading.).
Gilli does not appear to disclose, but Dai teaches the limitation of “whether the shared library is encrypted according to a flag field of a header of the shared library” ([0024] Header includes several fields, including SIGN stated in paragraph [0025], which indicates if a file is encrypted, corresponding to a flag field of a header of files.).
Therefore, one of ordinary skill in the art would have been capable of applying this known method of "whether the shared library is encrypted according to a flag field of a header of the shared library" in a protection method for executable files and shared libraries and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated to include fields that encode an identifier for cryptography cipher suite and encryption block size used in a new encryption file, assisting in the identification on the type of encryption used in the file (Dai, [0127]).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Gilli in view of Maeda, further in view of Dai.
Regarding claim 5, Gilli in view of Maeda teaches the method of claim 1 as recited above. Gilli does not appear to disclose or suggest, but Maeda teaches the limitations of “wherein if the first process is formed by the execution of the second executable file, the protection method further comprises: when executing the second executable file” ([0037] Secure debugger operates in the secure mode to prevent unauthorized analysis of the program, also described in paragraph [0004], corresponding to a second executable file being encrypted. [0164] The protected program 8 is kept encrypted until the execution start, as encrypted protected-program 73, Fig. 5. [0284]-[0291] Fig. 11, debugger 14 attaches to a normal program, and when a debugger-use switching driver is opened after debugger notifies of a debug function 7 opearting in protection mode, a protected program is loaded and executed, corresponding to a first process being formed by execution of the second executable file, being the debugger.);
“if the second executable file is determined to be encrypted, setting a label in a security context pointed to by a task structure of the first process” ([0289] Debug function stores the notified process ID of the normal program 12a by the debugger-use switching driver, and activates a stop flag for the protected program 8a.);
“when the second process is about to perform the debugging of the first process, checking whether the label has been set in the security context of the first process” ([0293] S309 checks whether the stop flag for the process ID has been activated, and if active (S309: YES), the entry point of a protected program 8a has its instruction changed to a break instruction.);
“and if the label has been set in the security context, prohibiting the second process from performing the debugging of the first process” ([0293] When the entry point of a protected program 8a has its instruction changed to a break instruction, the protected program stops execution when executed with the debugger, corresponding to prohibiting second procerss from debugging the first process.);
Therefore, one of ordinary skill in the art would have been capable of applying the known methods of “wherein if the first process is formed by the execution of the second executable file, the protection method further comprises: when executing the second executable file”, “if the second executable file is determined to be encrypted, setting a label in a security context pointed to by a task structure of the first process”, “when the second process is about to perform the debugging of the first process, checking whether the label has been set in the security context of the first process”, and “if the label has been set in the security context, prohibiting the second process from performing the debugging of the first process” in a protection method for executable files and shared libraries and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated to further provide security to a program in a secure mode as debugging a target program in a secure mode to prevent unauthorized analysis, as two separate programs (one in normal mode, one in secure mode) cannot directly access each other, so a breakpoint is set for the entry instructions in the debugger (Maeda [0038], [0043]-[0045]).
Gilli in view of Maeda teaches the limitations of “wherein if the first process is formed by the execution of the second executable file, the protection method further comprises: when executing the second executable file”. Gilli in view of Maeda do not appear to suggest, but Dai teaches the limitation of “determining whether the second executable file is encrypted according to a flag field of a header of the second executable file” ([0024] Header includes several fields, including SIGN stated in paragraph [0025], which indicates if a file is encrypted, corresponding to a flag field of a header of files.).
Therefore, one of ordinary skill in the art would have been capable of applying this known method of "determining whether the second executable file is encrypted according to a flag field of a header of the second executable file" in a protection method for executable files and shared libraries and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated to include fields that encode an identifier for cryptography cipher suite and encryption block size used in a new encryption file, assisting in the identification on the type of encryption used in the file (Dai, [0127]).
Claims 6-7 are rejected under 35 U.S.C. 103 as being unpatentable over Gilli in view of Maeda as applied to claim 1 above, and further in view of Volckaert et al. (US 20190286551 A1), hereinafter ‘Volck’.
Regarding claim 6, Gilli in view of Maeda teaches the method of claim 1 as recited above. Gilli does not appear to disclose or suggest, but Maeda teaches the limitations of “wherein if the first process is formed by the execution of the second executable file and the second executable file is encrypted, the protection method further comprises: replacing, by the electronic device, a first memory mapping handling function recorded in a file structure of the second executable file with a second memory mapping handling function” ([0032] Fig. 2, Memory access of a code fragment cannot be performed as it was originally, so in S26, so memory accesses are replaced with memory support functions that access memory in the debuggee's address space, corresponding to replacing a first memory mapping handling function (memory access of code fragment in original software) with a second memory mapping handling function (debugger's memory support functions), which is handled in the debugger loop after an exception in the debuggee process.);
“wherein the second memory mapping handling function comprises: calling, by the electronic device, the first memory mapping handling function” ([0017] Debugger is invoked and provides memory support functions when a breakpoint in software is reached, and debugger is attached to the software process.);
“and replacing, by the electronic device, a first page fault handling function provided by a file system containing the second executable file with a second page fault handling function” ([0032] describes S23, where a debugger handles an exception in the debuggee process, and [0062] describes invalid memory accesses (such as segmentation faults), and dereferencing of an invalid pointer as such exceptions. The handling of exceptions in the debuggee process equates to a second page fault handling function, as opposed to letting the exception crash the debuggee program by the system, equating to a first page fault handling function.).
Therefore, one of ordinary skill in the art would have been capable of applying this known method of "wherein if the first process is formed by the execution of the second executable file and the second executable file is encrypted […] replacing, by the electronic device, a first memory mapping handling function recorded in a file structure of the second executable file with a second memory mapping handling function" and subsequent limitations in a protection method for executable files and shared libraries and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated to attach a debugger to a program to create a protected, self-debugging application, as the debugger process in the self-debugging application cannot be replaced without taking away most of the functionality of the application, and as most operating systems only allow a single debugger to be paired with any one process at a given time, with the debugger process using the debugger where most operating systems allow just one debugger with a corresponding process (Volck, [0010]).
Regarding claim 7, Gilli in view of Maeda teaches the method of claims 1 and 6 as recited above. Gilli does not appear to disclose, but Volck teaches the limitation of “wherein the second page fault handling function comprises: calling, by the electronic device, the first page fault handling function to load a page causing page fault of the first process from the file system into a virtual address space of the first process” ([0032] describes S23, debugger is notified of an exception and handles it in debugger loop in S24, Fig. 2. Migrated code executes in the debugger address space as opposed to the debuggee address space, wherein the debugger address space corresponds to virtual address space of the first process.).
Therefore, one of ordinary skill in the art would have been capable of applying this known method of "wherein the second page fault handling function comprises: calling, by the electronic device, the first page fault handling function to load a page causing page fault of the first process from the file system into a virtual address space of the first process" in a protection method for executable files and shared libraries and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated to utilize the mini-debugger to fetch the state of the program state of the debuggee (program being debugged) before a certain fragment of the debuggee is executed, so that the debugger performs the functionality of the fragment of what was originally of the original application to be performed in the debugger (Volck, [0067]-[0069]).
Gilli in view of Volck do not appear to suggest, but Maeda teaches the limitations of “checking, by the electronic device, whether contents of the page have been decrypted” ([0163] Protected program 8 is kept encrypted until execution of the program starts to prevent unauthorized analysis, and is decrypted by protected OS 6 when execution starts.);
and “decrypting, by the electronic device, the contents of the page if the contents of the page have not been decrypted” ([0163] Protected program 8 is decrypted by protected OS 6 when execution starts.).
Therefore, one of ordinary skill in the art would have been capable of applying this known method of "checking, by the electronic device, whether contents of the page have been decrypted" and “decrypting, by the electronic device, the contents of the page if the contents of the page have not been decrypted” in a protection method for executable files and shared libraries and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated to decrypt the contents relating to rights of a movie and copying of content, such as encrypted digital rights to the media, and is kept encrypted until execution of the program starts to prevent unauthorized analysis, and is decrypted by the protected OS at the beginning of execution (Maeda [0162]-[0163]).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Gilli in view of Maeda further in view of Volck as applied to claims 1, 6-7 above, and further in view of Dai.
Regarding claim 8, Gilli in view of Maeda further in view of Volck teach the limitations of claims 1, 6-7 above. Meada further teaches the limitations of “further comprising: if the contents of the page have not been decrypted, using, by the electronic device, a decryption algorithm” ([0170] Fig. 5, encrypted protected program contains a decryption-use header information that contains an algorithm used for encryption, an address for which the protected program 8 is loaded, and contains information required for decryption.).
Therefore, one of ordinary skill in the art would have been capable of applying this known method of “further comprising: if the contents of the page have not been decrypted, using, by the electronic device, a decryption algorithm” in a protection method for executable files and shared libraries and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated to decrypt the contents relating to rights of a movie and copying of content, such as encrypted digital rights to the media, and is kept encrypted until execution of the program starts to prevent unauthorized analysis, and is decrypted by the protected OS at the beginning of execution (Maeda [0162]-[0163]).
Gilli in view of Maeda further in view of Volck does not appear to suggest, but Dai teaches the limitations of “a decryption algorithm indicated in a flag field of a header of the second executable file to decrypt the contents of the page” (Fig. 8, header of an encrypted file includes cipher suite 814 that contains various algorithms for encryption and decryption, including decrypting a block of encrypted data, using an encryption key associated with a matching entry, to obtain a block of plaintext data.).
Therefore, one of ordinary skill in the art would have been capable of applying this known method of “a decryption algorithm indicated in a flag field of a header of the second executable file to decrypt the contents of the page” in a protection method for executable files and shared libraries and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated to include fields that encode an identifier for cryptography cipher suite and encryption block size used in a new encryption file, assisting in the identification on the type of encryption used in the file (Dai, [0127]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
CN 103136458 B (Cheng, “A Dynamic Linux Operating System Library Code Protection Method And Device Thereof”)
US 20160275019 A1 (Nam et al., “METHOD AND APPARATUS FOR PROTECTING DYNAMIC LIBRARIES”)
CN 114398598 A (“A Library File Encryption Method, Decryption Method And Encryption Device”)
WO 2017156962 A1 (Liu et al., “ELF SHARED LIBRARY PROTECTION METHOD AND SYSTEM”)
US 20060173875 A1 (Stefaniak, “Server Consolidation Data Mdel”)
US 20210117544 A1 (Kurtz et al., “Analysis Of Malware”)
US 20190163885 A1 (Park et al., “APPARATUS AND METHOD OF PROVIDING SECURITY AND APPARATUS AND METHOD OF EXECUTING SECURITY FOR COMMON INTERMEDIATE LANGUAGE”)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TOMMY MARTINEZ whose telephone number is (703)756-5651. The examiner can normally be reached Monday thru Friday 8AM-4PM ET.
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, Jorge L. Ortiz-Criado can be reached at (571) 272-7624 on Monday thru Friday, 7AM-7PM ET. 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.
/T.M./ Examiner, Art Unit 2496
/JORGE L ORTIZ CRIADO/ Supervisory Patent Examiner, Art Unit 2496