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.
Response to Arguments
In page 1 of the remarks, Applicant states that the Specification has been amended to include the appropriate TM symbol following each occurrence of the aforementioned trademarks, those being the terms "Linux," "Unix," and "Windows". Examiner withdraws the objections made to the Specification.
In pages 1-2 of the remarks, Applicant states that claims 1 and 5-9 are amended to remove the contingent limitation from the claims, and replaced the contingent limitation “if” from the limitations to further claim the invention. Furthermore, the claims 1, 5, and 10 are amended to remove the phrases "about to" and "configured for" in response to the 112(b) rejections. Examiner withdraws the claim interpretation limitation, and the subsequent 112(b) rejections regarding the use of contingent limitations.
In pages 2-3 of the remarks, Applicant states that claims 1, 2, 9, and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Gilli (US 2018/0181729 Al, hereinafter "Gilli") in view of Maeda et al. (US 2009/0307783 A1, hereinafter "Maeda'); independent claim 1 has been amended to incorporate technical features based on claim 2, and claim 2 has been canceled. Applicant respectfully submits that the amended claims 1 and 3-10 are patentable over the cited references and respectfully traverses the rejections under 35 U.S.C. § 103 for the reasons set forth below. Applicant states that the Office Action (“OA”) alleges that a person skilled in the art, upon reading the content of Gilli, would have been motivated to combine the concept of "prohibiting the second process from debugging the first process" in paragraph [0293] of the specification of Maeda with the teachings of Gilli to complete the invention claimed by claims 1, 2, 9, and 10. Applicant cites MPEP 2143.01 to state that the proposed modification of the claims cannot change operation of a reference, and the teachings of the references are not sufficient to render the claims prima facie obvious.
In pages 3-5 of the remarks, Applicant states that the Specification of Maeda describes a problem that Maeda seeks to solve regarding enabling authorized developers to perform trusted debugging on protected programs called by “normal programs running in a normal mode (see paragraphs [0005], [0010]-[0013], and particularly paragraph [0014] of the specification of Maeda)”, so that when a user debugs a normal program and a protected program cooperating with the normal program, the invention of Maeda cause the debugger to notify the secure debugger to assist with debugging the protected program, as described in paragraphs [0287]-[0288] of Maeda and steps S302-S304 in FIG. 11 of Maeda. Maeda seeks to solve and the various paragraphs of the specification of Maeda, the central focus is on enabling developers to debug the protected programs, as described in Fig. 11 of Maeda, including “debugging function 7 checking whether the stop flag corresponding to the process ID previously stored in the storage area in the protection mechanism is active”, as described paragraph [0293] of the specification of Maeda and step S309 of Fig. 11. In contrast, Gilli addresses a lack of protections against reverse engineering of byte code, where existing obfuscation techniques provide insufficient protection (see paragraph [0005] of the specification of Gilli). Gilli opts to completely block any potential vulnerabilities and thus adopts the fundamental operating principle of "debugging equals termination." Applicant states that Gilli and Maeda “involve mutually exclusive fundamental principles of operation”, with Maeda’s flexible debugging mechanism operating with the zero-trust debugging architecture of Gilli, with Gilli’s invention failing to “achieve its intended objective, and the logic and the timing established in Gilli for determining whether the debugger is active would become substantially meaningless”, and the combination of teachings of Gilli and Maeda are not sufficient to render independent claim 1, the dependent claims thereof, and the corresponding system claim 10 obvious.
Applicant's arguments filed June 17, 2026 have been fully considered but they are not persuasive. Regarding Gilli’s invention that is operating in a zero-trust debugging architecture, while it is stated in paragraph [0059] that Gilli describes, in Fig. 3, step S22, that a launcher module 14 tests if a “computer program is allowed to run on the system, which executes the launcher executable”, such as be utilizing an “X509 certificate to verify if it is allowed to run on the current computer“, where these certificates are used to allow the programs to run on the hardware, even if it is to be checked every time the program initiates. Furthermore, in paragraph [0061] of Gilli, in Fig. 3, step S24, the method checks whether a debugger is active, checking for manipulation of the activation as well, and if detected, the launcher executable program is terminated before decryption of the program in S26. Maeda’s paragraph [0379] states that a menu for a debugger is also present, including options for opening and attaching of the debug target program, termination of the debugger itself, and manipulation of the target program, including in [0444] when “detection of a general error interruption occurred during the execution of the protected program 8”. In spite of the dueling purposes that the invention of Gilli and Maeda operate in, which includes ‘termination of a program when a debugger is detected’ and ‘assistance in debugging a program’, respectively, Examiner states that under MPEP 2143.01, the prior arts of Gilli and Maeda can be combined 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]). Additionally, Gilli’s statement that “the launcher module 14 tests, whether the computer program is allowed to run on the system, which executes the launcher executable” in paragraph [0059], can be applied to Maeda’s Fig. 7, which shows whether a debugger is allowed to operate based on the decision made by the debugger ID judging unit in S101 of Fig. 7, also recited in paragraphs [0257]-[0260].
In pages 6-7 of the remarks, amended independent claim 1 recites, inter alia, the distinguishing technical feature "prohibiting, by the electronic device, a second process from debugging the first process after the first process performs memory mapping on a shared library that is encrypted", with the OA alleging that paragraphs [0026], [0040], [0061], and [0062] of the specification of Gilli already disclose the technical contents "after the first process performs the memory mapping on the shared library, […] 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" of claim 2, being moved to independent claim 1. Applicant states that paragraphs [0061] and [0062] of the specification of Gilli describe the method flow shown in FIG. 3 of Gilli, where “step S24 detects whether a debugger is active [and if] active, the launcher executable 12 and/or the virtual machine is/are terminated, and then, in the subsequent step S28, the bootstrap library 16 including the libraries 22, 26 is loaded into the virtual machine”, which Gilli prohibits the second process from debugging the first process before the first process performing memory mapping, while the claimed invention “prohibits the second process from debugging the first process after the first process performs memory mapping”. Applicant states that Gilli does not disclose “prohibiting, by the electronic device, a second process from debugging the first process after the first process performs memory mapping on a shared library that is encrypted”. Applicant also states that none of “none of Maeda, Dai, and Volck discloses the aforementioned” limitation of “prohibiting, by the electronic device, a second process from debugging the first process”.
Examiner disagrees with the Applicant regarding the amended claim limitations being in an allowable state over the prior art references. In the amended limitation of “prohibiting, by the electronic device, a second process from debugging the first process after the first process performs memory mapping on a shared library that is encrypted”, while not disclosed by Gilli, is taught by Maeda in the following sections: [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. [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. A person of ordinary skill in the art would utilize the references of Gilli and Maeda 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]). As a result, claims 1, and 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over Gilli in view of Maeda. The remaining claim rejections remain rejected under their previous combination of references under U.S.C. 103.
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, 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.);
“determining, by the electronic device, that a first process is being debugged, and then prohibiting the first process from executing a first executable file that is encrypted” ([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.);
Gilli does not appear to disclose, but Maeda teaches the limitation of “prohibiting, by the electronic device, a second process from debugging the first process after the first process performs memory mapping on a shared library that is encrypted” ([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. [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.);
Therefore, one of ordinary skill in the art would have been capable of applying the known methods of “prohibiting, by the electronic device, a second process from debugging the first process after the first process performs memory mapping on a shared library that is encrypted” 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 9, Gilli in view of Maeda teaches the method of claim 1 as recited above. Gilli also discloses “further comprising: determining, by the electronic device, that the first executable file is encrypted” ([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 determining, by the electronic device, that the shared library is encrypted” ([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 “and then moving 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 “and then moving 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 “and then moving the first executable file out of a page cache of the operating system” and “and then moving 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 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 the first process is formed by execution of a second executable file that is encrypted, and the protection method further comprising:” ([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.);
“determining, by the electronic device, whether the second executable file is encrypted, and then 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.);
“before the second process performs the debugging of the first process, checking, by the electronic device, 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 determining, by the electronic device, that the label has been set in the security context, and then 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 the first process is formed by execution of a second executable file that is encrypted, and the protection method further comprising: determining, by the electronic device, whether the second executable file is encrypted”. Gilli in view of Maeda do not appear to suggest, but Dai teaches the limitation of “determining, by the electronic device, 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 the first process is formed by execution of a second executable file that is encrypted, and the protection method further comprising: 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 “determining, by the electronic device, that the contents of the page have not been decrypted, and then decrypting the contents of the page” ([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 “determining, by the electronic device, that the contents of the page have not been decrypted, and then decrypting 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 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: 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: 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
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 TOMMY MARTINEZ whose telephone number is (703)756-5651. The examiner can normally be reached at Tommy.Martinez@uspto.gov on 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
Prosecution Insights