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 .
EXAMINER’S COMMENT
Regarding the claimed invention, the claims recite the conjunction “or” in several places. It is noted by the Examiner that recitation of the conjunction “or” means that among a list of options such A, B, or C, the prior art need only read upon one option to meet the claimed limitation, such as merely teaching option B in the example above. As a further example, in the case of Claim 1, Claim 1 recites the following:
A method for mobile-terminal aspect-oriented security, comprising: after aspect-oriented security on a mobile terminal is turned on with a service application program on a mobile terminal, determining whether the mobile terminal is at risk of being attacked; (A) and in response to determining that the mobile terminal is at risk: ….(B) or in response to determining that the mobile terminal is not at risk, turning off the aspect-oriented security on the mobile terminal.
Regarding the bolded section above, since the claim recites two options (labeled A and B accordingly), the prior art can merely teach option B without teaching the limitations of option A and still read upon the claim. As a further example, Claim 2 recites the following:
The method according to claim 1, wherein the determining whether the mobile terminal is at risk of being attacked comprises: (A) 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;(B) determining whether injection/HOOK occurs on the service application program, wherein the injection/Hook indicates to replace 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;(C) or determining whether the service application program is debugged.
Similarly, for Claim 2 above, the prior art need only teach one of options A, B, or C to read upon Claim 2. Dependent Claims 3-5 however are directed towards further clarification of the options above. For example, Claim 3 recites “The method according to claim 2, wherein the determining whether the mobile terminal encounters jailbreak/ROOT comprises…” This means that if Claim 2 were to be rejected under the prior art teaching option C, Claim 3 would be automatically rejected as well since Claim 3 is directed towards narrowing the scope of option A.
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”.
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 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). Isenberg further teaches that the security module can be disabled to conserve resources.
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.
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 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.
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 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.
Claims 2-3, 8-9, 14-15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Isenberg/Zhang 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 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; determining whether injection/HOOK occurs on the service application program, wherein the injection/Hook indicates to replace 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; 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 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 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 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/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 as applied to Claims 1, 7, 13 respectively above, and further in view of Teal et al. (U.S. Pub. No. 2013/0290662 A1) hereinafter referred to as “Teal”.
Regarding Claims 2, 8, 14:
Teal 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; determining whether injection/HOOK occurs on the service application program, wherein the injection/Hook indicates to replace 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; or determining whether the service application program is debugged (Par. [0031]-[0035]). Teal teaches injection detection where such injection involves library code. Under the broadest reasonable interpretation, this teaches the claims as explained in the Examiner’s Comment above.
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.
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 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; determining whether injection/HOOK occurs on the service application program, wherein the injection/Hook indicates to replace 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; 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 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 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 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 2, 8, 14 above under Isenberg/Zhang/Teal.
Claims 5, 11, 17 are rejected under 35 U.S.C. 103 as being unpatentable over Isenberg/Zhang/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/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/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/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/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/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:
Stafford (U.S. Pub. No. 2017/0364686 A1) – Includes methods regarding injection of security protocols
Shaw et al. (U.S. Pub. No. 2021/0329032 A1) – Includes methods regarding wireless security
Lee et al. (U.S. Pub. No. 2018/0046804 A1) – Includes methods regarding device monitoring and debugging
Conclusion
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 /LYNN D FEILD/Supervisory Patent Examiner, Art Unit 2431