DETAILED ACTION
This office action is in response to application filed on 12/11/2023.
Claims 1 – 14 are pending.
Priority is claimed to Korean Application KR-2023-0174843 (filed on 12/5/2023).
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim 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 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Falivene et al (US 20250028829, hereinafter Falivene), in view of Smith (US20220188170), and further in view of Wilson et al (US 20230023981, hereinafter Wilson).
As per claim 1, Falivene discloses: A method for mapping API functions to threat actions by a server in multiple cloud environments, the method comprising:
a) mapping a first API function used in a first cloud environment provided by a first cloud server to a first threat action included in an attack technique database where a plurality of threats classified into multiple types is stored; (Falivene [0074]: “The collaborative content management system 130 inputs 540 the vector of API call features into a machine learning model and receives 550, as output from the machine learning model, a determination as to whether the set of API calls represent a C2 attack. The collaborative content management system 130 may have trained the machine learning model using training data comprising sets of API calls labelled by whether they represent a C2 attack (e.g., using the model training module 438).”; [0070]: cloud environment.)
b) generating feature information of the first API function based on descriptive information for the first API function provided by the first cloud server; (Falivene [0072]: “The collaborative content management system 130 obtains 520 a set of API calls made by the identified susceptible application (e.g., using the API call obtainment module 434). The set of API calls may be stored in API call log 324 and may be a subset of API calls made by the application”; [0073]: “The collaborative content management system 130 extracts 530 a vector of API call features derived from the set of API calls made by the susceptible application (e.g., using the feature extraction module 436)”.)
and d) mapping the second API function to the first threat action. (Falivene [0074]: “The collaborative content management system 130 inputs 540 the vector of API call features into a machine learning model and receives 550, as output from the machine learning model, a determination as to whether the set of API calls represent a C2 attack. The collaborative content management system 130 may have trained the machine learning model using training data comprising sets of API calls labelled by whether they represent a C2 attack (e.g., using the model training module 438)”.)
Falivene did not explicitly disclose:
wherein the first API function is used in a first cloud environment provided by a first cloud server;
c) based on the feature information of the first API function, identifying a second API function matching the first API function among at least one API function used in a second cloud environment provided by a second cloud server;
However, Smith teaches:
wherein the first API function is used in a first cloud environment provided by a first cloud server; wherein the second API function is used in a second cloud environment provided by a second cloud server; (Smith [0027]: “The cloud provider control plane can include a cluster control plane engine, configured to generate one or more instances of an API server,”; [0028]: “For each process, the process can include a respective instance of a cluster control plane for a particular tenant, which itself may be running zero or more API server instances across one or more computing devices of the computing platform.”; [0029]: “the cloud provider control plane 102 exposes the resources of a computing platform through a platform API, which itself may be one or more separately defined APIs.”; Figure 3 shows plurality of cloud server computing device each running its own API server instance”.)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Smith into that of Falivene and Smith in order to have the first API function is used in a first cloud environment provided by a first cloud server; wherein the second API function is used in a second cloud environment provided by a second cloud server. Falivene [0070] teaches of the invention may be implemented in cloud environment. Smith [0027] – [0029] has shown that each cloud server may run its own API server instance. It would be obvious for one of ordinary skill in the art to apply the teaching of Falivene into the specific cloud environment taught by Smith in order to perform AI aided attach detection and prevention, now customized for specific cloud environment configuration, and is therefore rejected under 35 USC 103.
Wilson teaches:
c) based on the feature information of the first API function, identifying a second API function matching the first API function among at least one API function; (Wilson [0042]: “Each entry may include a cloud service provider API identifier. Each entry may also include a set of API call references, API call arguments, and API call data formats associated with each API call and API call return objects associated with the client service provider API. Each API call and API call return object of a client service provider API may mapped to and/or otherwise associated with analogous API calls (i.e., provide the same functionality) of all client service provider APIs included in the API mapping information repository (112).”; figure 1A: plurality of cloud providers.)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Wilson into that of Falivene and Smith in order to identify a second API function matching the first API function among at least one API function used in a second cloud environment provided by a second cloud server based on the feature information of the first API function. Falivene figure 5 teaches extracting feature vectors from API and feeding the vector to a trained model to determine if the API represents a C2 attack. One of ordinary skill in the art of cloud computing and network security can easily see that the overhead cost for scanning every single API call for attacks can be reduced by identifying API with similar features and group them accordingly, applicants have thus merely claimed the combination of known parts in the field to achieve predictable results of reducing attack prevention overhead, and is therefore rejected under 35 USC 103.
As per claim 2, the combination of Falivene, Smith and Wilson further teach:
The method of claim 1, wherein step b) comprises: transmitting a first request prompt to a generative artificial intelligence server, asking for summary information of a first API which encapsulates the descriptive information for the first API function; receiving the summary information of the first API from the generative artificial intelligence server in response to the first request prompt; and generating the feature information of the first API based on the summary information of the first API. (Falivene [0072]: “The collaborative content management system 130 obtains 520 a set of API calls made by the identified susceptible application (e.g., using the API call obtainment module 434). The set of API calls may be stored in API call log 324 and may be a subset of API calls made by the application”; [0073]: “The collaborative content management system 130 extracts 530 a vector of API call features derived from the set of API calls made by the susceptible application (e.g., using the feature extraction module 436)”.)
As per claim 3, the combination of Falivene, Smith and Wilson further teach:
The method of claim 2, wherein: step b) further comprises identifying a service performed in the first cloud environment when the first API function is executed, and the feature information is also based on information on the service. (Falivene [0064])
As per claim 14, the combination of Falivene, Smith and Wilson further teach:
The method of claim 1, wherein the attack technique database comprises information on types of attack techniques, descriptive information for the attack techniques, and information on detailed techniques included in the attack techniques, wherein the type is a higher-level concept comprising at least one of the attack techniques, and each of the attack techniques is a higher-level concept comprising at least one of the detailed techniques. (Falivene [0065] – [0067])
Claim(s) 10 – 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Falivene, Smith and Wilson, and further in view of Zafar et al (USPAT 11811819, hereinafter Zafar).
As per claim 10, the combination of Falivene, Smith and Wilson did not teach:
The method of claim 1, further comprising: verifying occurrence of the first threat action based on a user's event information of the second API function in the second cloud environment; verifying a response scenario for a threat scenario containing the first threat action in the first cloud environment; and based on the response scenario, determining a response solution in the second cloud environment.
However, Zafar teaches:
The method of claim 1, further comprising: verifying occurrence of the first threat action based on a user's event information of the second API function in the second cloud environment; verifying a response scenario for a threat scenario containing the first threat action in the first cloud environment; and based on the response scenario, determining a response solution in the second cloud environment. (Zafar col 4, lines 8 – 44)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Zafar into that of Falivene, Smith and Wilson in order to verify occurrence of the first threat action based on a user's event information of the second API function in the second cloud environment; verifying a response scenario for a threat scenario containing the first threat action in the first cloud environment; and based on the response scenario, determining a response solution in the second cloud environment. Falivene figure 5 teaches extracting feature vectors from API and feeding the vector to a trained model to verify if the API represents a C2 attack. Zafar teaches verification process would entail verifying occurrence of event and determine appropriate response, such combination merely claimed the combination of known parts in the field of attack detection and preventing to achieve predictable results of determining the appropriate response and is therefore rejected under 35 USC 103.
As per claim 11, the combination of Falivene, Smith, Wilson and Zafar further teach:
The method of claim 10, wherein the determining of the response solution comprises: verifying a first response API function used in the first cloud environment and included in the response scenario; and verifying a second response API function corresponding to the first response API function among the at least one API function used in the second cloud environment. (Zafar col 4, lines 8 – 44)
Allowable Subject Matter
Claims 4 – 9 and 12 – 13 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.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Chen et al (US 20230409714) teaches “a computer system can receive one or more application programming interface (API) call traces comprising metadata of API calls made by an application and can extract features from the one or more API call traces, the extracting resulting in one or more feature vectors. The computer system can then provide the one or more feature vectors as input to one or more machine learning (ML) models, where the one or more ML models are configured to generate a prediction for each of the one or more API call traces indicating whether the API call corresponding to the API call trace is normal or anomalous.”;
Mohanty et al (US 20230229534) teaches “receiving a new application programming interface (API) specification and extracting one or more keywords from the new API specification. The method also includes identifying, using a trained machine learning (ML) model, one or more existing API specifications that are similar to the new API specification based on the one or more keywords from the new API specification and, responsive to the identification, outputting information regarding the one or more existing API specifications that are similar to the new API specification.”;
Tan et al (US 20220210172) teaches “a system may obtain a first model that is trained to identify feature data associated with a client system using one or more services of a service platform. The system may train, based on the feature data, a second model to identify anomalies associated with devices accessing the one or more services in association with a client identifier of the client system. The system may receive access data associated with an acting device accessing a service of the service platform. The system may determine, using the second model, that the acting device accessing the service corresponds to potential anomalous activity based on the access information. The system may obtain, from a verification device, a verification that the acting device accessing the service is anomalous activity. The system may perform, based on obtaining the verification, an action associated with the acting device.”.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLES M SWIFT whose telephone number is (571)270-7756. The examiner can normally be reached Monday - Friday: 9:30 AM - 7PM.
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, April Blair can be reached at 5712701014. 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.
/CHARLES M SWIFT/Primary Examiner, Art Unit 2196