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 .
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 (i.e., changing from AIA to pre-AIA ) 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.
FINAL ACTION
This is action is in response to applicant’s claim amendment(s) submitted on 06/16/2026. Claims 1, 6-8, 13-15, 20 and 21 are amended. Claims 1-21 are pending.
Response to Arguments
Examiner’s Remarks - Specification (Title)
The examiner withdraws the objection in view of applicant’s title amendment.
Examiner’s Remarks -Claim Rejections - 35 USC § 112
The examiner withdraws the rejection in view of applicant’s claim amendment(s).
Examiner’s Remarks - Claim Interpretation
The examiner maintains the claim interpretation noted in office action dated 03/18/2026.
Examiner’s Remarks -Claim Rejections - 35 USC § 103 – Independent claims 1, 8 and 15
The examiner notes that the applicant has amended each independent claim to recite the following: “running the application with the variations of the inputs to generate updated application behavior information that is based on the variations of the inputs; generating a second application security profile based on the updated application behavior information that is based on the variations of the inputs; and in response to determining that the application does not contain any malicious code based on the first application security profile and the second application security profile”. The examiner notes that the applicant now alleges a deficiency on the part of the cited prior art in view of the claim amendment(s). In view of the claim amendments, the examiner introduces the teachings of prior art reference Vorsanger (US Patent Publication No. 2017/0024583) to the record. The examiner notes that Vorsanger discloses a process for varying the input to a application, collecting the output data based on the variations in inputs and then comparing the outputs. See rejection below.
Examiner’s Remarks -Claim Rejections - 35 USC § 103 – Dependent claims 2, 9 and 16
The examiner finds applicant’s remarks persuasive in this instance and therefore withdraws the rejection.
Examiner’s Remarks -Claim Rejections - 35 USC § 103 – Dependent claims 3, 5, 6, 7, 10, 12, 13, 14, 17, 19, 20 and 21
Applicant's arguments do not comply with 37 CFR 1.111(c) because they do not clearly point out the patentable novelty which he or she thinks the claims present in view of the state of the art disclosed by the references cited or the objections made. Further, they do not show how the amendments avoid such references.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 5, 8, 12, 15 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Salajegheh et al. (US Patent Publication No. 2017/0206350 and Salajegheh hereinafter) in view of Daswani et al. (US Patent No. 9,894,096 and Daswani hereinafter) and further in view of Vorsanger (US Patent Publication No. 2017/0024583).
As to claims 1, 8 and 15, Salajegheh teaches a method comprising:
obtaining application behavior information indicating runtime behavior of an application submitted for sharing in a data exchange (i.e., …teaches in par. 0050 the following: The processor 110 may perform the first analysis at runtime in a manner similar to that described with reference to the offline 210 first analysis 214 execution. A result of the first analysis 214 executed at runtime, may be a new risk summary 218, which may be stored in memory 125 and any applicable directory or reference data structure updated accordingly);
generating, based on the application behavior information, a first application security profile (i.e., …teaches in par. 0050 the following: …A result of the first analysis 214 executed at runtime, may be a new risk summary 218, which may be stored in memory 125 and any applicable directory or reference data structure updated accordingly),
the first application security profile comprising inputs to the application (i.e., … teaches in par. 0051 the following: “Thus, the processor 110 may continuously reconfigure the portions of an application being reviewed …);
generating, by a processing device, variations of the inputs to the application (i.e., …teaches in par. 0047 the following: “… As the software application 202 progresses through an execution session, user input (e.g., keyboard, microphone, touchscreen interactions) may result in changes in the execution path.” …teaches in par. 0047 the following: “A path assessment 224 module of the second analysis 222 may cause the processor 110 to track the current execution path of the software application 202. As the software application 202 progresses through an execution session, user input (e.g., keyboard, microphone, touchscreen interactions) may result in changes in the execution path. The processor 110 may monitor this progress and may maintain in a memory, a temporary pointer to a current path segment as well as the current execution path (i.e., total path taken). Substantially concurrently, the processor 110 may compare the current execution path (i.e., the currently executing path segment) to the available risk summaries stored in memory 125. If the processor 110 retrieves a set of stored risk summaries 218, or finds an entry for associated risk summaries 218 in a stored directory, the processor 110 may consider the current execution path to be an existing path 225b.” …teaches in par. 0051 the following: “Thus, the processor 110 may continuously reconfigure the portions of an application being reviewed and analyzed across execution sessions. Such incremental modification of the risk summaries 218 and the resulting second analysis 222 execution, may make the information flow tracking scheme 200 versatile and relatively low in resource consumption.”.).
Salajegheh does not expressly teach:
scanning the second application security profile to determine if the application contains any malicious code,
approving the application for listing on the data exchange.
In this instance the examiner notes the teachings of prior art reference Daswani.
With regards to applicant’s claim limitation element of, “scanning the second application security profile to determine if the application contains any malicious code”, Daswani teaches in col. 3 lines 1-10 the following: “During scanning, various user interactions are simulated to activate many possible behaviors of an application when it is running on a computing device. Scanning may be performed for different amounts of time both to allow a greater amount of simulated user interactions and to activate behaviors that may occur only after the mobile device running the application has been asleep, the screen has been dimmed, or any other temporally affected behavior has occurred.”. Daswani teaches in col. 4 lines 55-67 the following: “The application is run in an emulated software platform, and a wide range of input permutations are performed in order to monitor the resulting behavior of the application. An emulator can be built from a stock mobile device emulator, and modified to form a mobile sandbox. The sandbox provides an emulated environment corresponding to a device and is suitable for testing an app without installing on the particular device. The sandbox includes hooks for key application programming interfaces (APIs) that a mobile application might communicate through, e.g., calls sent or received.”. Teaches in col. 6 lines 45-60 the following: “STRACE is utilized to monitor system calls made by the application. This enables all system calls, actions, and other behaviors of the application to be stored during behavioral analysis.”. Teaches in col. 6 lines 60-67 the following: “Signal combination module 306 combines multiple behaviors signals to determine an overall likelihood that an application is malicious”.
With regards to applicant’s claim limitation element of, “approving the application for listing on the data exchange”, Daswani teaches as part of his claim 1 element(s) the following: “and determining, based on the classification, whether to approve or reject the mobile application for distribution in the mobile application marketplace.”.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the of the claimed invention was made to implement the teachings of Salajegheh with the teachings of Daswani by having their system comprise an enhanced application security analysis process. One would have been motivated to do so to provide a simple and effective means to secure network resources, wherein the enhanced application security analysis process helps facilitate data integrity within the network and makes it easier to analyze applications for malicious behavior.
The system of Salajegheh and Daswani do not expressly teach:
running the application with the variations of the inputs to generate updated application behavior information that is based on the variations of the inputs;
generating a second application security profile based on the updated application behavior information that is based on the variations of the inputs;
and in response to determining that the application does not contain any malicious code based on the first application security profile and the second application security profile.
In this instance the examiner notes the teachings of prior art reference Vorsanger.
With regards to applicant’s claim limitation element of, “running the application with the variations of the inputs to generate updated application behavior information that is based on the variations of the inputs”, Vorsanger illustrates in figure 2 of their original drawings a process for comparing outputs of an application with variable inputs.
PNG
media_image1.png
691
1011
media_image1.png
Greyscale
With regards to applicant’s claim limitation element of, “generating a second application security profile based on the updated application behavior information that is based on the variations of the inputs”, Vorsanger illustrates in figure 2, figure element 230 a comparison module for comparing updated activity (i.e., second application security profile) based on the variable inputs to the application.
With regards to applicant’s claim limitation element of, “and in response to determining that the application does not contain any malicious code based on the first application security profile and the second application security profile,”, Vorsanger illustrates in figure 2, figure element 230 a comparison module for comparing a first and second activity data (i.e., first application security profile and the second application security profile) based on the variable inputs the application. Further teaches in par. 0036 the following: “The existence of any such data (if any is identified) may then be used to make determinations about whether or when to run the application, or whether to uninstall or otherwise disable the application”. The examiner notes that if there is anomalous activity than the application will be disabled. The examiner notes that if there is no anomalous activity than the application will be okay.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the of the claimed invention was made to implement the teachings of Salajegheh and Daswani with the teachings of Vorsanger by having their system comprise an enhanced data comparison process. One would have been motivated to do so to provide a simple and effective means to detect anomalies, wherein the enhanced data comparison process helps facilitate security and makes it easier to analyze data for anomalies.
As to claims 5, 12 and 19, the system of Salajegheh, Daswani and Vorsanger as applied to claim 1 above teaches access control, specifically Salajegheh does not expressly teaches a method of claim 1, further comprising: testing the application in a provider account to generate the application behavior information.
In this instance the examiner notes the teachings of prior art reference Daswani.
Daswani teaches in col. 4 lines 1-10 the following: “the behavioral analysis server 108 receives an application from the application server 104 prior to the application server 104 making the application available to the mobile device 106. … Various input permutations are tested to analyze the resulting behavior of the application. The resulting behavior may include signals indicating the application is likely to contain malware. In one embodiment, soft signal and hard signal classifications are assigned to behaviors to indicate a likelihood that a certain behavior is due to malware on the application being tested.”.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the of the claimed invention was made to implement the teachings of Salajegheh with the teachings of Daswani by having their system comprise an enhanced application security analysis process. One would have been motivated to do so to provide a simple and effective means to secure network resources, wherein the enhanced application security analysis process helps facilitate data integrity within the network and makes it easier to analyze applications for malicious behavior.
Claim(s) 3, 6, 7, 10, 13, 14, 17, 20 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Salajegheh and Daswani in view of Vorsanger as applied to claims 1, 8 and 15 above and further in view of Grund et al. (US Patent No. 2024/0256531 and Grund hereinafter).
As to claims 3, 10 and 17, the system of Salajegheh, Daswani and Vorsanger as applied to claim 1 above teaches access control, specifically Salajegheh does not expressly teaches a method of claim 1, wherein the application behavior information comprises:
egress hosts and ports the application connects to;
ingress endpoints of the application, paths and payloads of requests to the ingress endpoints of the application,
and paths and payloads of responses from the ingress endpoints of the application,
permissions required by the application,
and packet filter monitoring logs.
In this instance the examiner notes the teachings of prior art reference Daswani.
With regards to applicant’s claim limitation element(s) of, “egress hosts and ports the application connects to”, Daswani teaches in col. 7 lines 10-20 the following: “For example, iteratively retrieving every address from an address book may be assigned a higher probability of maliciousness. On the other hand, contacting an internet protocol (IP) address associated with a known malicious botmaster may be classified as a hard signal due to the small probability of benign software performing such an action.”.
With regards to applicant’s claim limitation element(s) of, “ingress endpoints of the application, paths and payloads of requests to the ingress endpoints of the application”, Daswani teaches in col. 4 lines 60-67 & col. 5 lines 1-10 the following: “The application is run in an emulated software platform, and a wide range of input permutations are performed in order to monitor the resulting behavior of the application. An emulator can be built from a stock mobile device emulator, and modified to form a mobile sandbox. The sandbox provides an emulated environment corresponding to a device and is suitable for testing an app without installing on the particular device. The sandbox includes hooks for key application programming interfaces (APIs) that a mobile application might communicate through, e.g., calls sent or received. Examples of APIs include those that are used to access a file system, access contacts in an address book, interface with an SMS text subsystem, a interface with a wireless fidelity (WiFi) system, interface with a telephony system, or enable or disable a camera. In one embodiment, the sandbox is also configured to observe an application's network behavior, graphical user interface and other aspects for black-box monitoring, in addition to white-box monitoring of API calls.”.
With regards to applicant’s claim limitation element(s) of, “and paths and payloads of responses from the ingress endpoints of the application”, Daswani teaches in col. 4 lines 60-67 & col. 5 lines 1-10 the following: “The application is run in an emulated software platform, and a wide range of input permutations are performed in order to monitor the resulting behavior of the application. An emulator can be built from a stock mobile device emulator, and modified to form a mobile sandbox. The sandbox provides an emulated environment corresponding to a device and is suitable for testing an app without installing on the particular device. The sandbox includes hooks for key application programming interfaces (APIs) that a mobile application might communicate through, e.g., calls sent or received. Examples of APIs include those that are used to access a file system, access contacts in an address book, interface with an SMS text subsystem, a interface with a wireless fidelity (WiFi) system, interface with a telephony system, or enable or disable a camera. In one embodiment, the sandbox is also configured to observe an application's network behavior, graphical user interface and other aspects for black-box monitoring, in addition to white-box monitoring of API calls.”.
With regards to applicant’s claim limitation element of, “permissions required by the application”, teaches in col. 7 lines 1-10 the following: “some system calls or actions simulated in the emulated environment may be classified as soft signals or hard signals. In one embodiment, soft signals comprise system calls or actions which have an associated probability of the application containing malware. Hard signals comprise system calls or actions that are by definition malicious actions, or associated with a probability of the application containing malware, the probability exceeding a hard signal threshold. For example, a soft signal may be accessing an address book on the mobile device. This action may be used for malicious purposes, but is often benign. In one embodiment, a soft signal has a higher probability of maliciousness if similar applications are unlikely to perform a similar action. A soft signal of accessing address book information may also be assigned an increased probability of maliciousness based on the amount of address book entries accessed or the pattern in which entries are accessed. For example, iteratively retrieving every address from an address book may be assigned a higher probability of maliciousness. On the other hand, contacting an internet protocol (IP) address associated with a known malicious botmaster may be classified as a hard signal due to the small probability of benign software performing such an action.”.
With regards to applicant’s claim limitation element(s) of, “and packet filter monitoring logs”, Daswani teaches in col. 5 lines 1-10 the following: In one embodiment, the sandbox is also configured to observe an application's network behavior...”.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the of the claimed invention was made to implement the teachings of Salajegheh with the teachings of Daswani by having their system comprise an enhanced application security analysis process. One would have been motivated to do so to provide a simple and effective means to secure network resources, wherein the enhanced application security analysis process helps facilitate data integrity within the network and makes it easier to analyze applications for malicious behavior.
The system of Salajegheh, Daswani and Vorsanger does not expressly teach:
a list of user defined functions (UDFs) and stored procedures included in the application and queries run by the application.
With regards to applicant’s claim limitation element of, “a list of user defined functions (UDFs) and stored procedures included in the application”, teaches in par. 0042 the following: “parses the command to extract various attributes associated with a UDF, for example, the UDF name, input parameters, return type, UDF code, and so on”. Teaches in par. 0055 the following: “determines 720 the UDF code specified by the database command … The client application 510 uses the stored hash value H1 for comparing with a hash value generated by the data processing service 102 during execution of a database query that invokes the UDF code to determine whether the UDF code specified during creation of the UDF matches the UDF code being executed during execution of database queries.”. Teaches in par. 0057 the following: “the UDF code may be identified using markers”. Teaches in par. 0063 the following: “provides the identities of the UDFs being invoked”.
With regards to applicant’s claim limitation element of, “queries run by the application”, Grund teaches in par. 15 the following: “invoke UDFs using a client application that sends requests (e.g., queries) to the database system”.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the of the claimed invention was made to implement the teachings of Salajegheh, Daswani and Vorsanger with the teachings of Grund by having their system comprise an enhanced application function analysis process. One would have been motivated to do so to provide a simple and effective means to better detect the tampering of an application function, wherein the enhanced application function analysis process helps facilitate security within the network and makes it easier to analyze the behavior of an application.
As to claims 6, 13 and 20, the system of Salajegheh, Daswani and Vorsanger as applied to claim 1 above teaches access control, specifically Salajegheh does not expressly teach a method of claim 1, wherein the inputs to the application comprise:
and paths and payloads of requests to ingress endpoints of the application.
In this instance the examiner notes the teachings of prior art reference Daswani.
Daswani teaches in col. 4 lines 60-67 & col. 5 lines 1-10 the following: “The application is run in an emulated software platform, and a wide range of input permutations are performed in order to monitor the resulting behavior of the application. An emulator can be built from a stock mobile device emulator, and modified to form a mobile sandbox. The sandbox provides an emulated environment corresponding to a device and is suitable for testing an app without installing on the particular device. The sandbox includes hooks for key application programming interfaces (APIs) that a mobile application might communicate through, e.g., calls sent or received. Examples of APIs include those that are used to access a file system, access contacts in an address book, interface with an SMS text subsystem, a interface with a wireless fidelity (WiFi) system, interface with a telephony system, or enable or disable a camera. In one embodiment, the sandbox is also configured to observe an application's network behavior, graphical user interface and other aspects for black-box monitoring, in addition to white-box monitoring of API calls.”.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the of the claimed invention was made to implement the teachings of Salajegheh with the teachings of Daswani by having their system comprise an enhanced application security analysis process. One would have been motivated to do so to provide a simple and effective means to secure network resources, wherein the enhanced application security analysis process helps facilitate data integrity within the network and makes it easier to analyze applications for malicious behavior.
The system of Salajegheh, Daswani and Vorsanger do not expressly teach:
queries executed by user defined functions (UDFs) and stored procedures of the application in the application behavior information.
In this instance the examiner notes the teachings of prior art reference Grund.
Grund teaches in par. 15 the following: “invoke UDFs using a client application that sends requests (e.g., queries) to the database system”. Teaches in par. 0067 the following: “executes 940 a call back function as part of execution”.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the of the claimed invention was made to implement the teachings of Salajegheh, Daswani and Vorsanger with the teachings of Grund by having their system comprise an enhanced application function analysis process. One would have been motivated to do so to provide a simple and effective means to better detect the tampering of an application function, wherein the enhanced application function analysis process helps facilitate security within the network and makes it easier to analyze the behavior of an application.
As to claims 7, 14 and 21, the system of Salajegheh, Daswani and Vorsanger as applied to claim 6 above teaches access control, specifically Salajegheh does not expressly teach a method of claim 6, wherein generating the variations of the inputs to the application comprises:
and generating variations of the payloads of requests to the ingress endpoints of the application.
In this instance the examiner notes the teachings of prior art reference Daswani.
Daswani teaches in col. 4 lines 60-67 & col. 5 lines 1-10 the following: “The application is run in an emulated software platform, and a wide range of input permutations are performed in order to monitor the resulting behavior of the application. An emulator can be built from a stock mobile device emulator, and modified to form a mobile sandbox. The sandbox provides an emulated environment corresponding to a device and is suitable for testing an app without installing on the particular device. The sandbox includes hooks for key application programming interfaces (APIs) that a mobile application might communicate through, e.g., calls sent or received. Examples of APIs include those that are used to access a file system, access contacts in an address book, interface with an SMS text subsystem, a interface with a wireless fidelity (WiFi) system, interface with a telephony system, or enable or disable a camera. In one embodiment, the sandbox is also configured to observe an application's network behavior, graphical user interface and other aspects for black-box monitoring, in addition to white-box monitoring of API calls.”.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the of the claimed invention was made to implement the teachings of Salajegheh with the teachings of Daswani by having their system comprise an enhanced application security analysis process. One would have been motivated to do so to provide a simple and effective means to secure network resources, wherein the enhanced application security analysis process helps facilitate data integrity within the network and makes it easier to analyze applications for malicious behavior.
The system of Salajegheh, Daswani and Vorsanger do not expressly teach:
generating variations of the queries executed by each UDF and the stored procedures of the application.
In this instance the examiner notes the teachings of prior art reference Grund.
Grund teaches in par. 17 the following: “multiple versions of the UDF code, the data processing service allows users to confirm that the right version of UDF code is being used when executing database queries.”. Teaches in par. 0067 the following: “executes 940 a call back function as part of execution”.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the of the claimed invention was made to implement the teachings of Salajegheh, Daswani and Vorsanger with the teachings of Grund by having their system comprise an enhanced application function analysis process. One would have been motivated to do so to provide a simple and effective means to better detect the tampering of an application function, wherein the enhanced application function analysis process helps facilitate security within the network and makes it easier to analyze the behavior of an application.
Allowable Subject Matter
Claims 2, 9 and 16 are 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.
The following is a statement of reasons for the indication of allowable subject matter:
“obtaining live application behavior information from an instance of the application that is installed in a consumer account of the data exchange; generating, based on the live application behavior information, a third application security profile; comparing the third application security profile to the second application security profile to determine if there have been changes in the application that require reprofiling the application; and in response to determining that there have been changes in the application that require reprofiling the application, performing one or more mitigation actions”.
Claims 4, 11 and 18 are 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.
The following is a statement of reasons for the indication of allowable subject matter:
“receiving a request for a new version of the application to be submitted for sharing in the data exchange, wherein the request references the first application security profile; obtaining a list of UDFs and stored procedures included in the new version of the application; comparing the list of UDFs and stored procedures included in the new version of the application to a list of UDFs and stored procedures included in the second application security profile; and determining if the new version of the application may be submitted for sharing in the data exchange with the first application security profile based on the comparing”.
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.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRYAN F WRIGHT whose telephone number is (571)270-3826.
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, Eleni Shiferaw can be reached on (571)272-3867. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/BRYAN F WRIGHT/ Examiner, Art Unit 2497
Prosecution Insights