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 .
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “an acquisition module configured to acquire an application to be detected, and to perform reverse parsing on the application to obtain a parsed target file”, “a static analysis module configured to perform static analysis on the target file to obtain a dynamic loading path and a target privacy protocol of the application”, and “a determination module configured to determine, according to the first detection result and the second detection result, whether the application is an abnormal application causing leakage of the user privacy information” in claim 10.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 7-8, 15-19, 21 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 7 recites the limitation “all the information” in line 2 of Page 5 of Claims. There is insufficient antecedent basis for this limitation in the claim. Multiple types of information have been previously recited such as “user privacy information” in independent Claim 1 and “information loaded by the application” in Claim 6. For this reason, it is unclear as to what “all the information” is meant to refer to, therefore rendering the claim indefinite. It is recommended to clarify what the information is meant to refer to by the Examiner.
Claim 7 recites the limitation “the target node” in lines 5-6 of Page 5 of Claims. There is insufficient antecedent basis for this limitation in the claim. A target node is not recited previously before being first recited in Claim 7, therefore it is unclear as to what the target node is meant to refer to, and the claim is rendered indefinite. It is recommended to initially recite “a target node” by the Examiner.
Claims 8, 19, 21 are rejected by virtue of depending upon Claim 7.
Claim 15 recites the limitation "the static database" in line 3 of Claim 15. There is insufficient antecedent basis for this limitation in the claim. A static database is not recited previously before being first recited in Claim 15, therefore it is unclear as to what the static database is meant to refer to, and the claim is rendered indefinite. It is recommended to initially recite “a static database” by the Examiner.
Claim 16 is rejected by virtue of depending upon Claim 15.
Claim 17 recites the limitation “the instrumentation” in lines 3-4 of Claim 17. There is insufficient antecedent basis for this limitation in the claim. An instrumentation is not recited nor defined before being first recited in Claim 17, therefore it is unclear as to what the instrumentations are meant to refer to, and the claim is rendered indefinite. It is recommended to initially recite and clarify “an instrumentation” by the Examiner.
The term “basic” in line 4 of claim 21 is a relative term which renders the claim indefinite. The term “basic” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. For this reason, it is unclear as to what “other basic information” entails and the corresponding scope of the claim, therefore rendering the claim indefinite.
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, 4-6, 9-10, 12, 15-17, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zhou et al. (U.S. Pub. No. 2023/0267228 A1) hereinafter referred to as “Zhou”, and in view of Le et al. (U.S. Patent No. 8,286,250 B1) hereinafter referred to as “Le”, and in view of Ferrara et al. (U.S. Pub. No. 2018/0034857 A1) hereinafter referred to as “Ferrara”.
Regarding Claim 1:
Zhou teaches the following limitations:
A detection method for privacy information leakage, comprising: acquiring an application to be detected (Par. [0004], Par. [0005], Par. [0034]). Zhou teaches performing privacy analysis on android applications.
(taught by Le below)
performing static analysis on the target file to obtain a dynamic loading path [taint propagation path] and a target privacy protocol of the application [static analysis result], wherein the target privacy protocol at least comprises a first privacy protocol of the application [interface permission information] (Par. [0034], Par. [0039], Par. [0043], Par. [0066]). Zhou teaches performing static analysis which includes identifying the application’s interface privacy permissions, i.e. a first privacy protocol under the broadest reasonable interpretation.
and a second privacy protocol of a software development kit associated with the application [SDK permission information] (Par. [0034], Par. [0039], Par. [0046], Par. [0066]). Zhou includes software development kit (SDK) permission information for privacy determination.
and the dynamic loading path is a control flow path achieving dynamic loading (Par. [0035], Par. [0038]). Zhou teaches the propagation path being a flow path for information, i.e. dynamic loading under the broadest reasonable interpretation.
(taught by Ferrara below)
(taught by Ferrara below)
detecting, according to the dynamic loading path, the user privacy information used by the application in a dynamic loading process to generate a second detection result, wherein the second detection result indicates whether the application is an application illegally using the user privacy information when running (Par. [0034], Par. [0081], Par. [0084], Par. [0097]). Zhou teaches performing dynamic/flow analysis in conjunction with static analysis for behavior detection.
and determining, according to the first detection result and the second detection result, whether the application is an abnormal application causing leakage of the user privacy information [fused to obtain detection result] (Par. [0032], Par. [0034], Par. [0105]). Zhou teaches combining the results in a single report for privacy leakage determination.
Le teaches the following limitation:
and performing reverse parsing on the application to obtain a parsed target file (Col. 4, lines 60-67, Col. 5, lines 1-10). Le teaches extracting code from a package for sensitive information analysis.
Zhou does not teach parsing for the application. Le however teaches that in sensitive information analysis, an application may be in the form of a package and need to have its files extracted for analysis (Col. 4, lines 60-67, Col. 5, lines 1-10). For this reason, it would have been obvious to one of ordinary skill in the art to combine the privacy analysis system of Zhou with the file extraction of Le in order to gain the predictable result of parsing the application to obtain files for analysis. One of ordinary skill in the art would have recognized that the file extraction of Le is compatible with the application analysis of Zhou as they both are directed towards analysis of sensitive information within applications, and that such a file extraction would have been a predictable step for performing code analysis for packaged applications.
Ferrara teaches the following limitations:
generating a first detection result according to the target privacy protocol and a preset protocol [privacy policy], wherein the first detection result indicates whether the application is an application illegally using user privacy information when not running (Par. [0027], Par. [0028], Par. [0029]). Ferrara teaches using preset privacy policies in static analysis to determine whether privacy leakage has occurred. In conjunction with Zhou which teaches using static analysis which determines the privacy permission information of the application, this teaches the claimed limitation.
and the preset protocol is a protocol to determine whether the target privacy protocol meets preset specifications (Par. [0027], Par. [0028], Par. [0029]).
Zhou does not teach a preset privacy protocol. Ferrara however teaches a user setting a privacy policy to determine privacy information leakage and that this has the advantage of fine-grained privacy specification (Par. [0002], Par. [0014]). For this reason, it would have been obvious to one of ordinary skill in the art to combine the privacy analysis system of Zhou with the privacy policy of Ferrara in order to gain the benefit of fine-grained analysis in privacy leakage determination. One of ordinary skill in the art would have recognized that the privacy policy of Ferrara is compatible with the privacy analysis system of Zhou because both relate to static analysis systems, and that using such a privacy policy would have the benefit of user-defined policies for more specific control of personal information through determining fine-grained privacy violations.
Regarding Claim 4:
Ferrara teaches the following limitations:
wherein the generating a first detection result according to the target privacy protocol and a preset protocol comprises: determining that the application is an application illegally using the user privacy information when not running, under the condition that content of the target privacy protocol does not match content of the preset protocol [compare leaked data to privacy policies] (Par. [0027], Par. [0028], Par. [0029]). Ferrara teaches comparing the leaked information from performing static analysis to what is specified in the privacy policies for unauthorized leakage determination.
acquiring a first code in the target file when the content of the target privacy protocol matches the content of the preset protocol, wherein the first code indicates user privacy information to be actually acquired by the application (Par. [0023], Par. [0027], Par. [0028], Par. [0029]). Ferrara teaches tracking the leakage of confidential data in sources/sinks in the code of the application. This suggests receiving a first code under the broadest reasonable interpretation as these sources/sinks are in the form of code instructions such as API method calls.
and determining whether the application is an application illegally using the user privacy information when not running, according to the first code and the target privacy protocol (Par. [0023], Par. [0027], Par. [0028], Par. [0029]).
The reasons for motivation/combination of references remain the same as in Claim 1.
Regarding Claim 5:
Ferrara teaches the following limitations:
wherein the determining whether the application is an application illegally using the user privacy information when not running, according to the first code and the target privacy protocol comprises: parsing the first code [track privacy units] to obtain the user privacy information to be actually acquired by the application (Par. [0027], Par. [0028], Par. [0029]). Ferrara teaches performing static analysis to track confidential information, i.e. parsing the code under the broadest reasonable interpretation.
determining that the application is an application legally using the user privacy information when not running, under the condition that the user privacy information to be actually acquired by the application matches the content of the target privacy protocol (Par. [0027], Par. [0028], Par. [0029]). Ferrara teaches matching the policy to determine appropriate usage of privacy information.
and determining that the application is an application illegally using the user privacy information when not running, under the condition that the user privacy information to be actually acquired by the application does not match the content of the target privacy protocol (Par. [0027], Par. [0028], Par. [0029]).
The reasons for motivation/combination of references remain the same as in Claim 1.
Regarding Claim 6:
Zhou teaches the following limitations:
wherein the detecting, according to the dynamic loading path, the user privacy information used by the application in a dynamic loading process to generate a second detection result, comprises: inserting a second code [hook] for recording dynamic loading information in the application [monitor privacy] (Par. [0081], Par. [0082], Par. [0083]). Zhou teaches using hooking as part of dynamic analysis, i.e. code injection.
generating an input event [command line] for triggering a dynamic loading process of the application according to the dynamic loading path (Par. [0081], Par. [0095], Par. [0096], Par. [0097]). Zhou teaches using a command in the command line to trigger a part of the code.
triggering a dynamic loading process of the application by the input event, and acquiring, by the second code, all information loaded by the application in the dynamic loading process [monitor privacy information] (Par. [0081], Par. [0095], Par. [0096], Par. [0097]). Zhou teaches monitoring the interface functions to track the information obtained.
and using data flow analysis to track a transmission process of the user privacy information in all the information on the dynamic loading path, and generating the second detection result according to a tracking result (Par. [0097], Par. [0098], Par. [0099], Par. [0103]). Zhou also teaches performing flow analysis, and this is used to create a dynamic/flow analysis result.
Regarding Claim 9:
Zhou teaches the following limitations:
(taught by Ferrara below)
and the second detection result indicates that the application is an application legally using the user privacy information when running (Par. [0032], Par. [0034], Par. [0105]). Zhou teaches combining the static and dynamic analysis results for a detection result. This suggests normal operation when both analyses are normal in conjunction with Ferrara.
(taught by Ferrara below)
Ferrara teaches the following limitations:
wherein the determining, according to the first detection result and the second detection result, whether the application is an abnormal application causing leakage of the user privacy information comprises: determining that the application is a normal application not causing leakage of the user privacy information, under the conditions that the first detection result indicates that the application is an application legally using the user privacy information when not running (Par. [0027], Par. [0028], Par. [0029]). Ferrara teaches monitoring in static analysis that the privacy policy is obeyed.
and determining that the application is an abnormal application causing leakage of the user privacy information, under the conditions that the first detection result indicates that the application is an application illegally using the user privacy information when not running, or the second detection result indicates that the application is an application illegally using the user privacy information when running (Par. [0027], Par. [0028], Par. [0029]). Ferrara teaches reporting when the privacy policy is violated.
The reasons for motivation/combination of references remain the same as in Claim 1.
Regarding Claim 10:
Zhou teaches the following limitations:
A detection apparatus for privacy information leakage, comprising: an acquisition module configured to acquire an application to be detected (Par. [0004], Par. [0005], Par. [0034], Par. [0108]).
(taught by Le below)
a static analysis module configured to perform static analysis on the target file to obtain a dynamic loading path and a target privacy protocol of the application, wherein the target privacy protocol at least comprises a first privacy protocol of the application (Par. [0034], Par. [0039], Par. [0043], Par. [0066], Par. [0108]).
and a second privacy protocol of a software development kit associated with the application (Par. [0034], Par. [0039], Par. [0046], Par. [0066]).
and the dynamic loading path is a control flow path achieving dynamic loading (Par. [0035], Par. [0038]).
(taught by Ferrara below)
(taught by Ferrara below)
a second detection module configured to detect, according to the dynamic loading path, the user privacy information used by the application in a dynamic loading process to generate a second detection result, wherein the second detection result indicates whether the application is an application illegally using the user privacy information when running (Par. [0034], Par. [0081], Par. [0084], Par. [0097], Par. [0108]).
and a determination module configured to determine, according to the first detection result and the second detection result, whether the application is an abnormal application causing leakage of the user privacy information (Par. [0032], Par. [0034], Par. [0105], Par. [0108]).
Le teaches the following limitation:
and to perform reverse parsing on the application to obtain a parsed target file (Col. 4, lines 60-67, Col. 5, lines 1-10).
Zhou does not teach parsing for the application. Le however teaches that in sensitive information analysis, an application may be in the form of a package and need to have its files extracted for analysis (Col. 4, lines 60-67, Col. 5, lines 1-10). For this reason, it would have been obvious to one of ordinary skill in the art to combine the privacy analysis system of Zhou with the file extraction of Le in order to gain the predictable result of parsing the application to obtain files for analysis. One of ordinary skill in the art would have recognized that the file extraction of Le is compatible with the application analysis of Zhou as they both are directed towards analysis of sensitive information within applications, and that such a file extraction would have been a predictable step for performing code analysis for packaged applications.
Ferrara teaches the following limitation:
a first detection module configured to generate a first detection result according to the target privacy protocol and a preset protocol, wherein the first detection result indicates whether the application is an application illegally using user privacy information when not running (Par. [0027], Par. [0028], Par. [0029]).
and the preset protocol is a protocol to determine whether the target privacy protocol meets preset specifications (Par. [0027], Par. [0028], Par. [0029]).
Zhou does not teach a preset privacy protocol. Ferrara however teaches a user setting a privacy policy to determine privacy information leakage and that this has the advantage of fine-grained privacy specification (Par. [0002], Par. [0014]). For this reason, it would have been obvious to one of ordinary skill in the art to combine the privacy analysis system of Zhou with the privacy policy of Ferrara in order to gain the benefit of fine-grained analysis in privacy leakage determination. One of ordinary skill in the art would have recognized that the privacy policy of Ferrara is compatible with the privacy analysis system of Zhou because both relate to static analysis systems, and that using such a privacy policy would have the benefit of user-defined policies for more specific control of personal information through determining fine-grained privacy violations.
Regarding Claim 12:
Zhou teaches the following limitation:
An electronic device, comprising one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors are used for running a program, and the program is configured to execute the detection method for privacy information leakage of claim 1 when running (Par. [0017], Par. [0018]).
Regarding Claim 15:
Zhou teaches the following limitations:
wherein the performing static analysis on the target file to obtain a dynamic loading path comprises: extracting static information from the static database [mapping table], after performing static analysis on the application to be detected and storing an analysis result of the static analysis in a static database (Par. [0034], Par. [0039], Par. [0041], Par. [0048]). Zhou teaches obtaining permission-related information which is stored in mapping tables, i.e. a database.
determining the dynamic loading path of the application to be detected according to the static information, and generating path information (Par. [0034], Par. [0039], Par. [0053]). Zhou constructs a path from the obtained information.
Regarding Claim 16:
Zhou teaches the following limitation:
wherein method further comprises: generating an input event for triggering the dynamic loading process of the application according to the path information (Par. [0081], Par. [0095], Par. [0096], Par. [0097]).
Regarding Claim 17:
Zhou teaches the following limitation:
wherein the inserting a second code for recording dynamic loading information in the application comprises: determining positions of the application required to be subjected to the instrumentation, according to a node of dynamic loading determined by a generation process of path information; performing instrumentation on the positions, wherein the instrumentation is to insert the second code for recording dynamic loading information into the application (Par. [0081], Par. [0082], Par. [0083]). This limitation is directed towards determining code positions for code insertion, i.e. hooking. Under the broadest reasonable interpretation however, as Zhou teaches hooking the code for dynamic analysis, this suggests a determination of positions to insert code as a part of hooking.
Regarding Claim 20:
Ferrara teaches the following limitation:
wherein the first code is a code for indicating a relevant function for acquiring the user privacy information and a code for indicating relevant permission information for acquiring the user privacy information (Par. [0023], Par. [0027], Par. [0028], Par. [0029]). The first code as taught by Ferrara was directed towards obtaining user privacy information which were subject to privacy policies, i.e. indicate under the broadest reasonable interpretation.
The reasons for motivation/combination of references remain the same as in Claim 1.
Claims 2-3, 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zhou/Le/Ferrara and further in view of Wildsmith et al. (U.S. Pub. No. 2023/0140432 A1) hereinafter referred to as “Wildsmith”.
Regarding Claim 2:
Zhou teaches the following limitation:
(taught by Wildsmith below)
and determining the dynamic loading path and the target privacy protocol of the application according to the original code (Par. [0034], Par. [0039], Par. [0043], Par. [0066]).
Wildsmith teaches the following limitation:
wherein the performing static analysis on the target file to obtain a dynamic loading path and a target privacy protocol of the application comprises: detecting whether a code in the target file is subjected to packing [obfuscated code], wherein the packing comprises at least one of the following processing methods: encrypting the code, hiding the code and obfuscating the code; performing unpacking on the code to obtain an original code not subjected to the packing when the code is subjected to the packing [deobfuscated code], wherein the unpacking is reverse processing of the packing (Par. [0055], Par. [0056], Par. [0057]). Wildsmith teaches de-obfuscating code which has been obfuscated for determining malicious behavior.
Zhou/Le/Ferrara do not teach deobfuscating code. Wildsmith however teaches that malicious code can be obfuscated to evade detection in static analysis, and such code deobfuscation overcomes this issue (Par. [0003], Par. [0022]). For this reason, it would have been obvious to one of ordinary skill in the art to combine the privacy analysis system of Zhou/Le/Ferrara with the code unpacking of Wildsmith in order to gain the benefit of additional detection of malicious code behavior. One of ordinary skill in the art would have recognized that the code unpacking of Wildsmith is compatible with the system of Zhou/Le/Ferrara as they both relate to code analysis, and that such code unpacking would have the benefit of preventing malicious behavior in obfuscated code from being avoided in detection.
Regarding Claim 3:
Zhou teaches the following limitations:
wherein the determining the target privacy protocol of the application according to the original code comprises: extracting the first privacy protocol of the application (Par. [0039], Par. [0040], Par. [0043]). Zhou teaches extracting the interface permission-related information by creating a mapping table.
and mark information of the software development kit according to the original code (Par. [0046]). Zhou teaches obtaining a name of the SDK, i.e. mark information under the broadest reasonable interpretation.
acquiring the second privacy protocol of the software development kit according to the mark information (Par. [0046], Par. [0047], Par. [0048], Par. [0049]). Zhou creates a permission-related information mapping table for the SDK.
and using semantic analysis to analyze the first privacy protocol and the second privacy protocol [status privacy context], and integrating analysis results to obtain the target privacy protocol (Par. [0053], Par. [0064], Par. [0066], Par. [0067]). Zhou teaches using status privacy context information from combining the two protocols to determine different privacy types for permissions, i.e. semantic analysis under the broadest reasonable interpretation.
Regarding Claim 13:
Zhou teaches the following limitations:
wherein the method further comprises: performing static analysis on the code in the target file, when the code in the target file corresponding to an android application is not subjected to the packing (Par. [0034], Par. [0039], Par. [0043], Par. [0066]). Zhou/Le/Ferrara was combined with Wildsmith in such a manner that Wildsmith unpacked code to obtain the original code for static analysis. Therefore, unpacked code and code that was not packed in the first place were subject to static analysis.
Claims 7-8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zhou/Le/Ferrara and further in view of Sun et al. (U.S. Patent No. 11,354,433 B1) hereinafter referred to as “Sun”.
Regarding Claim 7:
Zhou teaches the following limitations:
wherein the using data flow analysis to track a transmission process of the user privacy information in all the information on the dynamic loading path comprises: performing the data flow analysis from an entry point of the dynamic loading path, and identifying the user privacy information from all the information (Par. [0097], Par. [0098], Par. [0099], Par. [0103]). Zhou teaches performing flow analysis for privacy information.
(taught by Sun below)
Sun teaches the following limitations:
marking the identified user privacy information to obtain mark data (Fig. 2, Col. 4, lines 22-37). Sun teaches tainting data for dynamic taint analysis.
performing taint propagation on the mark data (Col. 3, lines 22-52).
acquiring target dynamic loading information recorded by the second code at the target node, when it is detected that the application performs dynamic loading call at a target node on the dynamic loading path (Col. 3, lines 40-52, Col. 8, lines 15-64, Col. 9, lines 3-30). Sun teaches the taint information being propagated through a taint source, i.e. target dynamic loading information under the broadest reasonable interpretation as this is data formed from the inserted code for dynamic analysis.
and tracking the mark data between the dynamic loading path and an external code according to the target dynamic loading information to obtain the tracking result (Col. 3, lines 40-52, Col. 8, lines 31-64, Col. 9, lines 3-30). Sun teaches the taint information tracking for leaked information.
Zhou/Le/Ferrara do not teach dynamic taint analysis. Sun however teaches that dynamic taint analysis can be performed for privacy leakage detection and has the benefit of detecting exactly when sensitive data is leaked (Col. 3, lines 40-52). For this reason, it would have been obvious to one of ordinary skill in the art to combine the privacy analysis system of Zhou/Le/Ferrara with the dynamic taint tracking of Sun in order to gain the benefit of additional detection in privacy information leakage. One of ordinary skill in the art would have recognized that the dynamic taint analysis of Sun is compatible with the system of Zhou/Le/Ferrara as they both relate to code analysis, and that such dynamic taint analysis would have the benefit of accurately tracking when privacy information leakage occurs to external devices.
Regarding Claim 8:
Sun teaches the following limitations:
wherein generating the second detection result according to a tracking result comprises: determining that the application is an application legally using the user privacy information when running, under the condition that a transmission process matches the target privacy protocol, wherein the transmission process is a process of the mark data between the dynamic loading path and the external code (Col. 2, lines 53-67, Col. 9, lines 18-30). Sun teaches the determination being dependent upon a privacy policy being violated or not, i.e. privacy protocol.
and determining that the application is an application illegally using the user privacy information when running, under the condition that the transmission process of the mark data between the dynamic loading path and the external code does not match the target privacy protocol [violate privacy policy] (Col. 2, lines 53-67, Col. 9, lines 18-30).
The reasons for motivation/combination of references remain the same as in Claim 7.
Allowable Subject Matter
Claim 14 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
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:
Jones et al. (U.S. Pub. No. 2021/0279363 A1) – Includes methods regarding privacy analysis for SDKs
Hu et al. (U.S. Pub. No. 2020/0110878 A1) – Includes methods regarding static/dynamic analysis
McCorkendale et al. (U.S. Patent No. 8,726,392 B1) – Includes methods regarding static/dynamic analysis
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 /MICHAEL R VAUGHAN/Primary Examiner, Art Unit 2431