DETAILED ACTION
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 .
This office action is in response to amendments filed on April 6, 2026.
Claims 1-2, 7-8, 13-14 have been amended.
Claims 1-18 are pending.
Response to Arguments
Applicant's arguments filed April 6, 2026 have been fully considered but they are not persuasive.
Applicant mainly argues in pages 1-3 of Remarks that Teal does not teach the limitation of “and wherein the injection/HOOK comprises replacing an entry address of a target function with a function address of a third party library injected by an attacker to change a function in the service application program”. Examiner respectfully disagrees. Regarding the limitation, the description of injection/HOOK in the limitation is directed towards a well-known means for library injection using hooking, see NPL – “Hooking”. This is further corroborated by the Applicant’s specification at paragraph [0043], which includes “The attacker usually replaces, by using a combination of injection and HOOK technologies, an entry address of a target function with a function address of the third party library injected by the attacker”. Therefore, when Teal teaches detection of library injection, this suggests the claimed limitation if it can be shown that the library injection detected by Teal is achieved through hooking. In Teal, one of the library injection techniques detected regard Skape/JT type memory attacks regarding their 2004 paper NPL - “Remote Library Injection” (Par. [0031]). NPL – “Remote Library Injection” describes methods of library injection and this includes hooking: “the general approach is to hook the underlying file operations that the dynamic loader uses to load a library.” (Page 17, Par. 1). Therefore, by teaching detection of Skape/JT type memory injection attacks, Teal further teaches the claimed limitation. Since the methodology of this type of library injection attack is known and considered “usual” by the Applicant’s specification, it is recommended by the Examiner that the claims focus on how such detection of injection/HOOK is performed instead.
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 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, 7, 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Isenberg et al. (U.S. Patent No. 7,823,205 B1) hereinafter referred to as “Isenberg”, and further in view of Zhang (CN 115186270 A) hereinafter referred to as “Zhang”, and further in view of Teal et al. (U.S. Pub. No. 2013/0290662 A1) hereinafter referred to as “Teal”.
Regarding Claim 1:
Isenberg teaches the following limitations:
A method for mobile-terminal (Fig. 2, Col. 2, lines 22-32, Col. 3, lines 12-20, Col. 3, lines 46-59, Col. 4, lines 18-67, Col. 5, lines 1-53). Isenberg teaches a security system which monitors and detects malicious threats on a computer, and this computer can be a mobile device.
(taught by Teal below)
(taught by Zhang below)
(taught by Zhang below)
Zhang teaches the following limitations:
aspect-oriented security (Abstract, Page 5, Par. 3-5). Zhang is directed towards a system for aspect-oriented security.
and in response to determining that the mobile terminal is at risk: determining, based on a manner the mobile terminal is attacked, an attacked function [aim at vulnerability] in the service application program as an injection point [injection point is same as point of repair] (Page 4, Par. 1-2, Page 5, Par. 3-5, Page 10, Par. 3). Zhang teaches monitoring a service application program for vulnerabilities, i.e. at risk of attack, and injecting a patch program to repair the vulnerability in an aspect-oriented manner. Zhang further teaches that the patch program can be injected at a pointcut or a location where the vulnerability is detected.
and injecting an aspect program [vulnerability patch] from the injection point by using an aspect base of the aspect-oriented security on the mobile terminal to execute an aspect-oriented security service by using the injected aspect program (Page 4, Par. 1-2, Page 5, Par. 3-5, Page 10, Par. 3). Zhang teaches that the patch program is injected to repair the vulnerability.
Isenberg teaches a security system for mobile devices, but does not teach aspect-oriented security. Zhang however teaches that program security can be implemented in an aspect-oriented manner, and this has the advantage of quickly repairing vulnerabilities and separating concerns (Page 2, Par. 1-2, Page 6, Par. 1-2). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the security monitoring system of Isenberg with the aspect-oriented security of Zhang in order to gain the benefit of improved protection against attacks. One of ordinary skill in the art would have recognized that the aspect-oriented security of Zhang is compatible with the system of Isenberg as both are directed towards monitoring and handling security threats in programs. One of ordinary skill would have understood that this aspect-oriented paradigm separates security aspects from the rest of the code, allowing for independent and quicker development time in security patching as described by Zhang (Page 2, Par. 1-2, Page 6, Par. 1-2). Therefore, one of ordinary skill would have recognized that aspect-oriented security would provide the benefit of increased efficiency in repairing vulnerabilities.
Teal teaches the following limitation:
wherein determining whether the mobile terminal is at risk of being attacked comprises determining whether injection/HOOK occurs on the service application program, and wherein the injection/HOOK comprises replacing an entry address of a target function with a function address of a third party library injected by an attacker to change a function in the service application program (Par. [0031]-[0035]). Teal teaches injection detection where such injection involves library code. This includes Skape/JT library injection attacks which use hooking.
Isenberg/Zhang teach mobile device security, but do not teach injection detection. Teal however teaches that memory injections are attacks that are appealing to hackers (Par. [0030], Par. [0031]). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the system of Isenberg/Zhang with the injection detection of Teal in order to gain the benefit of additional security against injection attacks. One of ordinary skill in the art would have recognized that such injection detection of Teal is compatible with the system of Isenberg/Zhang as both are directed towards device security, and that such an injection detection would have the benefit of additional security by detecting and thwarting injection attacks.
Regarding Claim 7:
Isenberg teaches the following limitations:
An apparatus for (Fig. 1, Col. 2, lines 22-67).
after (Fig. 2, Col. 2, lines 22-32, Col. 3, lines 12-20, Col. 3, lines 46-59, Col. 4, lines 18-67, Col. 5, lines 1-53).
(taught by Teal below)
(taught by Zhang below)
(taught by Zhang below)
or in response to determining that the mobile terminal is not at risk, turning off the (Col. 3, lines 46-59, Col. 4, lines 18-67, Col. 5, lines 1-53).
Zhang teaches the following limitations:
aspect-oriented security (Abstract, Page 5, Par. 3-5).
and in response to determining that the mobile terminal is at risk: determining, based on a manner the mobile terminal is attacked, an attacked function in the service application program as an injection point (Page 4, Par. 1-2, Page 5, Par. 3-5, Page 10, Par. 3).
and injecting an aspect program from the injection point by using an aspect base of the aspect-oriented security on the mobile terminal to execute an aspect-oriented security service by using the injected aspect program (Page 4, Par. 1-2, Page 5, Par. 3-5, Page 10, Par. 3).
Isenberg teaches a security system for mobile devices, but does not teach aspect-oriented security. Zhang however teaches that program security can be implemented in an aspect-oriented manner, and this has the advantage of quickly repairing vulnerabilities and separating concerns (Page 2, Par. 1-2, Page 6, Par. 1-2). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the security monitoring system of Isenberg with the aspect-oriented security of Zhang in order to gain the benefit of improved protection against attacks. One of ordinary skill in the art would have recognized that the aspect-oriented security of Zhang is compatible with the system of Isenberg as both are directed towards monitoring and handling security threats in programs. One of ordinary skill would have understood that this aspect-oriented paradigm separates security aspects from the rest of the code, allowing for independent and quicker development time in security patching as described by Zhang (Page 2, Par. 1-2, Page 6, Par. 1-2). Therefore, one of ordinary skill would have recognized that aspect-oriented security would provide the benefit of increased efficiency in repairing vulnerabilities.
Teal teaches the following limitations:
wherein determining whether the mobile terminal is at risk of being attacked comprises determining whether injection/HOOK occurs on the service application program, and wherein the injection/HOOK comprises replacing an entry address of a target function with a function address of a third party library injected by an attacker to change a function in the service application program (Par. [0031]-[0035]).
Isenberg/Zhang teach mobile device security, but do not teach injection detection. Teal however teaches that memory injections are attacks that are appealing to hackers (Par. [0030], Par. [0031]). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the system of Isenberg/Zhang with the injection detection of Teal in order to gain the benefit of additional security against injection attacks. One of ordinary skill in the art would have recognized that such injection detection of Teal is compatible with the system of Isenberg/Zhang as both are directed towards device security, and that such an injection detection would have the benefit of additional security by detecting and thwarting injection attacks.
Regarding Claim 13:
Isenberg teaches the following limitations:
A non-transitory, computer-readable medium storing one or more instructions executable by at least one processor to perform operations comprising (Fig. 1, Col. 2, lines 22-67).
after (Fig. 2, Col. 2, lines 22-32, Col. 3, lines 12-20, Col. 3, lines 46-59, Col. 4, lines 18-67, Col. 5, lines 1-53).
(taught by Teal below)
(taught by Zhang below)
(taught by Zhang below)
or in response to determining that the mobile terminal is not at risk, turning off the (Col. 3, lines 46-59, Col. 4, lines 18-67, Col. 5, lines 1-53).
Zhang teaches the following limitations:
aspect-oriented security (Abstract, Page 5, Par. 3-5).
and in response to determining that the mobile terminal is at risk: determining, based on a manner the mobile terminal is attacked, an attacked function in the service application program as an injection point (Page 4, Par. 1-2, Page 5, Par. 3-5, Page 10, Par. 3).
and injecting an aspect program from the injection point by using an aspect base of the aspect-oriented security on the mobile terminal to execute an aspect-oriented security service by using the injected aspect program (Page 4, Par. 1-2, Page 5, Par. 3-5, Page 10, Par. 3).
Isenberg teaches a security system for mobile devices, but does not teach aspect-oriented security. Zhang however teaches that program security can be implemented in an aspect-oriented manner, and this has the advantage of quickly repairing vulnerabilities and separating concerns (Page 2, Par. 1-2, Page 6, Par. 1-2). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the security monitoring system of Isenberg with the aspect-oriented security of Zhang in order to gain the benefit of improved protection against attacks. One of ordinary skill in the art would have recognized that the aspect-oriented security of Zhang is compatible with the system of Isenberg as both are directed towards monitoring and handling security threats in programs. One of ordinary skill would have understood that this aspect-oriented paradigm separates security aspects from the rest of the code, allowing for independent and quicker development time in security patching as described by Zhang (Page 2, Par. 1-2, Page 6, Par. 1-2). Therefore, one of ordinary skill would have recognized that aspect-oriented security would provide the benefit of increased efficiency in repairing vulnerabilities.
Teal teaches the following limitations:
wherein determining whether the mobile terminal is at risk of being attacked comprises determining whether injection/HOOK occurs on the service application program, and wherein the injection/HOOK comprises replacing an entry address of a target function with a function address of a third party library injected by an attacker to change a function in the service application program (Par. [0031]-[0035]).
Isenberg/Zhang teach mobile device security, but do not teach injection detection. Teal however teaches that memory injections are attacks that are appealing to hackers (Par. [0030], Par. [0031]). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the system of Isenberg/Zhang with the injection detection of Teal in order to gain the benefit of additional security against injection attacks. One of ordinary skill in the art would have recognized that such injection detection of Teal is compatible with the system of Isenberg/Zhang as both are directed towards device security, and that such an injection detection would have the benefit of additional security by detecting and thwarting injection attacks.
Claims 2-3, 8-9, 14-15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Isenberg/Zhang/Teal as applied to Claims 1, 7, 13 respectively above, and further in view of Whitmore et al. (U.S. Pub. No. 2021/0319095 A1) hereinafter referred to as “Whitmore”.
Regarding Claims 2, 8, 14:
Whitmore teaches the following limitation:
wherein the determining whether the mobile terminal is at risk of being attacked further comprises: determining whether the mobile terminal encounters jailbreak/ROOT, wherein the jailbreak/ROOT indicates to obtain a highest authority of a system of the mobile terminal; or determining whether the service application program is debugged (Par. [0042]-[0050]). Whitmore teaches jailbreak detection, and it is well known in the art that jailbreaking means bypassing manufacturer restrictions by gaining access to the entire device, i.e. obtain highest authority, such as described by Whitmore in Par. [0023]-[0024]. Under the broadest reasonable interpretation, this teaches the claims as explained in the Examiner’s Comment above.
Isenberg/Zhang/Teal teach mobile device security, but do not teach jailbreak detection. Whitmore however teaches that jailbreaking is a potential source of vulnerability in mobile devices and such detection is beneficial to trace and thwart attacks (Par. [0003], Par. [0023], Par. [0053]). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the system of Isenberg/Zhang/Teal with the jailbreak detection of Whitmore in order to gain the benefit of additional security. One of ordinary skill in the art would have recognized that such jailbreak detection of Whitmore is compatible with the system of Isenberg/Zhang/Teal as both are directed towards mobile device security, and that such a jailbreak detection would have the benefit of additional security by additional vulnerability detection.
Regarding Claims 3, 9, 15:
Whitmore teaches the following limitation:
wherein the determining whether the mobile terminal encounters jailbreak/ROOT comprises: determining whether a high-risk file [indicator application] used for storing configuration information exists in a memory of the mobile terminal (Par. [0042]-[0050]). Whitmore teaches searching for files in memory indicating a jailbreak attempt. Note that under the broadest reasonable interpretation, the phrase “for storing configuration information” constitutes intended usage which carries little patentable weight. Furthermore, as this configuration information is not defined, the jailbreaking application can be considered to be storing configuration information as jailbreaking regards modifying the permissions/protections of a system, i.e. configuration information under the broadest reasonable interpretation.
and in response to determining that the high-risk file exists, determining that the mobile terminal encounters the jailbreak/ROOT (Par. [0042]-[0050]). Whitmore determines a device to be compromised if such a file is found.
or in response to determining that the high-risk file does not exist, determining that the mobile terminal does not encounter the jailbreak/ROOT (Par. [0042]-[0050], Par. [0052]). Whitmore further teaches that not finding files of past or current jailbreak means that the device is determined neither to be compromised nor formerly compromised.
The reasons for motivation/combination of references remain the same as in the rejection of Claims 2, 8, 14 above under Isenberg/Zhang/Teal/Whitmore.
For the sake of clarity and compact prosecution, Claims 2, 8, 14 are alternatively and additionally rejected under 35 U.S.C. 103 as being unpatentable over Isenberg/Zhang/Teal as applied to Claims 1, 7, 13 respectively above, and further in view of Kokubo et al. (U.S. Pub. No. 2017/0302682 A1) hereinafter referred to as “Kokubo”.
Regarding Claims 2, 8, 14:
Kokubo teaches the following limitation:
wherein the determining whether the mobile terminal is at risk of being attacked comprises: determining whether the mobile terminal encounters jailbreak/ROOT, wherein the jailbreak/ROOT indicates to obtain a highest authority of a system of the mobile terminal; or determining whether the service application program is debugged (Par. [0082]). Kokubo teaches debugger detection. Under the broadest reasonable interpretation, this teaches the claims as explained in the Examiner’s Comment above.
Isenberg/Zhang/Teal teach mobile device security, but do not teach debugger detection. Kokubo however teaches that an instruction can be detected for the presence of a debugger, i.e. debugged, and that this has the advantage of more accurate malware detection (Par. [0082]). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the system of Isenberg/Zhang/Teal with the debugger detection of Kokubo in order to gain the benefit of additional security through more accurate malware detection. One of ordinary skill in the art would have recognized that such debugger detection of Kokubo is compatible with the system of Isenberg/Zhang/Teal as both are directed towards device security regarding instructions, and that such a debugger detection would have the benefit of additional security by more accurately detecting malware.
Claims 4, 10, 16 are rejected under 35 U.S.C. 103 as being unpatentable over Isenberg/Zhang/Teal.
Regarding Claims 4, 10, 16:
Teal teaches the following limitation:
wherein the determining whether injection/HOOK occurs on the service application program comprises: traversing entry addresses of functions in the service application program [memory region address information] (Abstract, Par. [0031]-[0035]). Teal teaches iterating over memory region address information and comparing with loaded module address information for injection detection.
determining whether the entry addresses of the functions and the service application program [loaded module address information] are in a same memory address space (Par. [0031]-[0035]). Teal teaches determining injection occurs by checking if memory regions are mapped correctly corresponding to loaded module address information.
in response to determining that the entry addresses and the service application program are in the same memory address space, determining that the injection/HOOK does not occur on the service application program (Par. [0031]-[0035]). Teal teaches ending the process without issuing an alarm once all memory regions are analyzed, i.e. injection does not occur.
or in response to determining that the entry addresses and the service application program are not in the same memory address space otherwise, determining that the injection/HOOK occurs on the service application program (Par. [0031]-[0035]). Teal teaches determining injection occurs if memory regions do not match with what is mapped, i.e. not in the same memory space.
The reasons for motivation/combination of references remain the same as in the rejection of Claims 1, 7, 13 above under Isenberg/Zhang/Teal.
Claims 5, 11, 17 are rejected under 35 U.S.C. 103 as being unpatentable over Isenberg/Zhang/Teal/Kokubo as applied to Claims 2, 8, 14 respectively above, and further in view of NPL – “IsDebuggerPresent”.
Regarding Claims 5, 11, 17:
NPL – “IsDebuggerPresent” teaches the following limitations:
wherein the determining whether the service application program is debugged comprises: reading a value of an object or a file that controls a debugging switch in a memory; and determining the service application program is debugged if the value is true or 1, or determining the service application program is not debugged if the value is false or 0 (Page 1). NPL – “IsDebuggerPresent” teaches that a simple way of checking for the presence of a debugger is by invoking the API function IsDebuggerPresent() which outputs a boolean value which is true when debugged, and false when not debugged.
Isenberg/Zhang/Teal/Kokubo teach mobile device security with debugger detection, but do not teach reading a value regarding a debugging switch. NPL – “IsDebuggerPresent” however teaches that an the presence of a debugger can be simply checked by obtaining the value through the function IsDebuggerPresent(). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the system of Isenberg/Zhang/Teal/Kokubo with the function of NPL – “IsDebuggerPresent” in order to gain the predictable result of reading a value for determining the service application to be debugged or not. One of ordinary skill in the art would have recognized that such a function is compatible with the system of Isenberg/Zhang/Teal/Kokubo as both are directed towards debugger detection, and that such a function would have the predictable result of determining a debugger being present according to the Boolean value it outputs.
Claims 6, 12, 18 are rejected under 35 U.S.C. 103 as being unpatentable over Isenberg/Zhang/Teal/Kokubo.
Regarding Claims 6, 12, 18:
Kokubo teaches the following limitation:
wherein the determining an attacked function as an injection point comprises: determining, as the injection point, a function in the service application program for operating a high-risk file after the mobile terminal encounters jailbreak/ROOT; determining a function with injection/HOOK in the service application program as the injection point; or determining a debugged function in the service application program as the injection point (Par. [0082]). Kokubo teaches determining an instruction being detected as debugged as a vulnerability, and this is used as an injection point in combination with Isenberg/Zheng. Under the broadest reasonable interpretation, this teaches the claims as explained in the Examiner’s Comment above.
The reasons for motivation/combination of references remain the same as in the rejection of Claims 2, 8, 14 above under Isenberg/Zhang/Teal/Kokubo.
Related Art
The following prior art made of record and cited on PTO-892, but not relied upon, is considered pertinent to applicant’s disclosure:
Yoon et al. (U.S. Pub. No. 2019/0286820 A1) – Includes methods regarding hooking and detection
Ko et al. (U.S. Pub. No. 2014/0157366 A1) – Includes methods regarding code injection detection
Chung et al. (U.S. Pub. No. 2014/0156939 A1) – Includes methods regarding mapping detection and library injection
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 ETHAN V VO whose telephone number is (571)272-2505. The examiner can normally be reached M-F 8am-5pm.
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, Lynn Feild can be reached on (571)272-2092. 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.
/E.V.V./Examiner, Art Unit 2431 /TRANG T DOAN/Primary Examiner, Art Unit 2431
Prosecution Insights