DETAILED ACTION
Examiner acknowledges receipt of Applicant’s amendment filed on 10/06/2025
Claims 1, 3-7, and 15-16 are currently amended
Claims 1-7 and 15-16 are pending
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 .
Response to Amendment
Examiner has fully considered Applicant’s amendments to the Claims in the arguments filed on 10/06/2025. Claims 1-7 and 15-16 remain pending in the application. Examiner has withdrawn the 101 rejections, 112(b) rejections, and objections to the Claims based on the amendments. However, additional claim objections arise.
Response to Arguments
Applicant’s arguments filed 10/06/2025, with respect to the rejections of independent claims 1, 15, and 16 and their corresponding dependent claims under 35 USC 103 have been fully considered and are persuasive. Therefore, the rejections have been withdrawn. However, upon further consideration, new ground(s) of rejection are made in view of the previously applied references from Bodorin and Abbasi, in addition to a newly applied reference from Bai et al. (Bai, J., Wang, W., Qin, Y., Zhang, S., Wang, J., & Pan, Y. (2018). Bridgetaint: A bi-directional dynamic taint tracking method for JavaScript bridges in Android Hybrid Applications. IEEE Transactions on Information Forensics and Security, 14(3), 677–692. https://doi.org/10.1109/tifs.2018.2855650), hereinafter Bai. Specifically, Bai teaches the newly added limitations “wherein the triggering invokes a service interface for the applet to send an invoking request to a JavaScript Bridge according to an agreed protocol, wherein the JavaScript Bridge is cut, so that the applet first routes execution logic to a security aspect module when sending the invoking request to the JavaScript Bridge, wherein the security aspect module receives and forwards the invoking request to the JavaScript Bridge for the JavaScript Bridge to send an invoking request response to the security aspect module, and wherein the security aspect module forwards the invoking request response to the applet and obtains the behavior record generated when the applet invokes the service interface”.
Claim Objections
Claim 1, 15, and 16 are objected to because of the following informalities:
Each of claims 1, 15, and 16 include the newly added limitation “wherein the triggering invokes a service interface”. It is unclear how the triggering is intended to invoke the service interface, when it appears that the applet is the entity which invokes the service interface. Further, in Applicant Arguments, the amendment is originally described as including “when invoking a service interface, the applet sends an invoking request…”. Examiner acknowledges this change was made in response to the discussion held in the interview on 09/23/2025. The limitation could be re-written to further clarify that the triggering occurs during/based on running of the applet, and that the running of the applet includes invoking the service interface, etc., such as: “obtaining at least two behavior records that are generated through triggering during running of the applet; wherein the running of the applet comprises the applet invoking a service interface by sending an invoking request to a JavaScript Bridge …”, or the like.
Each of claims 1, 15, and 16 include the newly added limitation “wherein the JavaScript Bridge is cut, so that the applet first routes execution logic to a security aspect module when sending the invoking request to the JavaScript Bridge”. The particular phrase “the JavaScript Bridge is cut” is unclear because the term “cut” is not commonly understood in the art in this context. However, the following limitation, “so that the applet first routes execution logic to a security aspect module when sending the invoking request to the JavaScript Bridge” indicates an interception or hooking of the invoking request/logic thereof. Therefore, the limitation could be re-written as: “send an invoking request to a JavaScript Bridge according to an agreed protocol, wherein the applet first routes execution logic to a security aspect module when sending the invoking request to the JavaScript Bridge, wherein the security aspect module receives and forwards the invoking request to the JavaScript Bridge” for clarity.
Appropriate correction is required.
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-3, 6, 15, and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bodorin et al. (US 20050188272 A1), hereinafter Bodorin, in view of Abbasi et al. (US 20170083703 A1), hereinafter Abbasi, and Bai et al. (Bai, J., Wang, W., Qin, Y., Zhang, S., Wang, J., & Pan, Y. (2018). Bridgetaint: A bi-directional dynamic taint tracking method for JavaScript bridges in Android Hybrid Applications. IEEE Transactions on Information Forensics and Security, 14(3), 677–692. https://doi.org/10.1109/tifs.2018.2855650), hereinafter Bai.
Regarding Claim 1:
Bodorin teaches a method for detecting a malicious behavior of an applet, comprising (Bodorin – Paragraph [0001]: The present invention relates to a system and a method for proactively securing a computer against malware, and more particularly, a system and method for detecting malware in an executable code module according to the code module's exhibited behavior; and Paragraph [0022]: For example, the code module 212 may be a Microsoft Windows executable, a Microsoft .NET executable, a Java applet/application, and the like): obtaining at least two behavior records that are generated through triggering during running of the applet (Bodorin – Paragraph [0024]: As the code module 212 executes within the dynamic behavior evaluation module 204, the dynamic behavior evaluation module records "interesting" behaviors exhibited by the code module. Interesting behaviors are those which a user or implementer of the malware detection system 200 has identified as interesting, potentially associated with malware, and are used to compare the behaviors of the code module 212 against known malware behaviors. Table A includes an exemplary, representative list of "interesting" behaviors, including parameters that are also considered interesting, that are recorded by a dynamic behavior evaluation module 204; and Table A: list of “interesting” behaviors recorded while code module 212 is running); extracting a behavior feature of each behavior record (Bodorin – Paragraph [0038]: As illustrated in both behavior signature 500 and behavior signature 512, each behavior includes three elements: a behavior token, such as behavior token 502; a first parameter value, such as parameter value 504; and a second parameter value, such as parameter value 506); forming at least one feature combination by using at least two behavior features of at least two [successively] generated behavior records, wherein each feature combination comprises at least two behavior features (Bodorin – Figures 5A and 5B: Illustrations of behavior signatures which include behavior feature of multiple behavior records); determining whether there is a feature combination that comprises a predetermined feature combination of a malicious behavior record; and if there is a feature combination that comprises the predetermined feature combination of a malicious behavior record, determining that the applet conducts a malicious behavior (Bodorin – Paragraph [0026]: Once the behavior signature 210 has been generated, the behavior signature comparison module 206 takes the behavior signature and compares it against behavior signatures of known malware that are stored in the malware behavior signature store 208. The malware behavior signature store 208 is a repository of behavior signatures of known malware. However, unlike signature files of anti-virus software 204, behavior signatures stored in the malware behavior signature store 208 are based on exhibited behaviors of malware. As such, even though all variable names and routine names within source code for malware are modified by a malicious party, the exhibited behaviors of the malware remain the same, and will be detected by the malware detection system 200 when the behavior signature comparison module 206 matches a code module's behavior signature 210 to a known malware's behavior signature in the malware behavior signature store 208).
Bodorin does not expressly teach successively generated behavior records; and a sequence of the at least two behavior features in the feature combination is the same as a time sequence of generating behavior records corresponding to the at least two behavior features.
However, Abbasi teaches successively generated behavior records (Abbasi – Paragraph [0052]: According to one embodiment of the disclosure, temporal identification logic 257 may be located within the monitoring logic 250, where the temporal identification (temp_id) logic 257 assigns an identifier to the detected malicious behavior and/or the salient information associated with the detected malicious behavior, where the identifier may be used in the chronological sequencing (or ordering) of behaviors received by the monitoring logic 250. Examples of various types of identifiers may include a time-stamp that is based on a current time as measured by a real-time clock (RTC) 258 communicatively coupled via interconnect 259 to the file system monitoring logic 252, the process monitoring logic 253, the registry monitoring logic 254 and/or the network access monitoring logic 255. Alternatively, the identifier may include a sequence number as generated by a monotonic counter for example. Connectivity to a common time source (or a counting source such as a monotonic counter) ensures that the chronological ordering of the behaviors); and a sequence of the at least two behavior features in the feature combination is the same as a time sequence of generating behavior records corresponding to the at least two behavior features (Abbasi – Paragraph [0051]: the monitoring logic 250 may be used to detect one or more malicious behaviors (e.g., anomalous behavior), such as unexpected attempts to access or modify a particular file, a particular process, or a particular registry. The occurrence of these behaviors also may trigger a gathering of salient information by the monitoring logic 250, including state information. Examples of the state information may include (1) information directed to software components running in the virtual machine or the malware sample 215 being processed (e.g., running application name, version number, file type, object type, etc.) and (2) information directed to one or more behaviors (e.g., path, detected behavior name, etc.); and Paragraph [0052]: According to one embodiment of the disclosure, temporal identification logic 257 may be located within the monitoring logic 250, where the temporal identification (temp_id) logic 257 assigns an identifier to the detected malicious behavior and/or the salient information associated with the detected malicious behavior, where the identifier may be used in the chronological sequencing (or ordering) of behaviors received by the monitoring logic 250. Examples of various types of identifiers may include a time-stamp that is based on a current time as measured by a real-time clock (RTC) 258 communicatively coupled via interconnect 259 to the file system monitoring logic 252, the process monitoring logic 253, the registry monitoring logic 254 and/or the network access monitoring logic 255. Alternatively, the identifier may include a sequence number as generated by a monotonic counter for example. Connectivity to a common time source (or a counting source such as a monotonic counter) ensures that the chronological ordering of the behaviors; Examiner’s Comment: the detected malicious behaviors are interpreted as the claimed behavior records and the salient/state information is interpreted as the claimed behavior features – both the detected malicious behaviors and the state information are described as being observed/recorded successively, according to the attribution of identifiers including timestamps for the behaviors and/or state information).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Bodorin, further incorporating Abbasi to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Abbasi’s sequential analysis of the behaviors exhibited by a data object into Bodorin’s method for detecting malicious behavior by applets. This addition would enhance a system’s capability to observe and recognize known behavioral sequences indicative of malicious activity.
The combination of Bodorin and Abbasi does not expressly teach wherein the triggering invokes a service interface for the applet to send an invoking request to a JavaScript Bridge according to an agreed protocol, wherein the JavaScript Bridge is cut, so that the applet first routes execution logic to a security aspect module when sending the invoking request to the JavaScript Bridge, wherein the security aspect module receives and forwards the invoking request to the JavaScript Bridge for the JavaScript Bridge to send an invoking request response to the security aspect module, and wherein the security aspect module forwards the invoking request response to the applet and obtains the behavior record generated when the applet invokes the service interface.
However, Bai teaches wherein the triggering invokes a service interface for the applet (Bai – P. 677, Right Col.: Generally, mobile apps can be classified into three categories: native apps, mobile Web apps, and hybrid apps. Native apps are developed for specific platforms. They are usually developed with platform specific languages, e.g., Java for Android and Objective-C for iOS. Native apps can invoke application programming interfaces (APIs) provided by the platform to directly access hardware and local resources, making them achieve high performance and satisfy user experiences. … mobile Web apps are typically implemented with platform-independent Web technologies like HTML, CSS, and JavaScript (JS). They are interpreted to run by web browsers built in mobile platforms, without compiling and installing … The recently emerged hybrid apps try to achieve both optimized performance and cross-platform capabilities by combining native code and Web code. Because hybrid apps can take advantages of both native apps and Web apps; and P. 678, Figure 1: illustration of a hybrid app containing a native environment and web environment; Examiner’s Comment: According to the description provided in Paragraph [0002] of the instant specification, “An applet is an application that can be used without downloading and installing. Generally, the applet needs to rely on a specific applet platform (other application software), and implements its service functions through a service interface provided by the applet platform”. Therefore, the web apps/components of the hybrid apps described in Bai are interpreted to represent the claimed applets) to send an invoking request to a JavaScript Bridge according to an agreed protocol (Bai – P. 678, Right Col.: In order to interoperate between the native code and Web code, hybrid apps use a communication mechanism called JavaScript bridge. This mechanism provides a method to transmit data through the language boundary, which makes it easier to develop the app; and P. 678, Left Col.: The code in the higher layer is rendered by an embedded Web component provided by the mobile platform (e.g., WebView on Android) and interpreted by its JS engine. To enable Web code to access the hardware resources and use the platform APIs, the Web component provides a special communication mechanism called bridge communication for interoperation between Web code and native code; and P. 679, Left Col.: Although the cross-language communication capabilities provided by different mobile platforms vary slightly, their basic mechanisms are similar. These mechanisms are usually implemented based on APIs within the Web components. Through these APIs, the native code and the web code can invoke each other and transfer data between different languages. In the following, we use the Android framework’s communication mechanisms as an example to explain the cross-language communication interface. Android provides two kinds of communication mechanisms for inter-operation between Java and JavaScript: bridge communication and callback communication. The first mechanism mainly depends on the WebView’s add-JavaScriptInterface API. By using this API, developers can inject Java objects into the Web context. The JS code can access the injected objects and call their native methods. During the method invocation, data can be passed between Java and JS as method arguments or method results), wherein the JavaScript Bridge is cut, so that the applet first routes execution logic to a security aspect module when sending the invoking request to the JavaScript Bridge (Bai – P. 690, Left Col.: BRIDGETAINT uses a dynamic method to record and map the data on the transmission path, which is different from the one used in HybriDroid. To do this, BRIDGETAINT adds hook points in the underlying JNI implementation of WebView in order to record the actual bridge methods, the method parameters, and the method return values in the bidirectional channels), wherein the security aspect module receives and forwards the invoking request to the JavaScript Bridge for the JavaScript Bridge to send an invoking request response to the security aspect module (Bai – P. 690, Left Col.: BRIDGETAINT uses a dynamic method to record and map the data on the transmission path, which is different from the one used in HybriDroid. To do this, BRIDGETAINT adds hook points in the underlying JNI implementation of WebView in order to record the actual bridge methods, the method parameters, and the method return values in the bidirectional channels), and wherein the security aspect module forwards the invoking request response to the applet (Bai – P. 690, Left Col.: BRIDGETAINT uses a dynamic method to record and map the data on the transmission path, which is different from the one used in HybriDroid. To do this, BRIDGETAINT adds hook points in the underlying JNI implementation of WebView in order to record the actual bridge methods, the method parameters, and the method return values in the bidirectional channels) and obtains the behavior record generated when the applet invokes the service interface (Bai – P. 682, Right Col.: a) Taint logging: To ensure the uniqueness of data mappings and distinguish between different bridge methods with arguments of different data types, we record complete relevant information of the transmitted data. The detailed recorded information includes the bridge method name, as well as the taint information of its parameters and the result of the corresponding Java method. We represent the recorded information as a triple (M, A, R). The taint information A and R are also a triple (S, V, T), where S is the data type, V is the original value and T is the taint tag in the Web and the Java environment).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Bodorin and Abbasi, further incorporating Bai to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Bai’s teachings to intercept/monitor communications facilitated via a JS Bridge to track and detect suspicious behavior into Bodorin and Abbasi’s method for detecting malicious behavior by applets. While Bai is directed to observing behavior of “hybrid apps”, one of ordinary skill in the art would be motivated to apply the known technique established by Bai to monitoring applet invocations. Bai’s hybrid apps encompass web apps whose functionality directly reflects the applet functionality described in Paragraph [0002] of the instant specification, as noted above. As claimed, the applets implement a JavaScript bridge in a way that is mirrored by the teachings of Bai with respect to the web components of the hybrid apps. Therefore, such a technique for monitoring web component communications processed through a JavaScript bridge would provide the obvious benefit of enabling a capability to monitor and record applet behaviors during processing of service interface invocations and corresponding invocation responses.
Regarding Claim 2:
The combination of Bodorin, Abbasi, and Bai teaches the method according to claim 1.
Bodorin further teaches wherein the behavior record comprises at least one of the following: a name of a service interface invoked by the applet, time information when the applet invokes the service interface, parameter information in an invoking request sent by the applet, parameter information in an invoking request response received by the applet, and information about a function page corresponding to the applet after invoking the service interface (Bodorin – Paragraph [0024]: As the code module 212 executes within the dynamic behavior evaluation module 204, the dynamic behavior evaluation module records "interesting" behaviors exhibited by the code module. Interesting behaviors are those which a user or implementer of the malware detection system 200 has identified as interesting, potentially associated with malware, and are used to compare the behaviors of the code module 212 against known malware behaviors. Table A includes an exemplary, representative list of "interesting" behaviors, including parameters that are also considered interesting, that are recorded by a dynamic behavior evaluation module 204; and Table A: list of “interesting” behaviors recorded while code module 212 is running, including multiple functions which invoke service interfaces and include parameters).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 3:
The combination of Bodorin, Abbasi, and Bai teaches the method according to claim 1.
Bodorin further teaches wherein the obtaining at least two behavior records that are generated through triggering during running of the applet comprises: obtaining at least two behavior records generated by the applet during running of the applet (Bodorin – Paragraph [0024]: As the code module 212 executes within the dynamic behavior evaluation module 204, the dynamic behavior evaluation module records "interesting" behaviors exhibited by the code module. Interesting behaviors are those which a user or implementer of the malware detection system 200 has identified as interesting, potentially associated with malware, and are used to compare the behaviors of the code module 212 against known malware behaviors. Table A includes an exemplary, representative list of "interesting" behaviors, including parameters that are also considered interesting, that are recorded by a dynamic behavior evaluation module 204; and Table A: list of “interesting” behaviors recorded while code module 212 is running); and the forming at least one feature combination by using the at least two behavior features of the at least two [successively] generated behavior records comprises: forming one feature combination by using behavior features of the at least two behavior records generated by the applet (Bodorin – Figures 5A and 5B: Illustrations of behavior signatures which include behavior feature of multiple behavior records).
Abbasi further teaches successively generated behavior records (Abbasi – Paragraph [0052]: According to one embodiment of the disclosure, temporal identification logic 257 may be located within the monitoring logic 250, where the temporal identification (temp_id) logic 257 assigns an identifier to the detected malicious behavior and/or the salient information associated with the detected malicious behavior, where the identifier may be used in the chronological sequencing (or ordering) of behaviors received by the monitoring logic 250. Examples of various types of identifiers may include a time-stamp that is based on a current time as measured by a real-time clock (RTC) 258 communicatively coupled via interconnect 259 to the file system monitoring logic 252, the process monitoring logic 253, the registry monitoring logic 254 and/or the network access monitoring logic 255. Alternatively, the identifier may include a sequence number as generated by a monotonic counter for example. Connectivity to a common time source (or a counting source such as a monotonic counter) ensures that the chronological ordering of the behaviors).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 6:
The combination of Bodorin, Abbasi, and Bai teaches the method according to claim 3.
Bodorin further teaches wherein the obtaining the at least two behavior records generated by the applet during running of the applet comprises: obtaining at least two behavior records generated when the applet invokes at least two service interfaces during running of the applet (Bodorin – Paragraph [0024]: As the code module 212 executes within the dynamic behavior evaluation module 204, the dynamic behavior evaluation module records "interesting" behaviors exhibited by the code module. Interesting behaviors are those which a user or implementer of the malware detection system 200 has identified as interesting, potentially associated with malware, and are used to compare the behaviors of the code module 212 against known malware behaviors. Table A includes an exemplary, representative list of "interesting" behaviors, including parameters that are also considered interesting, that are recorded by a dynamic behavior evaluation module 204; and Table A: list of “interesting” behaviors recorded while code module 212 is running, including multiple functions which invoke service interfaces).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 15:
Bodorin teaches obtain at least two behavior records that are generated through triggering during running of an applet (Bodorin – Paragraph [0024]: As the code module 212 executes within the dynamic behavior evaluation module 204, the dynamic behavior evaluation module records "interesting" behaviors exhibited by the code module. Interesting behaviors are those which a user or implementer of the malware detection system 200 has identified as interesting, potentially associated with malware, and are used to compare the behaviors of the code module 212 against known malware behaviors. Table A includes an exemplary, representative list of "interesting" behaviors, including parameters that are also considered interesting, that are recorded by a dynamic behavior evaluation module 204; and Table A: list of “interesting” behaviors recorded while code module 212 is running); extract a behavior feature of each of the at least two behavior records (Bodorin – Paragraph [0038]: As illustrated in both behavior signature 500 and behavior signature 512, each behavior includes three elements: a behavior token, such as behavior token 502; a first parameter value, such as parameter value 504; and a second parameter value, such as parameter value 506); form at least one feature combination by using at least two behavior features of at least two [successively] generated behavior records, wherein each feature combination comprises at least two behavior features (Bodorin – Figures 5A and 5B: Illustrations of behavior signatures which include behavior feature of multiple behavior records); determine whether there is at least one feature combination that comprises a predetermined feature combination of a malicious behavior record; and if there is at least one feature combination that comprises the predetermined feature combination of a malicious behavior record, determining that the applet conducts a malicious behavior (Bodorin – Paragraph [0026]: Once the behavior signature 210 has been generated, the behavior signature comparison module 206 takes the behavior signature and compares it against behavior signatures of known malware that are stored in the malware behavior signature store 208. The malware behavior signature store 208 is a repository of behavior signatures of known malware. However, unlike signature files of anti-virus software 204, behavior signatures stored in the malware behavior signature store 208 are based on exhibited behaviors of malware. As such, even though all variable names and routine names within source code for malware are modified by a malicious party, the exhibited behaviors of the malware remain the same, and will be detected by the malware detection system 200 when the behavior signature comparison module 206 matches a code module's behavior signature 210 to a known malware's behavior signature in the malware behavior signature store 208).
Bodorin does not expressly teach a non-transitory computer-readable storage medium comprising instructions stored therein that, when executed by a processor of a computing device, cause the processor to: successively generated behavior records; and a sequence of the at least two behavior features in the feature combination is the same as a time sequence of generating behavior records corresponding to the at least two behavior features.
However, Abbasi teaches a non-transitory computer-readable storage medium (Abbasi – Paragraph [0029]: Herein, the electronic device 100 comprises one or more hardware processors (referred to as “processor(s)”) 110, a memory 120) comprising instructions stored therein that, when executed by a processor of a computing device, cause the processor to: (Abbasi – Paragraph [0032]: The memory 120 includes a plurality of locations that are addressable by the processor(s) 110 and the network interface(s) 130 for storing software components (including software applications) and data structures associated with such software components. Some of the stored software components, associated with a threat detection system described below, may include the following: a behavior reporting logic 170, a behavioral rule-matching logic 180, and/or a malware classification logic 190. It is contemplated, however, that some or all of logic 170, 180 and 190 may be hardware logic that performs the functionality described below); successively generated behavior records (Abbasi – Paragraph [0052]: According to one embodiment of the disclosure, temporal identification logic 257 may be located within the monitoring logic 250, where the temporal identification (temp_id) logic 257 assigns an identifier to the detected malicious behavior and/or the salient information associated with the detected malicious behavior, where the identifier may be used in the chronological sequencing (or ordering) of behaviors received by the monitoring logic 250. Examples of various types of identifiers may include a time-stamp that is based on a current time as measured by a real-time clock (RTC) 258 communicatively coupled via interconnect 259 to the file system monitoring logic 252, the process monitoring logic 253, the registry monitoring logic 254 and/or the network access monitoring logic 255. Alternatively, the identifier may include a sequence number as generated by a monotonic counter for example. Connectivity to a common time source (or a counting source such as a monotonic counter) ensures that the chronological ordering of the behaviors); and a sequence of the at least two behavior features in the feature combination is the same as a time sequence of generating behavior records corresponding to the at least two behavior features (Abbasi – Paragraph [0051]: the monitoring logic 250 may be used to detect one or more malicious behaviors (e.g., anomalous behavior), such as unexpected attempts to access or modify a particular file, a particular process, or a particular registry. The occurrence of these behaviors also may trigger a gathering of salient information by the monitoring logic 250, including state information. Examples of the state information may include (1) information directed to software components running in the virtual machine or the malware sample 215 being processed (e.g., running application name, version number, file type, object type, etc.) and (2) information directed to one or more behaviors (e.g., path, detected behavior name, etc.); and Paragraph [0052]: According to one embodiment of the disclosure, temporal identification logic 257 may be located within the monitoring logic 250, where the temporal identification (temp_id) logic 257 assigns an identifier to the detected malicious behavior and/or the salient information associated with the detected malicious behavior, where the identifier may be used in the chronological sequencing (or ordering) of behaviors received by the monitoring logic 250. Examples of various types of identifiers may include a time-stamp that is based on a current time as measured by a real-time clock (RTC) 258 communicatively coupled via interconnect 259 to the file system monitoring logic 252, the process monitoring logic 253, the registry monitoring logic 254 and/or the network access monitoring logic 255. Alternatively, the identifier may include a sequence number as generated by a monotonic counter for example. Connectivity to a common time source (or a counting source such as a monotonic counter) ensures that the chronological ordering of the behaviors; Examiner’s Comment: the detected malicious behaviors are interpreted as the claimed behavior records and the salient/state information is interpreted as the claimed behavior features – both the detected malicious behaviors and the state information are described as being observed/recorded successively, according to the attribution of identifiers including timestamps for the behaviors and/or state information).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Bodorin, further incorporating Abbasi to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Abbasi’s memory, processor, and sequential analysis of the behaviors exhibited by a data object into Bodorin’s method for detecting malicious behavior by applets. This addition would provide a practical capability and enhancement of a system’s observation and recognition of known behavioral sequences indicative of malicious activity.
The combination of Bodorin and Abbasi does not expressly teach wherein the triggering invokes a service interface for the applet to send an invoking request to a JavaScript Bridge according to an agreed protocol, wherein the JavaScript Bridge is cut, so that the applet first routes execution logic to a security aspect module when sending the invoking request to the JavaScript Bridge, wherein the security aspect module receives and forwards the invoking request to the JavaScript Bridge for the JavaScript Bridge to send an invoking request response to the security aspect module, and wherein the security aspect module forwards the invoking request response to the applet and obtains the behavior record generated when the applet invokes the service interface.
However, Bai teaches wherein the triggering invokes a service interface for the applet (Bai – P. 677, Right Col.: Generally, mobile apps can be classified into three categories: native apps, mobile Web apps, and hybrid apps. Native apps are developed for specific platforms. They are usually developed with platform specific languages, e.g., Java for Android and Objective-C for iOS. Native apps can invoke application programming interfaces (APIs) provided by the platform to directly access hardware and local resources, making them achieve high performance and satisfy user experiences. … mobile Web apps are typically implemented with platform-independent Web technologies like HTML, CSS, and JavaScript (JS). They are interpreted to run by web browsers built in mobile platforms, without compiling and installing … The recently emerged hybrid apps try to achieve both optimized performance and cross-platform capabilities by combining native code and Web code. Because hybrid apps can take advantages of both native apps and Web apps; and P. 678, Figure 1: illustration of a hybrid app containing a native environment and web environment; Examiner’s Comment: According to the description provided in Paragraph [0002] of the instant specification, “An applet is an application that can be used without downloading and installing. Generally, the applet needs to rely on a specific applet platform (other application software), and implements its service functions through a service interface provided by the applet platform”. Therefore, the web apps/components of the hybrid apps described in Bai are interpreted to represent the claimed applets) to send an invoking request to a JavaScript Bridge according to an agreed protocol (Bai – P. 678, Right Col.: In order to interoperate between the native code and Web code, hybrid apps use a communication mechanism called JavaScript bridge. This mechanism provides a method to transmit data through the language boundary, which makes it easier to develop the app; and P. 678, Left Col.: The code in the higher layer is rendered by an embedded Web component provided by the mobile platform (e.g., WebView on Android) and interpreted by its JS engine. To enable Web code to access the hardware resources and use the platform APIs, the Web component provides a special communication mechanism called bridge communication for interoperation between Web code and native code; and P. 679, Left Col.: Although the cross-language communication capabilities provided by different mobile platforms vary slightly, their basic mechanisms are similar. These mechanisms are usually implemented based on APIs within the Web components. Through these APIs, the native code and the web code can invoke each other and transfer data between different languages. In the following, we use the Android framework’s communication mechanisms as an example to explain the cross-language communication interface. Android provides two kinds of communication mechanisms for inter-operation between Java and JavaScript: bridge communication and callback communication. The first mechanism mainly depends on the WebView’s add-JavaScriptInterface API. By using this API, developers can inject Java objects into the Web context. The JS code can access the injected objects and call their native methods. During the method invocation, data can be passed between Java and JS as method arguments or method results), wherein the JavaScript Bridge is cut, so that the applet first routes execution logic to a security aspect module when sending the invoking request to the JavaScript Bridge (Bai – P. 690, Col. 1: BRIDGETAINT uses a dynamic method to record and map the data on the transmission path, which is different from the one used in HybriDroid. To do this, BRIDGETAINT adds hook points in the underlying JNI implementation of WebView in order to record the actual bridge methods, the method parameters, and the method return values in the bidirectional channels), wherein the security aspect module receives and forwards the invoking request to the JavaScript Bridge for the JavaScript Bridge to send an invoking request response to the security aspect module (Bai – P. 690, Col. 1: BRIDGETAINT uses a dynamic method to record and map the data on the transmission path, which is different from the one used in HybriDroid. To do this, BRIDGETAINT adds hook points in the underlying JNI implementation of WebView in order to record the actual bridge methods, the method parameters, and the method return values in the bidirectional channels), and wherein the security aspect module forwards the invoking request response to the applet (Bai – P. 690, Col. 1: BRIDGETAINT uses a dynamic method to record and map the data on the transmission path, which is different from the one used in HybriDroid. To do this, BRIDGETAINT adds hook points in the underlying JNI implementation of WebView in order to record the actual bridge methods, the method parameters, and the method return values in the bidirectional channels) and obtains the behavior record generated when the applet invokes the service interface (Bai – P. 682, Col. 2: a) Taint logging: To ensure the uniqueness of data mappings and distinguish between different bridge methods with arguments of different data types, we record complete relevant information of the transmitted data. The detailed recorded information includes the bridge method name, as well as the taint information of its parameters and the result of the corresponding Java method. We represent the recorded information as a triple (M, A, R). The taint information A and R are also a triple (S, V, T), where S is the data type, V is the original value and T is the taint tag in the Web and the Java environment).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Bodorin and Abbasi, further incorporating Bai to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Bai’s teachings to intercept/monitor communications facilitated via a JS Bridge to track and detect suspicious behavior into Bodorin and Abbasi’s method for detecting malicious behavior by applets. While Bai is directed to observing behavior of “hybrid apps”, one of ordinary skill in the art would be motivated to apply the known technique established by Bai to monitoring applet invocations. Bai’s hybrid apps encompass web apps whose functionality directly reflects the applet functionality described in Paragraph [0002] of the instant specification, as noted above. As claimed, the applets implement a JavaScript bridge in a way that is mirrored by the teachings of Bai with respect to the web components of the hybrid apps. Therefore, such a technique for monitoring web component communications processed through a JavaScript bridge would provide the obvious benefit of enabling a capability to monitor and record applet behaviors during processing of service interface invocations and corresponding invocation responses.
Regarding Claim 16:
Bodorin teaches obtain at least two behavior records that are generated through triggering during running of an applet (Bodorin – Paragraph [0024]: As the code module 212 executes within the dynamic behavior evaluation module 204, the dynamic behavior evaluation module records "interesting" behaviors exhibited by the code module. Interesting behaviors are those which a user or implementer of the malware detection system 200 has identified as interesting, potentially associated with malware, and are used to compare the behaviors of the code module 212 against known malware behaviors. Table A includes an exemplary, representative list of "interesting" behaviors, including parameters that are also considered interesting, that are recorded by a dynamic behavior evaluation module 204; and Table A: list of “interesting” behaviors recorded while code module 212 is running); extract a behavior feature of each of the at least two behavior record (Bodorin – Paragraph [0038]: As illustrated in both behavior signature 500 and behavior signature 512, each behavior includes three elements: a behavior token, such as behavior token 502; a first parameter value, such as parameter value 504; and a second parameter value, such as parameter value 506); form at least one feature combination by using at least two behavior features of at least two [successively] generated behavior records, wherein each feature combination comprises at least two behavior features (Bodorin – Figures 5A and 5B: Illustrations of behavior signatures which include behavior feature of multiple behavior records); determine whether there is at least one feature combination that comprises a predetermined feature combination of a malicious behavior record; and if there is at least one feature combination that comprises the predetermined feature combination of a malicious behavior record, determining that the applet conducts the malicious behavior (Bodorin – Paragraph [0026]: Once the behavior signature 210 has been generated, the behavior signature comparison module 206 takes the behavior signature and compares it against behavior signatures of known malware that are stored in the malware behavior signature store 208. The malware behavior signature store 208 is a repository of behavior signatures of known malware. However, unlike signature files of anti-virus software 204, behavior signatures stored in the malware behavior signature store 208 are based on exhibited behaviors of malware. As such, even though all variable names and routine names within source code for malware are modified by a malicious party, the exhibited behaviors of the malware remain the same, and will be detected by the malware detection system 200 when the behavior signature comparison module 206 matches a code module's behavior signature 210 to a known malware's behavior signature in the malware behavior signature store 208).
Bodorin does not expressly teach a computing device, comprising a memory and a processor, wherein the memory stores executable instructions that, in response to execution by the processor, cause processor to: successively generated behavior records; and a sequence of the at least two behavior features in the feature combination is the same as a time sequence of generating behavior records corresponding to the at least two behavior features.
However, Abbasi teaches a computing device, comprising a memory and a processor (Abbasi – Paragraph [0029]: Herein, the electronic device 100 comprises one or more hardware processors (referred to as “processor(s)”) 110, a memory 120), wherein the memory stores executable instructions that, in response to execution by the processor, cause processor to: (Abbasi – Paragraph [0032]: The memory 120 includes a plurality of locations that are addressable by the processor(s) 110 and the network interface(s) 130 for storing software components (including software applications) and data structures associated with such software components. Some of the stored software components, associated with a threat detection system described below, may include the following: a behavior reporting logic 170, a behavioral rule-matching logic 180, and/or a malware classification logic 190. It is contemplated, however, that some or all of logic 170, 180 and 190 may be hardware logic that performs the functionality described below); successively generated behavior records (Abbasi – Paragraph [0052]: According to one embodiment of the disclosure, temporal identification logic 257 may be located within the monitoring logic 250, where the temporal identification (temp_id) logic 257 assigns an identifier to the detected malicious behavior and/or the salient information associated with the detected malicious behavior, where the identifier may be used in the chronological sequencing (or ordering) of behaviors received by the monitoring logic 250. Examples of various types of identifiers may include a time-stamp that is based on a current time as measured by a real-time clock (RTC) 258 communicatively coupled via interconnect 259 to the file system monitoring logic 252, the process monitoring logic 253, the registry monitoring logic 254 and/or the network access monitoring logic 255. Alternatively, the identifier may include a sequence number as generated by a monotonic counter for example. Connectivity to a common time source (or a counting source such as a monotonic counter) ensures that the chronological ordering of the behaviors); and a sequence of the at least two behavior features in the feature combination is the same as a time sequence of generating behavior records corresponding to the at least two behavior features (Abbasi – Paragraph [0051]: the monitoring logic 250 may be used to detect one or more malicious behaviors (e.g., anomalous behavior), such as unexpected attempts to access or modify a particular file, a particular process, or a particular registry. The occurrence of these behaviors also may trigger a gathering of salient information by the monitoring logic 250, including state information. Examples of the state information may include (1) information directed to software components running in the virtual machine or the malware sample 215 being processed (e.g., running application name, version number, file type, object type, etc.) and (2) information directed to one or more behaviors (e.g., path, detected behavior name, etc.); and Paragraph [0052]: According to one embodiment of the disclosure, temporal identification logic 257 may be located within the monitoring logic 250, where the temporal identification (temp_id) logic 257 assigns an identifier to the detected malicious behavior and/or the salient information associated with the detected malicious behavior, where the identifier may be used in the chronological sequencing (or ordering) of behaviors received by the monitoring logic 250. Examples of various types of identifiers may include a time-stamp that is based on a current time as measured by a real-time clock (RTC) 258 communicatively coupled via interconnect 259 to the file system monitoring logic 252, the process monitoring logic 253, the registry monitoring logic 254 and/or the network access monitoring logic 255. Alternatively, the identifier may include a sequence number as generated by a monotonic counter for example. Connectivity to a common time source (or a counting source such as a monotonic counter) ensures that the chronological ordering of the behaviors; Examiner’s Comment: the detected malicious behaviors are interpreted as the claimed behavior records and the salient/state information is interpreted as the claimed behavior features – both the detected malicious behaviors and the state information are described as being observed/recorded successively, according to the attribution of identifiers including timestamps for the behaviors and/or state information).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Bodorin, further incorporating Abbasi to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Abbasi’s device and sequential analysis of the behaviors exhibited by a data object into Bodorin’s method for detecting malicious behavior by applets. This addition would provide a practical capability and enhancement of a system’s observation and recognition of known behavioral sequences indicative of malicious activity.
The combination of Bodorin and Abbasi does not expressly teach wherein the triggering invokes a service interface for the applet to send an invoking request to a JavaScript Bridge according to an agreed protocol, wherein the JavaScript Bridge is cut, so that the applet first routes execution logic to a security aspect module when sending the invoking request to the JavaScript Bridge, wherein the security aspect module receives and forwards the invoking request to the JavaScript Bridge for the JavaScript Bridge to send an invoking request response to the security aspect module, and wherein the security aspect module forwards the invoking request response to the applet and obtains the behavior record generated when the applet invokes the service interface.
However, Bai teaches wherein the triggering invokes a service interface for the applet (Bai – P. 677, Right Col.: Generally, mobile apps can be classified into three categories: native apps, mobile Web apps, and hybrid apps. Native apps are developed for specific platforms. They are usually developed with platform specific languages, e.g., Java for Android and Objective-C for iOS. Native apps can invoke application programming interfaces (APIs) provided by the platform to directly access hardware and local resources, making them achieve high performance and satisfy user experiences. … mobile Web apps are typically implemented with platform-independent Web technologies like HTML, CSS, and JavaScript (JS). They are interpreted to run by web browsers built in mobile platforms, without compiling and installing … The recently emerged hybrid apps try to achieve both optimized performance and cross-platform capabilities by combining native code and Web code. Because hybrid apps can take advantages of both native apps and Web apps; and P. 678, Figure 1: illustration of a hybrid app containing a native environment and web environment; Examiner’s Comment: According to the description provided in Paragraph [0002] of the instant specification, “An applet is an application that can be used without downloading and installing. Generally, the applet needs to rely on a specific applet platform (other application software), and implements its service functions through a service interface provided by the applet platform”. Therefore, the web apps/components of the hybrid apps described in Bai are interpreted to represent the claimed applets) to send an invoking request to a JavaScript Bridge according to an agreed protocol (Bai – P. 678, Right Col.: In order to interoperate between the native code and Web code, hybrid apps use a communication mechanism called JavaScript bridge. This mechanism provides a method to transmit data through the language boundary, which makes it easier to develop the app; and P. 678, Left Col.: The code in the higher layer is rendered by an embedded Web component provided by the mobile platform (e.g., WebView on Android) and interpreted by its JS engine. To enable Web code to access the hardware resources and use the platform APIs, the Web component provides a special communication mechanism called bridge communication for interoperation between Web code and native code; and P. 679, Left Col.: Although the cross-language communication capabilities provided by different mobile platforms vary slightly, their basic mechanisms are similar. These mechanisms are usually implemented based on APIs within the Web components. Through these APIs, the native code and the web code can invoke each other and transfer data between different languages. In the following, we use the Android framework’s communication mechanisms as an example to explain the cross-language communication interface. Android provides two kinds of communication mechanisms for inter-operation between Java and JavaScript: bridge communication and callback communication. The first mechanism mainly depends on the WebView’s add-JavaScriptInterface API. By using this API, developers can inject Java objects into the Web context. The JS code can access the injected objects and call their native methods. During the method invocation, data can be passed between Java and JS as method arguments or method results), wherein the JavaScript Bridge is cut, so that the applet first routes execution logic to a security aspect module when sending the invoking request to the JavaScript Bridge (Bai – P. 690, Col. 1: BRIDGETAINT uses a dynamic method to record and map the data on the transmission path, which is different from the one used in HybriDroid. To do this, BRIDGETAINT adds hook points in the underlying JNI implementation of WebView in order to record the actual bridge methods, the method parameters, and the method return values in the bidirectional channels), wherein the security aspect module receives and forwards the invoking request to the JavaScript Bridge for the JavaScript Bridge to send an invoking request response to the security aspect module (Bai – P. 690, Col. 1: BRIDGETAINT uses a dynamic method to record and map the data on the transmission path, which is different from the one used in HybriDroid. To do this, BRIDGETAINT adds hook points in the underlying JNI implementation of WebView in order to record the actual bridge methods, the method parameters, and the method return values in the bidirectional channels), and wherein the security aspect module forwards the invoking request response to the applet (Bai – P. 690, Col. 1: BRIDGETAINT uses a dynamic method to record and map the data on the transmission path, which is different from the one used in HybriDroid. To do this, BRIDGETAINT adds hook points in the underlying JNI implementation of WebView in order to record the actual bridge methods, the method parameters, and the method return values in the bidirectional channels) and obtains the behavior record generated when the applet invokes the service interface (Bai – P. 682, Col. 2: a) Taint logging: To ensure the uniqueness of data mappings and distinguish between different bridge methods with arguments of different data types, we record complete relevant information of the transmitted data. The detailed recorded information includes the bridge method name, as well as the taint information of its parameters and the result of the corresponding Java method. We represent the recorded information as a triple (M, A, R). The taint information A and R are also a triple (S, V, T), where S is the data type, V is the original value and T is the taint tag in the Web and the Java environment).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Bodorin and Abbasi, further incorporating Bai to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Bai’s teachings to intercept/monitor communications facilitated via a JS Bridge to track and detect suspicious behavior into Bodorin and Abbasi’s method for detecting malicious behavior by applets. While Bai is directed to observing behavior of “hybrid apps”, one of ordinary skill in the art would be motivated to apply the known technique established by Bai to monitoring applet invocations. Bai’s hybrid apps encompass web apps whose functionality directly reflects the applet functionality described in Paragraph [0002] of the instant specification, as noted above. As claimed, the applets implement a JavaScript bridge in a way that is mirrored by the teachings of Bai with respect to the web components of the hybrid apps. Therefore, such a technique for monitoring web component communications processed through a JavaScript bridge would provide the obvious benefit of enabling a capability to monitor and record applet behaviors during processing of service interface invocations and corresponding invocation responses.
Claim(s) 4 and 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bodorin in view of Abbasi, Bai, and Sahita et al. (US 20170185778 A1), hereinafter Sahita.
Regarding Claim 4:
The combination of Bodorin, Abbasi, and Bai teaches the method according to claim 1.
Bodorin further teaches wherein the obtaining at least two behavior records that are generated through triggering during running of the applet comprises: obtaining at least two behavior records generated by the applet during running of the applet (Bodorin – Paragraph [0024]: As the code module 212 executes within the dynamic behavior evaluation module 204, the dynamic behavior evaluation module records "interesting" behaviors exhibited by the code module. Interesting behaviors are those which a user or implementer of the malware detection system 200 has identified as interesting, potentially associated with malware, and are used to compare the behaviors of the code module 212 against known malware behaviors. Table A includes an exemplary, representative list of "interesting" behaviors, including parameters that are also considered interesting, that are recorded by a dynamic behavior evaluation module 204; and Table A: list of “interesting” behaviors recorded while code module 212 is running).
The combination of Bodorin, Abbasi, and Bai does not expressly teach for two adjacent behavior records in the at least two behavior records generated by the applet, when a first function page corresponding to one of the at least two behavior records generated by the applet with an earlier generation time jumps to a second function page corresponding to another one of the at least two behavior records generated by the applet with a later generation time, determining whether the first function page jumps to the second function page via at least one third function page, and if the first function page jumps to the second function page via the at least one third function page, generating a corresponding behavior record for the third function page; and using the at least two behavior records generated by the applet and the behavior record corresponding to the third function page as the at least two behavior records that are generated through triggering during running of the applet.
However, Sahita teaches for two adjacent behavior records in the at least two behavior records generated by the applet, when a first function page corresponding to one of the at least two behavior records generated by the applet with an earlier generation time jumps to a second function page corresponding to another one of the at least two behavior records generated by the applet with a later generation time, determining whether the first function page jumps to the second function page via at least one third function page, and if the first function page jumps to the second function page via the at least one third function page, generating a corresponding behavior record for the third function page (Sahita – Paragraph [0019]-[0029]: [0019] The Full Logic Path application facilitates replicating the examining source through all of its logical branches with recording of behaviors based on layered approach. Execution based on EXP-C will make the Full Logic Path application invisible to samples (malwares) hence providing a very accurate and stable flow control method. [0020] In general, the execution of the full logical path includes: [0021] 1. Backing up environmental data (registers, file, process and hive handles, etc.); [0022] 2. Executing a set of available instructions to the next “jump” condition within ExP-C interface functions; [0023] 3. Recording APIs/Parameters calls; [0024] 4. Restarting the jump-start instruction; [0025] 5. Restoring environmental data at jump-start instruction; [0026] 6. Executing next set of instructions; [0027] 7. Recording APIs/Parameters calls; and [0028] 8. Repeating to the next jump call [0029] Further analysis of the collected data will dictate the final verdict of sample maliciousness; and Paragraph [0042]: The FLPA 110 can simulate a run-time execution of the executable application 108 from within the secure environment of the sandbox 106. The FLPA 110 can force the execution of all or a subset of all logical paths that the executable application 108 includes. In addition or in the alternative, the FLPA 110 can implement EXP-C to execute each branch of the executable application); and using the at least two behavior records generated by the applet and the behavior record corresponding to the third function page as the at least two behavior records that are generated through triggering during running of the applet (Sahita – Paragraph [0019]-[0029]: [0019] The Full Logic Path application facilitates replicating the examining source through all of its logical branches with recording of behaviors based on layered approach. Execution based on EXP-C will make the Full Logic Path application invisible to samples (malwares) hence providing a very accurate and stable flow control method. [0020] In general, the execution of the full logical path includes: [0021] 1. Backing up environmental data (registers, file, process and hive handles, etc.); [0022] 2. Executing a set of available instructions to the next “jump” condition within ExP-C interface functions; [0023] 3. Recording APIs/Parameters calls; [0024] 4. Restarting the jump-start instruction; [0025] 5. Restoring environmental data at jump-start instruction; [0026] 6. Executing next set of instructions; [0027] 7. Recording APIs/Parameters calls; and [0028] 8. Repeating to the next jump call [0029] Further analysis of the collected data will dictate the final verdict of sample maliciousness; and Paragraph [0042]: The FLPA 110 can simulate a run-time execution of the executable application 108 from within the secure environment of the sandbox 106. The FLPA 110 can force the execution of all or a subset of all logical paths that the executable application 108 includes. In addition or in the alternative, the FLPA 110 can implement EXP-C to execute each branch of the executable application; and Paragraph [0033]: For the purposes of the following specification, executable application 108 can include … run-time interpreted code or applets (e.g., Java™ applets, Visual Basic® Controls, .Net™ code)).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Bodorin, Abbasi, and Bai, further incorporating Sahita to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Sahita’s teaching to analyze every step and sequence of a logical path of execution of an applet into Bodorin, Abbasi, and Bai’s combined method for detecting malicious behavior by applets. This addition would further enhance the security of the system by providing an additional mechanism/technique to identify potentially malicious applet behavior.
Regarding Claim 5:
The combination of Bodorin, Abbasi, and Sahita teaches the method according to claim 4.
Bodorin further teaches wherein the forming at least one feature combination by using the at least two behavior features of the at least two [successively] generated behavior records comprises: forming a first feature combination by using behavior features of the at least two behavior records generated by the applet (Bodorin – Figures 5A and 5B: Illustrations of behavior signatures which include behavior feature of multiple behavior records).
Abbasi further teaches successively generated behavior records (Abbasi – Paragraph [0052]: According to one embodiment of the disclosure, temporal identification logic 257 may be located within the monitoring logic 250, where the temporal identification (temp_id) logic 257 assigns an identifier to the detected malicious behavior and/or the salient information associated with the detected malicious behavior, where the identifier may be used in the chronological sequencing (or ordering) of behaviors received by the monitoring logic 250. Examples of various types of identifiers may include a time-stamp that is based on a current time as measured by a real-time clock (RTC) 258 communicatively coupled via interconnect 259 to the file system monitoring logic 252, the process monitoring logic 253, the registry monitoring logic 254 and/or the network access monitoring logic 255. Alternatively, the identifier may include a sequence number as generated by a monotonic counter for example. Connectivity to a common time source (or a counting source such as a monotonic counter) ensures that the chronological ordering of the behaviors).
Sahita further teaches and forming at least one second feature combination by using the behavior features of the at least two behavior records generated by the applet and a behavior feature of the behavior record corresponding to the third function page (Sahita – Paragraph [0019]-[0029]: [0019] The Full Logic Path application facilitates replicating the examining source through all of its logical branches with recording of behaviors based on layered approach. Execution based on EXP-C will make the Full Logic Path application invisible to samples (malwares) hence providing a very accurate and stable flow control method. [0020] In general, the execution of the full logical path includes: [0021] 1. Backing up environmental data (registers, file, process and hive handles, etc.); [0022] 2. Executing a set of available instructions to the next “jump” condition within ExP-C interface functions; [0023] 3. Recording APIs/Parameters calls; [0024] 4. Restarting the jump-start instruction; [0025] 5. Restoring environmental data at jump-start instruction; [0026] 6. Executing next set of instructions; [0027] 7. Recording APIs/Parameters calls; and [0028] 8. Repeating to the next jump call [0029] Further analysis of the collected data will dictate the final verdict of sample maliciousness; and Paragraph [0042]: The FLPA 110 can simulate a run-time execution of the executable application 108 from within the secure environment of the sandbox 106. The FLPA 110 can force the execution of all or a subset of all logical paths that the executable application 108 includes. In addition or in the alternative, the FLPA 110 can implement EXP-C to execute each branch of the executable application; and Paragraph [0033]: For the purposes of the following specification, executable application 108 can include … run-time interpreted code or applets (e.g., Java™ applets, Visual Basic® Controls, .Net™ code)).
The motivation to combine the arts is the same as that of Claim 4.
Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bodorin in view of Abbasi, Bai, and Lou (US 7779472 B1), hereinafter Lou.
Regarding Claim 7:
The combination of Bodorin, Abbasi, and Bai teaches the method according to claim 1.
Bodorin further teaches extracting the behavior feature of each of the at least two behavior records (Bodorin – Paragraph [0038]: As illustrated in both behavior signature 500 and behavior signature 512, each behavior includes three elements: a behavior token, such as behavior token 502; a first parameter value, such as parameter value 504; and a second parameter value, such as parameter value 506); a service interface invoked by the applet (Bodorin – Paragraph [0024]: As the code module 212 executes within the dynamic behavior evaluation module 204, the dynamic behavior evaluation module records "interesting" behaviors exhibited by the code module. Interesting behaviors are those which a user or implementer of the malware detection system 200 has identified as interesting, potentially associated with malware, and are used to compare the behaviors of the code module 212 against known malware behaviors. Table A includes an exemplary, representative list of "interesting" behaviors, including parameters that are also considered interesting, that are recorded by a dynamic behavior evaluation module 204; and Table A: list of “interesting” behaviors recorded while code module 212 is running, including multiple functions which invoke service interfaces and include parameters).
The combination of Bodorin, Abbasi, and Bai does not expressly teach wherein the [extracting the behavior feature of each of the at least two behavior records] comprises at least one of the following: determining, based on a name, comprised in the behavior record, of a [service interface invoked by the applet], a classification of the service interface; determining a classification value corresponding to the classification of the service interface based on a classification value predefined for each classification; and determining the determined classification value as the behavior feature of the behavior record; and/or detecting, based on parameter information, comprised in the behavior record, in an invoking request sent by the applet and parameter information, comprised in the behavior record, in an invoking request response received by the applet, privacy data comprised in the parameter information; determining, based on a predetermined mapping relationship between a data type and a sensitivity weight value, a sensitivity weight value corresponding to the privacy data; and determining the sensitivity weight value corresponding to the privacy data as the behavior feature of the behavior record.
However, Lou teaches wherein the extracting a behavior feature of each behavior record (Lou – Col. 2, Line 3-14: A method of detecting malware begins by first receiving a suspect executable computer file. Next, the executable file is loaded into a virtual machine arranged to emulate the instructions of the executable file. The instructions of the executable file are emulated using the virtual machine. A behavior flag if any suspect conditions occur during emulation. The virtual machine keeps track of application programming interfaces (APIs) used by the executable file during emulation. The APIs used are compared with a set of known behaviors, each known behavior includes a list of APIs used by malware. Finally, a determination is made that the executable file is malware based upon the results of the comparison) comprises at least one of the following: determining, based on a name, comprised in the behavior record, of a service interface invoked [by the applet], a classification of the service interface (Lou – Col. 2, Line 19-23: The executable file is scanned to determine names of (APIs) used. Behavior flags are set if certain conditions occur within the executable file. The APIs determined during emulation and during scanning are compared with a set of known behaviors); determining a classification value corresponding to the classification of the service interface based on a classification value predefined for each classification (Lou – Col. 6, Line 21-33: FIG. 4 shows the format of an API list 404 that may be embodied in a database used in conjunction with the virtual machine of the present invention (for example, in the Rule file). List 404 includes any number of API name strings that have been determined to be indicative of malware; the block includes a single line data structure as shown for each particular API name string. For example, a single line may be: "GetVersionExA", 0x00, 0x01. The first value is the API name string, and the second value is the API type in hexadecimal, an unsigned long value having 32 bits available for use. The third value is the argument quantity (also in hexadecimal), indicating how many arguments are used for that particular routine call); and determining the determined classification value as the behavior feature of the behavior record (Lou – Col. 8, Line 60-67 and Col. 9 , Line 1-5: For example, if the virtual machine determines that an API having the name "FindFirstFileA" is used by the suspect file, it is determined that its API type is 0x0001. Performing a bit-wise OR with the variable Dynamic Behavior (initially having a value zero) results in Dynamic Behavior=1. This variable now indicates that the suspect computer file exhibits the specific behavior of seeking files. Each time that the virtual machine detects usage of a particular API name the virtual machine determines the corresponding API type and performs the OR operation with the current value of the variable Dynamic Behavior. In this fashion the variable keeps a running tally of all the different types of suspect APIs that the suspect computer file is utilizing); and/or detecting, based on parameter information, comprised in the behavior record, in an invoking request sent by the applet and parameter information, comprised in the behavior record, in an invoking request response received by the applet, privacy data comprised in the parameter information; determining, based on a predetermined mapping relationship between a data type and a sensitivity weight value, a sensitivity weight value corresponding to the privacy data; and determining the sensitivity weight value corresponding to the privacy data as the behavior feature of the behavior record (Examiner’s Comment: The and/or is interpreted as or. Thus, the remaining limitations are moot in view of the teachings of Lou).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Bodorin, Abbasi, and Bai, further incorporating Lou to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Lou’s teaching to evaluate types of interfaces invoked during code execution as being indicative of malicious activity into Bodorin, Abbasi, and Bai’s combined method for detecting malicious behavior by applets. This combination would provide a system with an additional criterion to assess anomalous and/or potentially malicious behavior in examined processes.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Danileiko (US 9942268 B1) teaches a method for monitoring runtime behavior of an applet for detecting potentially malicious behavior
Mao et al. (Mao, J., Bian, J., Bai, G., Wang, R., Chen, Y., Xiao, Y., & Liang, Z. (2018). Detecting malicious behaviors in JavaScript applications. IEEE Access, 6, 12284–12294. https://doi.org/10.1109/access.2018.2795383) teaches methods for generating application behavior models based on activation of interface APIs in a bridge component
Gupta (US 20010039565 A1) teaches a method for implementing a proxy for intercepting system communications to and from applets to monitor applet behavior
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS JOSEPH DILUZIO whose telephone number is (703)756-1229. The examiner can normally be reached Mon - Fri -- 7:30 AM - 5 PM.
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, Yin-Chen Shaw can be reached at 571-272-8878. 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.
/NICHOLAS JOSEPH DILUZIO/Examiner, Art Unit 2498
/YIN CHEN SHAW/Supervisory Patent Examiner, Art Unit 2498
Prosecution Insights