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 .
DETAILED ACTION
Response to Arguments
Applicant's arguments filed 3/18/2026 have been fully considered, and are persuasive. The previously combination of Firebase in view of Baker, Mehta, and Dawoud fail to show where a “normalized request” is processed in the manner claimed. However, after further search and consideration, a new grounds of rejection is presently made based on a modified interpretation of Baker, now utilizing additional teachings not previously relied upon. While the previously relied upon citations to Baker show processing of control-plane-events, and normalization of the event processing data (e.g., in Baker’s [66], and further discussed in Baker’s [21-22, 26]), Baker elaborates in [68], discussing that alerts can be sent based on “API calls” and not merely based on API execution that has already been performed (as the present arguments assert). Thus Applicant’s arguments on pages 7 – 10 directed to Baker’s consideration of “historical records of actions that has already taken place” such as events “after a request has been processed” cannot be held as persuasive when Baker is considered as a whole, a particularly in light of the discussion in Baker’s [68] regarding consideration of “API calls” and generation of alerts based on said calls. Note that Baker’s discussion of “API calls” appears to be directly analogous to the claimed received “cloud service API request”
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 4, 5, 14, 17, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Firebase (Google Firebase (with line and page numbering added). 'Use the Firestore REST API". https://firebase.google.com/docs/firestore/use-rest-api. 2019 - 2021.) in view of Baker (US-20200204465-A1), Mehta (US-10339303-B2), and Dawoud (US-20190138556-A1).
Regarding claim 1, Firebase shows a method for providing security in cloud-based environments, the method comprising: receiving a cloud service API request intended for a cloud-based service (pg. 1 lines 6-14); determining one or more rules or policies to apply (pg. 1 lines 29-50 and pg. 2 lines 9-14); applying the determined one or more rules or policies to the request (pg. 1 lines 37-40 and 46-50); if all of the rules or policies are passed, transmitting the cloud service API request to the cloud-based service (pg. 2 lines 35-38, 44-46,m and 55-57, pg. 4 lines 23-26, pg. 5 lines 1-12); if one or more of the rules or policies are not passed, blocking the cloud service API request from being transmitted to the cloud-based service (pg. 5 lines 20-22). Firebase, while showing processing received cloud service API requests (Firebase, pg. 1), does not show normalizing the data to a standard format and then utilization of the normalized data. Baker shows normalizing data to a standard format and then utilization of the normalized data ([21-22,26,68], particularly [68]’s discussion regarding alerts sent based on the detection of particular “API calls”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the request treatment of Firebase with the request standardization of Baker in order to improve operational efficacy and simplify data correlation by enabling operations on the data as a whole, despite the date potentially being originated by a wide variety of data sources. The above combination does not show receiving a request at a proxy and where the determining includes determining one or more rules or policies to apply to the request based on a source application of the request. Mehta shows receiving a request at a proxy (Fig. 5 steps 502 – 506 discussing an “interceptor” which acts as a proxy for the API requests) and where the determining includes determining one or more rules or policies to apply to the request based on a source application of the request (Figs. 3, 5A, col. 3 line 49 – col. 4 line 9, col. 8 lines 27-42). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the request treatment of the above combination with the proxy-based request processing of Mehta in order to provide more fine-grained control over the API use allowed, further improving system security and reliability. The above combination does not show where the proxy is configured as an inline forward proxy. Dawoud shows use of a proxy (Fig. 1) configured as an inline (note that an “inline” is interpreted as being synonymous with an “intercepting” proxy based on the term’s industry standard definition, as evidenced by SwitchVPN Blog ("What is a Transparent Proxy". https://switchvpn.net/blog/transparent-proxy/. 2019) on page 1; Dawoud describes the proxy of Fig. 1 and discussed in [21,23] as both a forwarding proxy that performs “intercepting”, as noted in Dawoud’s [26,34,35], and thus this proxy is interpreted as being an inline/intercepting proxy) forward proxy ([23] discussing use of a proxy acting in a forwarding role between an enterprise network and a cloud service, and thus the proxy of Fig. 1 acts as both an inline/intercepting and forwarding proxy).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the request processing of the above combination with the interception and forwarding performed by Dawoud’s proxy in order to ensure that the advantages of the cloud-based services can be leveraged while also ensuring enterprise security is maintained (Dawoud, [21,23]).
Regarding claim 4, the above combination further shows wherein the cloud service API request comprises a create, read, update or delete action (Firebase, pg. 3 lines 31-42, pg. 15 lines 29-46, pg. 28 lines 47-50).
Regarding claim 5, the above combination further shows wherein applying the determined one or more rules to the normalized request (Baker, [21-22,26,68]) comprises, for each of the rules: blocking the cloud service API request if one or more of a provider, host, path, method and action of the normalized request (Baker, [21-22,26,68]) does not match a provider, host, path and method of an associated rule (Firebase, pg. 14 line 40 – pg. 15 line 9, pg. 15 line 55 – pg. 16 line 14).
Regarding claim 14, the above combination further shows wherein the received cloud provider (Baker, [21-22,26,30]) API request (Baker, [39,51, 65-66] and Firebase, pgs.1-2) originated at either a cloud provider or on premise and is destined for a second cloud provider (Baker, [21-22,26,30]). Regarding claim 17, Firebase shows providing security in cloud-based environments, comprising: receiving a cloud service API request intended for a cloud-based service (pg. 1 lines 6-14); determining one or more rules or policies to apply (pg. 1 lines 29-50 and pg. 2 lines 9-14); applying the determined one or more rules or policies to the request (pg. 1 lines 37-40 and 46-50); if all of the rules or policies are passed, transmitting the cloud service API request to the cloud-based service (pg. 2 lines 35-38, 44-46,m and 55-57, pg. 4 lines 23-26, pg. 5 lines 1-12); if one or more of the rules or policies are not passed, blocking the cloud service API request from being transmitted to the cloud-based service (pg. 5 lines 20-22). Firebase, while showing processing received cloud service API requests (Firebase, pg. 1), does not show normalizing the data to a standard format and then utilization of the normalized data. Baker shows normalizing data to a standard format and then utilization of the normalized data ([21-22,26,68], particularly [68]’s discussion regarding alerts sent based on the detection of particular “API calls”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the request treatment of Firebase with the request standardization of Baker in order to improve operational efficacy and simplify data correlation by enabling operations on the data as a whole, despite the date potentially being originated by a wide variety of data sources. The above combination does not show: a security proxy comprising a processor and a memory storing instructions that when executed perform operations, receiving and processing the request at a proxy, and where the determining includes determining one or more rules or policies to apply to the request based on a source application of the request. Mehta shows: a security proxy comprising a processor and a memory storing instructions that when executed perform operations (Fig. 1), receiving and processing the request at the proxy (Fig. 5 steps 502 – 506 discussing an “interceptor” which acts as a proxy for the API requests), and where the determining includes determining one or more rules or policies to apply to the request based on a source application of the request (Figs. 3, 5A, col. 3 line 49 – col. 4 line 9, col. 8 lines 27-42). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the request treatment of the above combination with the proxy-based request processing of Mehta in order to provide more fine-grained control over the API use allowed, further improving system security and reliability. The above combination does not show where the proxy is configured as an inline forward proxy. Dawoud shows use of a proxy (Fig. 1) configured as an inline (note that an “inline” is interpreted as being synonymous with an “intercepting” proxy based on the term’s industry standard definition, as evidenced by SwitchVPN Blog ("What is a Transparent Proxy". https://switchvpn.net/blog/transparent-proxy/. 2019) on page 1; Dawoud describes the proxy of Fig. 1 and discussed in [21,23] as both a forwarding proxy that performs “intercepting”, as noted in Dawoud’s [26,34,35], and thus this proxy is interpreted as being an inline/intercepting proxy) forward proxy ([23] discussing use of a proxy acting in a forwarding role between an enterprise network and a cloud service, and thus the proxy of Fig. 1 acts as both an inline/intercepting and forwarding proxy).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the request processing of the above combination with the interception and forwarding performed by Dawoud’s proxy in order to ensure that the advantages of the cloud-based services can be leveraged while also ensuring enterprise security is maintained (Dawoud, [21,23]).
Regarding claim 18, Firebase shows providing security in cloud-based environments comprising: receiving a cloud service API request intended for a cloud-based service (pg. 1 lines 6-14); determining one or more rules or policies to apply (pg. 1 lines 29-50 and pg. 2 lines 9-14); applying the determined one or more rules or policies to the request (pg. 1 lines 37-40 and 46-50); if all of the rules or policies are passed, transmitting the cloud service API request to the cloud-based service (pg. 2 lines 35-38, 44-46,m and 55-57, pg. 4 lines 23-26, pg. 5 lines 1-12); if one or more of the rules or policies are not passed, blocking the cloud service API request from being transmitted to the cloud-based service (pg. 5 lines 20-22). Firebase, while showing processing received cloud service API requests (Firebase, pg. 1), does not show normalizing the data to a standard format and then utilization of the normalized data. Firebase additionally lacks discussing regarding use of a non-transitory computer readable memory having stored thereon instructions which when executed by a processor of a device cause the device to perform operations. Baker shows normalizing data to a standard format and then utilization of the normalized data ([21-22,26,68], particularly [68]’s discussion regarding alerts sent based on the detection of particular “API calls”), as well as use of a non-transitory computer readable memory having stored thereon instructions which when executed by a processor of a device cause the device to perform operations ([24,76]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the request treatment of Firebase with the request standardization of Baker in order to improve operational efficacy and simplify data correlation by enabling operations on the data as a whole, despite the date potentially being originated by a wide variety of data sources. The above combination does not show receiving a request at a proxy and where the determining includes determining one or more rules or policies to apply to the request based on a source application of the request. Mehta shows receiving a request at a proxy (Fig. 5 steps 502 – 506 discussing an “interceptor” which acts as a proxy for the API requests) and where the determining includes determining one or more rules or policies to apply to the request based on a source application of the request (Figs. 3, 5A, col. 3 line 49 – col. 4 line 9, col. 8 lines 27-42). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the request treatment of the above combination with the proxy-based request processing of Mehta in order to provide more fine-grained control over the API use allowed, further improving system security and reliability.
The above combination does not show where the proxy is configured as an inline forward proxy. Dawoud shows use of a proxy (Fig. 1) configured as an inline (note that an “inline” is interpreted as being synonymous with an “intercepting” proxy based on the term’s industry standard definition, as evidenced by SwitchVPN Blog ("What is a Transparent Proxy". https://switchvpn.net/blog/transparent-proxy/. 2019) on page 1; Dawoud describes the proxy of Fig. 1 and discussed in [21,23] as both a forwarding proxy that performs “intercepting”, as noted in Dawoud’s [26,34,35], and thus this proxy is interpreted as being an inline/intercepting proxy) forward proxy ([23] discussing use of a proxy acting in a forwarding role between an enterprise network and a cloud service, and thus the proxy of Fig. 1 acts as both an inline/intercepting and forwarding proxy).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the request processing of the above combination with the interception and forwarding performed by Dawoud’s proxy in order to ensure that the advantages of the cloud-based services can be leveraged while also ensuring enterprise security is maintained (Dawoud, [21,23]).
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Firebase in view of Baker, Mehta, and Dawoud, as applied to claim 1 above, further in view of Qu (US-6854063-B1).
Regarding claim 2, the above combination shows claim 1, including operation if the one or more of the rules or policies are not passed (Firebase, pg. 5 lines 20-22). The above combination does not show where a request is allowed when an associated flag is set. Qu shows where a request is allowed when an associated flag is set (col. 5 lines 36-49, col. 6 lines 51-62, col. 8 lines 11-15).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the request handling of Qu in order to improve overall system performance (Qu, col. 6 line 58 – col. 7 line 5).
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Firebase in view of Baker, Mehta, Dawoud, and Qu, as applied to claim 2 above, further in view of Skanke (Skanke. "Get started with Azure AD Report Only Mode for Conditional Access". https://msendpointmgr.com/2019/11/04/reportonlymode/. (Year: 2019)).
Regarding claim 3, the above combination shows the cloud service API request (Firebase, pg. 1 lines 6-14). The above combination does not show use of a flag associated with logging the actions associated with a request. Skanke shows use of a flag associated with logging the actions associated with a request (pg. 2 lines 1-8 and pg. 4).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the flag usage of Skanke in order to enable improved testing and evaluation of potential system behavior in additional circumstances, enabling improvements in system reliability and predictability.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Firebase in view of Baker, Mehta, and Dawoud, as applied to claim 1 above, further in view of Zahoor (Zahoor, Ehtesham, et al. "Authorization policies specification and consistency management within multi-cloud environments." Secure IT Systems: 23rd Nordic Conference, NordSec 2018, Oslo, Norway, November 28-30, 2018, Proceedings 23. (Year: 2018)).
Regarding claim 6, the above combination shows wherein applying the determined one or more policies to the normalized request (Baker, [21-22,26,68]) comprises, for each of the policies: applying a policy if the path, method and action of the normalized request (Baker, [21-22,26,68]) matches the path, method, and action of the rules (Firebase, pg. 5 lines 20-49 and Mehta, Fig. 5A, col. 3 line 49 – col. 4 line 9). The above combination does not show consideration of the provider and host. Zahoor shows consideration of the provider and host (pgs. 11-13).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the multi-cloud and provider awareness of Zahoor in order to improve system reliability in multi-cloud environments via better understanding of the different capabilities and functionality provided by different cloud providers and their associated hosts.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Firebase in view of Baker, Mehta, Dawoud,, and Zahoor, as applied to claim 6 above, further in view of Palrecha (US-20180373781-A1).
Regarding claim 7, the above combination shows claim 6, including application of policies associated with the cloud-based service (Firebase, pgs. 1-2, 5). The above combination does not show: use of business rules or governance parameters.
Palrecha shows use of business rules or governance parameters (Figs. 8 – 9, [47,69,101]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the rule consideration of Palrecha in order to better ensure compliance with applicable rules and regulations and improve auditing capabilities of the resultant invention (Palrech, [101]).
Claims 8 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Firebase in view of Baker, Mehta, and Dawoud, as applied to claim 1 above, further in view of Pitre (US-20190098056-A1). Regarding claim 8, the above combination shows claim 1, including a cloud service API request (Firebase, pg. 1). The above combination does not show wherein the request is received from a customer network. Pitre shows wherein the cloud request is received from a customer network ([20,24,39]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the customer and cloud network interoperability supported by Pitre in order to improve system implementation flexibility by enabling resources from multiple locations and deployments to be utilized together, while ensuring policy requirements are adhered to.
Regarding claim 9, the above combination shows claim 1, including a cloud service API request (Firebase, pg. 1). The above combination does not show wherein the cloud request is received from a client's forwarding proxy associated with the customer network. Pitre shows wherein the cloud request is received from a client's forwarding proxy associated with the customer network (discussing where a cloud gate proxy controls API access ([54,120-126] via the client’s network [20,24,32,39,43]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the multi-cloud policy evaluation techniques of Pitre in order to ensure policies are adhered regardless of the implementation locations and environments of utilized tools and frameworks.
Claims 10 – 13 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Firebase in view of Baker, Mehta, and Dawoud, as applied to claim 1 above, further in view of Baset (US-20140101005-A1).
Regarding claim 10, the above combination shows claim 1, including a cloud service API request (Firebase, pg. 1). The above combination does not show providing a notification to identify the blocked request. Baset shows providing a notification to identify the blocked cloud request ([11,30-33]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the notifications of Baset in order to provide improved understating of system behavior and functionality to both administrators and system users.
Regarding claim 11, the above combination shows claim 1. The above combination does not show wherein the one or more rules or policies are stored in one or more associated profiles. Baset shows wherein the one or more rules or policies are stored in one or more associated profiles ([16,24,26,28]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the profile use of Baset in order to simplify storage, retrieval, and other management operations of the rules and policies controlling system behavior and operations.
Regarding claim 12, the above combination further shows wherein each of the profiles is associated with an identifier, wherein the received cloud service API request (Firebase, pg. 1) is associated with a respective identifier used in determining the rules or policies in profiles to be applied to the cloud service API (Firebase, pg. 1) request (Baset, [22,24,28-33]).
Regarding claim 13, the above combination further shows wherein the identifier is associated with a user or application (Firebase, pg. 27 lines 23-25 and 44-51).
Regarding claim 15, the above combination further shows wherein the received cloud service API request (Firebase, pg. 1, and Baker, [21-22,26,30,65-66]) is received from either a cloud provider or on premise via a client's forwarding proxy (Baker, [[21-22,26-27]).
Claim 16 rejected under 35 U.S.C. 103 as being unpatentable over Firebase in view of Baker, Mehta, and Dawoud, as applied to claim 1 above, further in view of Findeisen (US-9009729-B2).
Regarding claim 16, the above combination shows the cloud service API request (Firebase, pg. 1). The above combination does not show injecting metadata into the cloud request to facilitate tracking of an associated implementation. Findeisen shows injecting metadata into the cloud request to facilitate tracking of an associated implementation (col. 1 lines 57-64, col. 2 lines 5-22, col. 4 lines 15-38 and 51-59).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the tracking functionality of Findeisen in order to improve performance tracking across environments associated with fulfilling and servicing the received requests (Findeisen, col. 2 lines 14-22).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN M MACILWINEN whose telephone number is (571)272-9686. The examiner can normally be reached Monday - Friday, 9:00 - 5:00.
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, Glenton B Burgess can be reached at (571) 272 - 3949. 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.
JOHN MACILWINEN
Primary Examiner
Art Unit 2442
/JOHN M MACILWINEN/Primary Examiner, Art Unit 2454
Prosecution Insights