DETAILED ACTION
This action is responsive to application filed on 02/01/2024. Claims 1, 8 and 15 are independents. Claims 1-20 are currently 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 .
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 5, 6, 8, 12, 13, 15, 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Bolignano et al. (US 11483317 B1), hereinafter Bolignano, in view of Curtis et al. (US 11108828 B1), hereinafter Curtis.
Regarding claims 1, 8 and 15, Bolignano teaches a method (col42 ln27-49) comprising:
reading a plurality of application program interface (API) call logs generated during a transaction involving a plurality of APIs to identify a set of data objects used by the plurality of APIs (col38 ln12-29, In some embodiments, a computing resource service provider, such as those described in connection with FIG. 9, is configured so that clients of the computing resource service provider can apply security policies within an environment. In some embodiments, a client uses a command line interface to set a security policy using a web API supported by the policy management service 1804. The policy management service 1804 receives a web API request to apply a security policy and may perform one or more authorization and authentication procedures as part of fulfilling the request. The policy may be applied and stored in a policy repository 1806 where it can be retrieved for later use. In some embodiments, applying a policy and/or storing an applied policy to a policy repository 1806 generates a corresponding logging entry via a logging system. The logging system may be used to log some or all activities across a network, such as record information regarding web API requests made to a computing resource service provider; col40 ln13-32, More generally, a monitoring agent can be utilized to track the incoming requests themselves or downstream effects caused by the requests. For example, in some cases, web API requests to a computing resource service provider are parsed at a service frontend and distributed among several services of a computing resource service provider. In some cases, the monitoring agent may detect when a request is forwarded to a policy management service and parse those requests to determine whether a request applies a policy. As another example, some or all requests may be recorded in a logging system as the requests are received. The logging system may record information about the requests, such as the specific web API called, the parameters of the API call, and more. A monitoring agent may read the logs generated by requests to determine when a request applies a policy. Such a system may be performed either contemporaneous to the logging of the request or at a later point in time—for example, a monitoring agent may audit the logs once a day to check whether there are any policies in place which may violate rules imposed on the system);
assigning a particular data label to each data field among the set of data objects to provide consistent identification of a specific data type for each data field among the set of data objects (col8 ln29-col9 ln6, the Kripke structure is implemented as a graph where the nodes or vertexes are states and include the associated labeling. Edges between two nodes denote that the corresponding states are related according to R. The policy auditing service, in an embodiment, supports transitions corresponding to role assumption operations. In an embodiment, resolving the transitions is the most computationally expensive part of answering a query and may have a worst-case run-time of |S|.sup.2 comparisons using the policy analyzer service 216. In an embodiment, the graph is constructed in a breadth-first iterative fashion, beginning with the nodes corresponding to the initial states. When a node, N, is added to the graph, a check is made to determine whether the invariant is satisfied. To do so, we take the labeling for that node and the policy configuration specified as the invariant from the user and call the policy analyzer service 216 to compare them (¬φ.Math.L(s)). In an embodiment, the Kripke structure is generally sparse in the sense that |R|<<|S|.sup.2. In an embodiment, optimizations such as model enumeration and/or syntactic heuristics are utilized to ensure that graph construction is proportional to |R|. If the invariant is satisfied, the policy auditing service may provide a result 218 as an affirmative response; however, if the invariant is not satisfied, the policy auditing service may provide, as part of the result, an indication that the invariant has been violated and/or a counter-example in the form of a set of API calls that will lead to a state which violates the invariant. The result 218 may be a response to a request (e.g., CLI command described above) submitted to the policy auditing service, the request indicating one or more snapshots, a query, and a security policy);
generating, based on the plurality of API call logs, a candidate superset graph (col12 ln43-col13 ln5, If the system determines that the principal, based on its security policy, has access to call the API to assume the destination role, the system may indicate 412 that role assumption is allowed. The system may provide the indication in any suitable manner, such as by providing a response or message that indicates a Boolean value indicating that the assumption of the destination role is allowed. However, if the source principal does not have a security policy that allows access to call an API to assume the destination role, the system may determine whether 410 explicit role assumption is allowed. The system may determine whether explicit role assumption is allowed by performing a two-step process in which the system verifies that the destination role has a trust policy that explicitly or directly trusts the source principal and that the security policy of the source principal does not explicitly deny access to the API for role assumption. In an embodiment, explicit denial of access refers to a permission with a “DENY” or “DISALLOW” Effect (e.g., as discussed in connection with FIG. 7) associated with an Action for performing role assumption. In some embodiments, the system also requires that the destination role and the source policy to be in the same account. If these checks are satisfied, the system may indicate 412 that role assumption is allowed and the destination role may be added as a node or vertex to a graph [superset]);
growing the candidate superset graph by an iterative edge elimination process to generate an API call graph identifying a sequence in which the plurality of APIs were called and linkages between the plurality of APIs (col8 ln29-col9 ln6, (45) In an embodiment, sets of permissions, which may appear in the labeling function, L, and the formula φ, are represented symbolically as policy configurations as specified in the computing resource service provider. A policy analyzer service 216, in an embodiment, is used as an oracle for permission subset queries and may be implemented in accordance with those described elsewhere in this disclosure, such as those discussed in connection with FIG. 6. Techniques described in U.S. application Ser. No. 15/637,227 entitled “SECURITY POLICY ANALYZER SERVICE AND SATISFIABILITY ENGINE” and Ser. No. 15/637,238 entitled “SECURITY POLICY MONITORING SERVICE” may be utilized in connection with various embodiments described herein. In an embodiment, the Kripke structure is implemented as a graph where the nodes or vertexes are states and include the associated labeling. Edges between two nodes denote that the corresponding states are related according to R. The policy auditing service, in an embodiment, supports transitions corresponding to role assumption operations. In an embodiment, resolving the transitions is the most computationally expensive part of answering a query and may have a worst-case run-time of |S|.sup.2 comparisons using the policy analyzer service 216. In an embodiment, the graph is constructed in a breadth-first iterative fashion, beginning with the nodes corresponding to the initial states. When a node, N, is added to the graph, a check is made to determine whether the invariant is satisfied. To do so, we take the labeling for that node and the policy configuration specified as the invariant from the user and call the policy analyzer service 216 to compare them (¬φ.Math.L(s)). In an embodiment, the Kripke structure is generally sparse in the sense that |R|<<|S|.sup.2. In an embodiment, optimizations such as model enumeration and/or syntactic heuristics are utilized to ensure that graph construction is proportional to |R|. If the invariant is satisfied, the policy auditing service may provide a result 218 as an affirmative response; however, if the invariant is not satisfied, the policy auditing service may provide, as part of the result, an indication that the invariant has been violated and/or a counter-example in the form of a set of API calls that will lead to a state which violates the invariant. The result 218 may be a response to a request (e.g., CLI command described above) submitted to the policy auditing service, the request indicating one or more snapshots, a query, and a security policy).
Bolignano does not explicitly teach using the API call graph to enforce a multi-API security policy that covers the plurality of API calls of the transaction, the multi-API security policy using the particular data labels to consistently identify the specific data type for each of the data fields among the set of data objects. However, in an analogous art, Curtis teaches using the API call graph to enforce a multi-API security policy that covers the plurality of API calls of the transaction, the multi-API security policy using the particular data labels to consistently identify the specific data type for each of the data fields among the set of data objects (col32 ln41-53, In some embodiments, translating policies that explicitly specify a user's rights into permissions is straightforward. For example, systems that express ACLs in terms of a user, action, and resource are converted to a permissions graph by creating nodes for each user and each resource and then connecting a user node and a resource node if there is an ACL granting the user access to that resource. In other words, the visibility server set 1105 takes as inputs (1) the set of policies from all enforcement points (either in Rego or the native policy language of that enforcement point, e.g., AWS IAM), (2) the set of users from all systems and identity providers, and (3) the set of resources from all systems, and outputs the permission graph; Abstract).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention to modify the teachings of Bolignano and Curtis by incorporating Curtis’s teaching of using graph to enforcing policy compliance.
Regarding claims 5, 12 and 19, the combination of Bolignano and Curtis all of the limitations of claims 1, 8 and 15, respectively, as shown above. Bolignano further teaches wherein assigning a particular data label to each of the data field among the set of data objects comprises:
programmatically analyzing the set of data objects to identify each of the data fields among the set of data objects (col8 ln29-col9 ln5); and
automatically assigning a particular data label to each of the identified data fields, each assigned particular data label identifying a corresponding specific data type (col37 ln14-50).
Regarding claims 6, 13 and 20, the combination of Bolignano and Curtis all of the limitations of claims 5, 12 and 19, respectively, as shown above. Bolignano further teaches wherein programmatically identifying each of the data fields among the set of data objects comprises: programmatically identifying each of the data fields among the set of data objects using heuristics (col8 ln29-col9 ln6, optimizations such as model enumeration and/or syntactic heuristics are utilized to ensure that graph construction is proportional to |R|. If the invariant is satisfied, the policy auditing service may provide a result 218 as an affirmative response; however, if the invariant is not satisfied, the policy auditing service may provide, as part of the result, an indication that the invariant has been violated and/or a counter-example in the form of a set of API calls that will lead to a state which violates the invariant. The result 218 may be a response to a request (e.g., CLI command described above) submitted to the policy auditing service, the request indicating one or more snapshots, a query, and a security policy).
Claims 2-4, 7, 9-11, 14 and 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Bolignano and Curtis, in view of Soh; (US 20190095992 A1).
Regarding claims 2, 9 and 16, the combination of Bolignano and Curtis all of the limitations of claims 1, 8 and 15, respectively, as shown above.
The combination of Bolignano and Curtis does not explicitly teach wherein generating the API call graph comprises: identifying a set of endpoints corresponding to API services in the plurality of API call logs; and for each of the set of endpoints, generating a linear regression model that expresses the number of API calls observed for the endpoint as a function of a number of API calls observed for all neighbors of the endpoint that are observed in the candidate superset graph. However, in an analogous art, Soh teaches wherein generating the API call graph comprises: identifying a set of endpoints corresponding to API services in the plurality of API call logs; and for each of the set of endpoints, generating a linear regression model that expresses the number of API calls observed for the endpoint as a function of a number of API calls observed for all neighbors of the endpoint that are observed in the candidate superset graph (para. 0117, The clustering model type, for example, k-means clusters data to discover similarity or dissimilarity among groups in the data. The regression models such as logistic regression, linear regression, ordinal regression, poisson regression, estimate the relationships among variables. Ensemble machine learning such as random forests, gradient-boosted trees use multiple learning algorithms to obtain better predictive performance. Neural networks are predictive models that capture and represent complex input/output relationships. In linear regression hypothesis, parameters are called features and values are called labels. In neural network hypothesis, parameters are called neurons or layers).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention to combine the teachings of Bolignano, Curtis and Soh by incorporating Soh’s teaching of linear regression to use multiple learning algorithms to obtain better predictive performance.
Regarding claims 3, 10 and 17, the combination of Bolignano and Curtis all of the limitations of claims 2, 9 and 16, respectively, as shown above. Soh further teaches wherein generating the API call graph further comprises: applying parameter tracing to one or more of the set of endpoints to identify the linkages between the plurality of APIs (para. 0085, track the cost of sending specific amount value over periods of time to specific destination countries; para. 0086, 0088 and 0089).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention to combine the teachings of Bolignano, Curtis and Soh by incorporating Soh’s teaching of tracing/tracking to use multiple learning algorithms to track parameter changes.
Regarding claims 4, 11 and 18, the combination of Bolignano and Curtis all of the limitations of claims 3, 10 and 17, respectively, as shown above. Soh further teaches wherein applying the parameter tracing comprises: applying the parameter tracing to input/output parameters of an endpoint of the set of endpoints; or applying the parameter tracing to input/output parameters of a chain of endpoints among the set of endpoints, wherein the input/output parameters of each of the chain of endpoints are correlated (para. 0085, 0086, 0088 and 0089).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention to combine the teachings of Bolignano, Curtis and Soh by incorporating Soh’s teaching of tracing/tracking to use multiple learning algorithms to track parameter changes.
Regarding claims 7 and 14, the combination of Bolignano and Curtis all of the limitations of claims 5 and 12, respectively, as shown above.
The combination of Bolignano and Curtis does not explicitly teach wherein programmatically identifying each of the data fields among the set of data objects comprises: programmatically identifying each of the data fields among the set of data objects using a trained machine learning model. However in an analogous art, Soh teaches wherein programmatically identifying each of the data fields among the set of data objects comprises: programmatically identifying each of the data fields among the set of data objects using a trained machine learning model (para. 0116-0118).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention to combine the teachings of Bolignano, Curtis and Soh by incorporating Soh’s teaching of tracing/tracking to use multiple learning algorithms to track parameter changes.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHU CHUN GAO whose telephone number is (571)270-5999. The examiner can normally be reached on Monday-Thursday 6:00-4:30.
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, ALEXANDER LAGOR can be reached on 571-270-5143. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/S. C. G./Examiner, Art Unit 2437
/ALEXANDER LAGOR/Supervisory Patent Examiner, Art Unit 2437
Prosecution Insights