DETAILED ACTION
Examiner acknowledges receipt of Applicant’s amendment filed on 12/05/2025
Claims 1, 10, and 18 are currently amended
Claims 1-4, 6-13, 15-20, and 22-25 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 Arguments
Applicant’s arguments filed 12/05/2025, with respect to the rejections of claims 1-4, 6-13, 15-20, and 22-25 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 combination of Wu, Grinstein, Almutairi, and Ngo, in addition to a newly applied reference from Wardell et al. (US 20170331791 A1), hereinafter Wardell. Specifically, Wardell teaches the newly added limitations “a source intercloud service gateway disposed in a first service tenancy” and “a target intercloud service gateway disposed in a second service tenancy”. Further, a newly applied reference from Tripp et al. (US 20220038449 A1), hereinafter Tripp, will be relied upon herein for rejections of limitations previously relying upon teachings from Abraham.
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.
Claims 1-4, 6, 7, 10-13, 15, 16, 18-20, and 22-25 are rejected under 35 U.S.C. 103 as being unpatentable over Wu et al. (Wu, Y., Suhendra, V., Guo, H. (2012). A Gateway-based Access Control Scheme for Collaborative Clouds. ICIMP 2012: The Seventh International Conference on Internet Monitoring and Protection. ICIMP 2012, 54-60.), hereinafter Wu, in view of Grinstein et al. (US 20220038544 A1), hereinafter Grinstein, Almutairi et al. (Almutairi, A., Sarfraz, M., Basalamah, S., Aref, W. G., & Ghafoor, A. (2012). A distributed access control architecture for cloud computing. IEEE Software, 29(2), 36–44.), hereinafter Almutairi, Wardell et al. (US 20170331791 A1), hereinafter Wardell, and Tripp et al. (US 20220038449 A1), hereinafter Tripp.
Regarding Claim 1:
Wu teaches a method comprising: generating, [by a compute instance executed in a source cloud environment], a request to use a service provided in a target cloud environment (Wu – P. 57, Col. 1: Access to Inter-cloud Resources: In the VPC diagram shown in Figure 4, the gateway can represent any user within its enterprise to send and receive data across clouds. When a user requests a service or resource from the collaborative enterprise, the gateway is authorized to complete the request on the user’s behalf) the source cloud environment being different than the target cloud environment (Wu – p. 57, Col. 1: a VPC gateway should translate the access request from its local user to a standard format e.g. SAML (Security Assertion Markup Language)) so that the gateway in the target enterprise can enforce the access control. For instance, if the user requests access to the resources of a peer cloud, the gateway in the user’s enterprise will translate the request into another format that is compliant with the target enterprise, so that the request can be handled as a local request by the target enterprise) and transmitting the request from the source cloud environment to the target cloud environment (Wu – P. 57, Col. 1: The gateway G1 translates the request into a “standard” Collaborative Clouds request format (e.g., SAML format), replaces the requestor with an authorized identity, and signs on the translated request. Then it sends the request to the target gateway G2) via a source intercloud service gateway disposed in [a first service tenancy in] the source cloud environment (Wu – Figure 4: illustrates access request from a local organization to a separate target organization. G1 is the source gateway) and a target intercloud service gateway disposed in [a second service tenancy in] the target cloud environment (Wu – Figure 4: illustrates access request from a local organization to a separate target organization. G2 is the target gateway), the transmitting including: sending [by the compute instance], the request to the source intercloud service gateway (Wu – P. 57, Col. 1: When a user wants to access the resource (or service) of one collaborative enterprise, he sends a request to the local authenticator A1. After the local authenticator A1 verifies (user) authenticity, it sends the request to the gateway G1; and P. 56, Figure 2: illustrates that authentication is performed within the Data security unit, which is a component of the security gateway) wherein the source intercloud service gateway: (a) modifies the request to generate a modified request (Wu – P. 57, Col. 1: The gateway G1 translates the request into a “standard” Collaborative Clouds request format (e.g., SAML format), replaces the requestor with an authorized identity, and signs on the translated request) at least by removing a credential from the request (Wu – P. 58, Col. 2: The user’s home VPC gateway processes the request before sending it through the channel, replacing the requestor identity with a pseudo user name to achieve anonymity) and (b) transmits the modified request [including the access role] to the target intercloud service gateway (Wu – P. 57, Col. 1: Then (gateway G1) sends the request to the target gateway G2), and causing, by the target intercloud service gateway, the service to be executed in the target cloud environment (Wu – P. 57, Col. 1-2: The target gateway G2 verifies the request based on the signature of the sending gateway G1 and translates the “standard” request format into its own request format. Then it sends the request to its own authenticator A2. Once A2 authenticates the request, the user can access the resource or service); and based on the modified request (Wu – P.57, Col. 1-2: The target gateway G2 verifies the request based on the signature of the sending gateway G1 and translates the “standard” request format into its own request format. Then it sends the request to its own authenticator A2. Once A2 authenticates the request, the user can access the resource or service).
Wu does not expressly teach generating, by a compute instance executed in a source cloud environment, a request; sending, by the compute instance, the request; and adding an access role in the target cloud environment associated with the compute instance; wherein the source cloud environment is provided by a first cloud service provider and the source cloud environment provides a first plurality of cloud services, and the target cloud environment is provided by a second cloud service provider and the target cloud environment provides a second plurality of services, wherein the second cloud service provider is different than the first cloud service provider.
However, Grinstein teaches generating, by a compute instance executed in a source cloud environment, a request (Grinstein – Paragraph [0006]: an instance metadata service request sent by a workload operating on the first execution environment; Examiner’s Comment: the generation of the request by the workload is implicit) to use a service provided in a target cloud environment the source cloud environment being different than the target cloud environment (Grinstein – Paragraph [0001]: a system and method for handling requests from workloads in a first cloud computing platform and providing credentials for the workloads to seamlessly access cloud services on a second, different, cloud platform); sending, by the compute instance, the request (Grinstein – Paragraph [0006]: an instance metadata service request sent by a workload operating on the first execution environment); [and adding] an access role in the target cloud environment associated with the compute instance (Grinstein – Paragraph [0025]: The WCS 102 maps an identity associated with the workload 214 to a logical identity that is acceptable on another execution environment, such as the second execution environment 104b, so that the workload 214 can access a second cloud service 222b on the second execution environment 104b; and Paragraph [0029]: The logical identity or identity construct may have different structures or be referenced by different names in different cloud platforms, such as a “role” on AWS, a “service account” on GCP and a “managed identity” on Microsoft Azure); wherein the source cloud environment is provided by a first cloud service provider (Grinstein – Paragraph [0019]: The different execution environments 104a . . . 104n may be execution environments of different cloud service providers, and may have different operational formats such as different communications formats, data structures to accessing data or operating within the execution environment, different metadata access formats, different authentication structures, and the like) and the source cloud environment provides a first plurality of cloud services (Grinstein – Paragraph [0017]: Embodiments of the present disclosure are directed to providing a workload control system that allows a workload deployed on a cloud platform execution environment to access features, services, data, or other software deployed or available on another cloud platform) , and the target cloud environment is provided by a second cloud service provider (Grinstein – Paragraph [0019]: The different execution environments 104a . . . 104n may be execution environments of different cloud service providers, and may have different operational formats such as different communications formats, data structures to accessing data or operating within the execution environment, different metadata access formats, different authentication structures, and the like) and the target cloud environment provides a second plurality of services (Grinstein – Paragraph [0017]: Embodiments of the present disclosure are directed to providing a workload control system that allows a workload deployed on a cloud platform execution environment to access features, services, data, or other software deployed or available on another cloud platform), wherein the second cloud service provider is different than the first cloud service provider Grinstein – Paragraph [0019]: The different execution environments 104a . . . 104n may be execution environments of different cloud service providers).
It would have been obvious before the effective filing date of the claimed invention to one of ordinary skill in the art to modify Wu, further incorporating Grinstein to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Grinstein’s teachings to implement APIs of one execution environment to associate a requesting workload with an access role applicable to another execution environment of a different cloud provider in order to fulfill a request for an intercloud resource/service into Wu’s teachings of security gateways residing in participating clouds to facilitate and fulfill requests for users to access services offered on separate cloud platforms. This combination of the functionality taught by Grinstein – providing intercloud access to resources and services – and the structure taught by Wu – a gateway established at each collaborating cloud environment – would result in the capability for cloud workloads to make requests for and receive appropriate levels of access to services provided in different cloud environments.
The combination of Wu and Grinstein does not expressly teach and adding an access role in the target cloud environment associated with the compute instance; and the modified request including the access role.
However, Almutairi teaches and adding an access role in the target cloud environment associated with the compute instance (Almutairi – P. 42, Col. 3: If X requires a remote resource, the participating SLA assigns it a mapped role (say, Ry); and Figure 6: Flow of request via the access control module and virtual resource manager across multiple clouds; and P. 43, Col. 1: In scenario B.2, the local SaaS needs to access virtual resources managed by CP2’s PaaS and IaaS. Assuming cross-layered SLA architecture, the local SaaS’s VRM generates the authorization request Ry, execute, PaaSCP2, CompInstx(isolation = 1), which is then forwarded to CP2’s PaaS’s ACM through the SLA); and the modified request including the access role (Almutairi – P. 39, Figure 3: SLA architecture including Role Mapper; and P. 39 Col. 2, P 40, Col. 1: If the request contains an authenticating credential, the credential evaluator assigns a user a local role based on the user-to-role assignment rules stored in the RBAC policy base. The process of user-to-role assignment re-quires input from the context evaluator regarding contextual constraints. If the request contains an authorization credential, the credential evaluator assesses if the role corresponds to a local role. If not, the implication is that this is a single-sign-on request and requires role mapping by a relevant SLA. Subsequently, the user acquires the privileges of the locally assigned role or of a mapped role in a remote cloud).
It would have been obvious before the effective filing date of the claimed invention to one of ordinary skill in the art to modify Wu and Grinstein, further incorporating Almutairi to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Almutairi’s teachings of modifying an intercloud service request by adding a role defining a user’s access privileges on a foreign cloud into Wu and Grinstein’s teachings of security gateways residing in participating clouds to facilitate and fulfill requests for users to access services offered on separate cloud platforms. This teaching enhances Grinstein’s teaching by injecting a role directly into the service request for a more streamlined authorization process in facilitating access to intercloud services.
The combination of Wu, Grinstein, and Almutairi does not expressly teach a source intercloud service gateway disposed in a first service tenancy in the source cloud environment and a target intercloud service gateway disposed in a second service tenancy in the target cloud environment.
However, Wardell teaches a source intercloud service gateway disposed in a first service tenancy in the source cloud environment and a target intercloud service gateway disposed in a second service tenancy in the target cloud environment (Wardell – Paragraph [0118]: In one embodiment, IDCS implements a “Cloud Gate” in the web tier. In one embodiment, Cloud Gate is implemented by a web server plugin that enables web applications to externalize user SSO to an identity management system (e.g., IDCS), similar to WebGate or WebAgent technologies that work with enterprise IDM stacks. In one embodiment, Cloud Gate acts as a security gatekeeper that secures access to IDCS APIs. In one embodiment, Cloud Gate is implemented by a web/proxy server plugin that provides a web PEP for protecting HTTP resources based on OAuth. In one embodiment, Cloud Gate also performs authentication (e.g., OAuth authentication); and Paragraph [0119]: In one embodiment, Cloud Gate may be deployed to protect a single-tenant application or a multi-tenant application, and may be deployed in proxy-mode front-ending different types of applications. In one embodiment, Cloud Gate supports single-tenant and multi-tenant applications by using respective default configurations for <Tenant> (represents what tenant owns the Cloud Gate instance) and <Host Identifier> (represents what application is being accessed). In one embodiment, local configurations specify default values for these artifacts, and may be overwritten on a per-request basis via HTTP headers supplied by the routing tier. For example, for a multi-tenant application, <Tenant> defines Cloud Gate's tenancy and is used to construct IDCS service URLs when contacting an IDCS server, and may be overwritten on a per-request basis by an optional X-RESOURCE-IDENTITY-DOMAIN-NAME header including <tenant-name> (e.g., “acme”); and Paragraph [0120]: In one embodiment, one instance of Cloud Gate is deployed for each tenant).
It would have been obvious before the effective filing date of the claimed invention to one of ordinary skill in the art to modify Wu, Grinstein, and Almutairi, further incorporating Wardell to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Wardell’s teachings to deploy per-tenant Cloud Gates to facilitate and authenticate requests to access resources between multiple tenancies into Wu, Grinstein, and Almutairi’s teachings of security gateways residing in participating clouds to facilitate and fulfill requests for users to access services offered on separate cloud platforms. Wardell’s per-tenant Cloud Gates address a known need for tenant-level policy customization and identity and access management. Thus, the addition of this aspect to the combination of Wu, Grinstein, and Almutairi provides the obvious benefit of inter-tenant resource access and simultaneous protection.
The combination of Wu, Grinstein, Almutairi, and Wardell does not expressly teach and wherein the source intercloud service gateway disposed in the source cloud environment and the target intercloud service gateway disposed in the target cloud environment are deployed and being controlled by a control plane of the source cloud environment.
However, Tripp teaches and wherein the source intercloud service [gateway] disposed in the source cloud environment and the target intercloud service [gateway] disposed in the target cloud environment are deployed and being controlled by a control plane of the source cloud environment (Tripp – Paragraph [0033], [0039], [0040]: Embodiments described herein further seek to support one or more of the following features … Per tenant inbound/outbound authentication via industry standards (e.g., Oauth2, OIDC with Proof Key for Code Exchange (PKCE), SAML, and LDAP); and Per tenant local users, groups, Single-Sign-On (SSO) and authorization policies; and Paragraph [0045]: As used herein, a “unified Identity and Access Management control plane” generally refers to APIs and associated services that support integration of multiple internal and/or external services, potentially using differing IAM protocols and/or schemes, into a cohesive model. In one embodiment, multiple service integrations are supported by enabling internal and/or external services to plugin to the unified IAM control plane by exposing appropriate APIs (e.g., for retrieval of resources, roles and permissions) and making use of those of a rich set of APIs of the unified IAM control plane as appropriate for the desired level of service integration (e.g., direct integration, brokered change events, and authentication level enforcement); and Paragraph [0051]: implementation of a unified Identity and Access Management (IAM) control plane by a Managed Service Provider (MSP) 230).
It would have been obvious before the effective filing date of the claimed invention to one of ordinary skill in the art to modify Wu, Grinstein, Almutairi, and Wardell, further incorporating Tripp to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Tripp’s unified IAM control plane for providing resources, roles, and permissions of various external cloud environments from a single source provider into Wu, Grinstein, Almutairi, and Wardell’s method for secure and private service access across multiple cloud environments offered by different cloud service providers. Tripp’s explicit teaching of unified IAM control plane enabling cross-cloud collaboration demonstrates a known technique in the art for seamless provision of multi-cloud resources from a single source point. This consideration naturally combines with the teachings of Wu, Grinstein, Almutairi, and Wardell, all applied to comparable scenarios for facilitating intercloud processes.
Regarding Claim 2:
Wu, Grinstein, Almutairi, Wardell, and Tripp combine to teach the method of claim 1.
Wu further teaches sending, [by the compute instance], the request to the source intercloud service gateway disposed in the source cloud environment (Wu – P. 57, Col. 1: When a user wants to access the resource (or service) of one collaborative enterprise, he sends a request to the local authenticator A1 along with his authentication information (e.g., credential, identity/role/attribute) … After the local authenticator A1 verifies (user) authenticity, it sends the request to the gateway G1; and P. 56, Figure 2: illustrates that authentication is performed within the Data security unit, which is component of the security gateway) the request including an identity principal [associated with the compute instance] (Wu – P. 57, Col. 1: When a user wants to access the resource (or service) of one collaborative enterprise, he sends a request to the local authenticator A1 along with his authentication information (e.g., credential, identity/role/attribute)) and validating, by the source intercloud service gateway, the identity principal of the compute instance (Wu – P. 57, Col. 1: after the local authenticator A1 verifies their authenticity, it sends the request to the gateway G1; and P. 56, Figure 2: illustrates that authentication is performed within the Data security unit, which is a component of the security gateway).
Grinstein further teaches sending, by the compute instance, the request (Grinstein – Paragraph [0006]: an instance metadata service request sent by a workload operating on the first execution environment); the request including an identity principal associated with the compute instance (Grinstein – Paragraph [0058]: the WCS may track the canonical identity of the workload and may determine the canonical identity of the workload from requests made to the WCS on behalf of the workload).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 3:
Wu, Grinstein, Almutairi, Wardell, and Tripp combine to teach the method of claim 2.
Grinstein further teaches wherein validating the identity principal includes verifying whether the compute instance is permitted to access the service in the target cloud environment (Grinstein – Paragraph [0047]: The credentials may represent a local identity with an associated logical authorization policy that has an associated local authorization policy. The retrieved credentials, being associated with a local authorization policy that grants sufficient authorization permissions to permit the workload 214 to access the target execution environment/cloud platform).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 4:
Wu, Grinstein, Almutairi, Wardell, and Tripp combine to teach the method of claim 2.
Almutairi further teaches further comprising: responsive to the identity principal being successfully validated, obtaining, by the source intercloud service gateway, the access role [associated with the compute instance] (Almutairi et al. – P. 39, Col. 3: If the request contains an authenticating credential, the credential evaluator assigns a user a local role based on the user-to-role assignment rules stored in the RBAC policy base) from preconfigured information stored in the source cloud environment (Almutairi et al. – P. 39, Col. 3: local role based on the user-to-role assignment rules stored in the RBAC policy base).
Grinstein further teaches the access role associated with the compute instance ((Grinstein – Paragraph [0025]: The WCS 102 maps an identity associated with the workload 214 to a logical identity that is acceptable on another execution environment; and Paragraph [0029]: The logical identity or identity construct may have different structures or be referenced by different names in different cloud platforms, such as a “role” on AWS, a “service account” on GCP and a “managed identity” on Microsoft Azure).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 6:
Wu, Grinstein, Almutairi, Wardell, and Tripp combine to teach the method of claim 1.
Wu further teaches wherein the source intercloud service gateway is disposed in a first data plane of the source cloud environment and the target intercloud service gateway is disposed in a second data plane of the target cloud environment (Wu – P. 55, Figure 1: Gateway-based architecture of virtual private cloud, illustrating gateways present within each collaborating environment), the source intercloud service gateway being communicatively coupled to the target intercloud service gateway via a trusted communication channel (Wu – P. 57, Col. 2: To guarantee the security level defined by the enterprises, the VPC gateways should ensure end-to-end security. Loosely speaking, both gateways should create a secure channel for any information exchange between them).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 7:
Wu, Grinstein, Almutairi, Wardell, and Tripp combine to teach the method of claim 1.
Grinstein further teaches further comprising: extracting, by the target intercloud service gateway, the access role associated with the compute instance from the modified request (Grinstein – Paragraph [0047]: The retrieved credentials, being associated with a local authorization policy that grants sufficient authorization permissions to permit the workload 214 to access the target execution environment/cloud platform) and obtaining, by the target intercloud service gateway, a token associated with the access role from a management service included in the target cloud environment (Grinstein – Paragraph [0047]: the request to the STS 220b acts as an “assumeRole” request, which is an operation that requests a token representing a particular identity; The STS token is returned to the UIMS 218 and the UIMS 218, in turn, returns the received token to the workload 214).
The motivation to combine the arts is the same as that of Claim 1, with the addition that Grinstein teaches implementation of an access token as a security feature of the method.
Regarding Claim 10:
Wu teaches one or more computer readable non-transitory media storing specific computer-executable instructions that, when executed by a processor, cause a computer system (Wu – P. 57, Col. 2: Each cloud is constructed with computers supporting BIOS virtualization … Examiner’s Comment: computers having the memory/storage to store instruction codes for execution by a processor(s)) to at least: generating, [by a compute instance executed] in a source cloud environment, a request to use a service provided in a target cloud environment (Wu – P. 57, Col. 1: Access to Inter-cloud Resources: In the VPC diagram shown in Figure 4, the gateway can represent any user within its enterprise to send and receive data across clouds. When a user requests a service or resource from the collaborative enterprise, the gateway is authorized to complete the request on the user’s behalf) the source cloud environment being different than the target cloud environment (Wu – p. 57, Col. 1: a VPC gateway should translate the access request from its local user to a standard format, e.g. SAML (Security Assertion Markup Language)) so that the gateway in the target enterprise can enforce the access control. For instance, if the user requests access to the resources of a peer cloud, the gateway in the user’s enterprise will translate the request into another format that is compliant with the target enterprise, so that the request can be handled as a local request by the target enterprise) and transmitting the request from the source cloud environment to the target cloud environment (Wu – P. 57, Col. 1: The gateway G1 translates the request into a “standard” Collaborative Clouds request format (e.g., SAML format), replaces the requestor with an authorized identity, and signs on the translated request. Then it sends the request to the target gateway G2) via a source intercloud service gateway disposed in [a first service tenancy in] the source cloud environment (Wu – Figure 4: illustrates access request from a local organization to a separate target organization. G1 is the source gateway) and a target intercloud service gateway disposed in [a second service tenancy in] the target cloud environment (Wu – Figure 4: illustrates access request from a local organization to a separate target organization. G2 is the target gateway), the transmitting including: sending, [by the compute instance], the request to the source intercloud service gateway (Wu – P. 57, Col. 1: When a user wants to access the resource (or service) of one collaborative enterprise, he sends a request to the local authenticator A1. After the local authenticator A1 verifies (user) authenticity, it sends the request to the gateway G1; and P. 56, Figure 2: illustrates that authentication is performed within the Data security unit, which is a component of the security gateway) wherein the source intercloud service gateway: (a) modifies the request to generate a modified request (Wu – P. 57, Col. 1: The gateway G1 translates the request into a “standard” Collaborative Clouds request format (e.g., SAML format), replaces the requestor with an authorized identity, and signs on the translated request) at least by removing a credential from the request (Wu – P. 58, Col. 2: The user’s home VPC gateway processes the request before sending it through the channel, replacing the requestor identity with a pseudo user name to achieve anonymity) and (b) transmits the modified request [including the access role] to the target intercloud service gateway (Wu – P. 57, Col. 1: Then (gateway G1) sends the request to the target gateway G2), and causing, by the target intercloud service gateway, the service to be executed in the target cloud environment (Wu – P. 57, Col. 1-2: The target gateway G2 verifies the request based on the signature of the sending gateway G1 and translates the “standard” request format into its own request format. Then it sends the request to its own authenticator A2. Once A2 authenticates the request, the user can access the resource or service); and based on the modified request (Wu – P.57, Col. 1-2: The target gateway G2 verifies the request based on the signature of the sending gateway G1 and translates the “standard” request format into its own request format. Then it sends the request to its own authenticator A2. Once A2 authenticates the request, the user can access the resource or service).
Wu does not expressly teach generating, by a compute instance executed in a source cloud environment, a request; sending, by the compute instance, the request; and adding an access role in the target cloud environment associated with the compute instance; wherein the source cloud environment is provided by a first cloud service provider and the source cloud environment provides a first plurality of cloud services, and the target cloud environment is provided by a second cloud service provider and the target cloud environment provides a second plurality of services, wherein the second cloud service provider is different than the first cloud service provider.
However, Grinstein teaches one or more computer readable non-transitory media storing specific computer-executable instructions that, when executed by a processor, cause a computer system to at least (Grinstein et al. – Paragraph [0004]: An embodiment system may have a non-transitory computer readable medium having a program stored thereon for execution by a computer processor, the program including instructions): generating, by a compute instance executed in a source cloud environment, a request (Grinstein – Paragraph [0006]: an instance metadata service request sent by a workload operating on the first execution environment; Examiner’s Comment: the generation of the request by the workload is implicit) to use a service provided in a target cloud environment the source cloud environment being different than the target cloud environment (Grinstein – Paragraph [0001]: a system and method for handling requests from workloads in a first cloud computing platform and providing credentials for the workloads to seamlessly access cloud services on a second, different, cloud platform); [and adding] an access role in the target cloud environment associated with the compute instance (Grinstein – Paragraph [0025]: The WCS 102 maps an identity associated with the workload 214 to a logical identity that is acceptable on another execution environment, such as the second execution environment 104b, so that the workload 214 can access a second cloud service 222b on the second execution environment 104b; and Paragraph [0029]: The logical identity or identity construct may have different structures or be referenced by different names in different cloud platforms, such as a “role” on AWS, a “service account” on GCP and a “managed identity” on Microsoft Azure); wherein the source cloud environment is provided by a first cloud service provider (Grinstein – Paragraph [0019]: The different execution environments 104a . . . 104n may be execution environments of different cloud service providers, and may have different operational formats such as different communications formats, data structures to accessing data or operating within the execution environment, different metadata access formats, different authentication structures, and the like) and the source cloud environment provides a first plurality of cloud services (Grinstein – Paragraph [0017]: Embodiments of the present disclosure are directed to providing a workload control system that allows a workload deployed on a cloud platform execution environment to access features, services, data, or other software deployed or available on another cloud platform) , and the target cloud environment is provided by a second cloud service provider (Grinstein – Paragraph [0019]: The different execution environments 104a . . . 104n may be execution environments of different cloud service providers, and may have different operational formats such as different communications formats, data structures to accessing data or operating within the execution environment, different metadata access formats, different authentication structures, and the like) and the target cloud environment provides a second plurality of services (Grinstein – Paragraph [0017]: Embodiments of the present disclosure are directed to providing a workload control system that allows a workload deployed on a cloud platform execution environment to access features, services, data, or other software deployed or available on another cloud platform), wherein the second cloud service provider is different than the first cloud service provider (Grinstein – Paragraph [0019]: The different execution environments 104a . . . 104n may be execution environments of different cloud service providers).
It would have been obvious before the effective filing date of the claimed invention to one of ordinary skill in the art to modify Wu, further incorporating Grinstein to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Grinstein’s teachings to implement APIs of one execution environment to associate a requesting workload with an access role applicable to another execution environment of a different cloud provider in order to fulfill a request for an intercloud resource/service into Wu’s executable instructions to cause security gateways residing in participating clouds to facilitate and fulfill requests for users to access services offered on separate cloud platforms. This combination of the functionality taught by Grinstein – providing intercloud access to resources and services – and the structure taught by Wu – a gateway established at each collaborating cloud environment – would result in a storable, reusable process for cloud workloads to make requests for and receive appropriate levels of access to services provided in different cloud environments.
The combination of Wu and Grinstein does not expressly teach and adding an access role in the target cloud environment associated with the compute instance; and the modified request including the access role.
However, Almutairi teaches and adding an access role in the target cloud environment associated with the compute instance (Almutairi – P. 42, Col. 3: If X requires a remote resource, the participating SLA assigns it a mapped role (say, Ry); and Figure 6: Flow of request via the access control module and virtual resource manager across multiple clouds; and P. 43, Col. 1: In scenario B.2, the local SaaS needs to access virtual resources managed by CP2’s PaaS and IaaS. Assuming cross-layered SLA architecture, the local SaaS’s VRM generates the authorization request Ry, execute, PaaSCP2, CompInstx(isolation = 1), which is then forwarded to CP2’s PaaS’s ACM through the SLA); and the modified request including the access role (Almutairi – P. 39, Figure 3: SLA architecture including Role Mapper; and P. 39 Col. 2, P 40, Col. 1: If the request contains an authenticating credential, the credential evaluator assigns a user a local role based on the user-to-role assignment rules stored in the RBAC policy base. The process of user-to-role assignment re- quires input from the context evaluator regarding contextual constraints. If the request contains an authorization credential, the credential evaluator assesses if the role corresponds to a local role. If not, the implication is that this is a single-sign-on request and requires role mapping by a relevant SLA. Subsequently, the user acquires the privileges of the locally assigned role or of a mapped role in a remote cloud).
It would have been obvious before the effective filing date of the claimed invention to one of ordinary skill in the art to modify Wu and Grinstein, further incorporating Almutairi to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Almutairi’s teachings of modifying an intercloud service request by adding a role defining a user’s access privileges on a foreign cloud into Wu and Grinstein’s teachings of security gateways residing in participating clouds to facilitate and fulfill requests for users to access services offered on separate cloud platforms. This teaching enhances Grinstein’s teaching by injecting a role directly into the service request for a more streamlined authorization process in facilitating access to intercloud services.
The combination of Wu, Grinstein, and Almutairi does not expressly teach a source intercloud service gateway disposed in a first service tenancy in the source cloud environment and a target intercloud service gateway disposed in a second service tenancy in the target cloud environment.
However, Wardell teaches a source intercloud service gateway disposed in a first service tenancy in the source cloud environment and a target intercloud service gateway disposed in a second service tenancy in the target cloud environment (Wardell – Paragraph [0118]: In one embodiment, IDCS implements a “Cloud Gate” in the web tier. In one embodiment, Cloud Gate is implemented by a web server plugin that enables web applications to externalize user SSO to an identity management system (e.g., IDCS), similar to WebGate or WebAgent technologies that work with enterprise IDM stacks. In one embodiment, Cloud Gate acts as a security gatekeeper that secures access to IDCS APIs. In one embodiment, Cloud Gate is implemented by a web/proxy server plugin that provides a web PEP for protecting HTTP resources based on OAuth. In one embodiment, Cloud Gate also performs authentication (e.g., OAuth authentication); and Paragraph [0119]: In one embodiment, Cloud Gate may be deployed to protect a single-tenant application or a multi-tenant application, and may be deployed in proxy-mode front-ending different types of applications. In one embodiment, Cloud Gate supports single-tenant and multi-tenant applications by using respective default configurations for <Tenant> (represents what tenant owns the Cloud Gate instance) and <Host Identifier> (represents what application is being accessed). In one embodiment, local configurations specify default values for these artifacts, and may be overwritten on a per-request basis via HTTP headers supplied by the routing tier. For example, for a multi-tenant application, <Tenant> defines Cloud Gate's tenancy and is used to construct IDCS service URLs when contacting an IDCS server, and may be overwritten on a per-request basis by an optional X-RESOURCE-IDENTITY-DOMAIN-NAME header including <tenant-name> (e.g., “acme”); and Paragraph [0120]: In one embodiment, one instance of Cloud Gate is deployed for each tenant).
It would have been obvious before the effective filing date of the claimed invention to one of ordinary skill in the art to modify Wu, Grinstein, and Almutairi, further incorporating Wardell to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Wardell’s teachings to deploy per-tenant Cloud Gates to facilitate and authenticate requests to access resources between multiple tenancies into Wu, Grinstein, and Almutairi’s teachings of security gateways residing in participating clouds to facilitate and fulfill requests for users to access services offered on separate cloud platforms. Wardell’s per-tenant Cloud Gates address a known need for tenant-level policy customization and identity and access management. Thus, the addition of this aspect to the combination of Wu, Grinstein, and Almutairi provides the obvious benefit of inter-tenant resource access and simultaneous protection.
The combination of Wu, Grinstein, Almutairi, and Wardell does not expressly teach and wherein the source intercloud service gateway disposed in the source cloud environment and the target intercloud service gateway disposed in the target cloud environment are deployed and being controlled by a control plane of the source cloud environment.
However, Tripp teaches and wherein the source intercloud service [gateway] disposed in the source cloud environment and the target intercloud service [gateway] disposed in the target cloud environment are deployed and being controlled by a control plane of the source cloud environment (Tripp – Paragraph [0033], [0039], [0040]: Embodiments described herein further seek to support one or more of the following features … Per tenant inbound/outbound authentication via industry standards (e.g., Oauth2, OIDC with Proof Key for Code Exchange (PKCE), SAML, and LDAP); and Per tenant local users, groups, Single-Sign-On (SSO) and authorization policies; and Paragraph [0045]: As used herein, a “unified Identity and Access Management control plane” generally refers to APIs and associated services that support integration of multiple internal and/or external services, potentially using differing IAM protocols and/or schemes, into a cohesive model. In one embodiment, multiple service integrations are supported by enabling internal and/or external services to plugin to the unified IAM control plane by exposing appropriate APIs (e.g., for retrieval of resources, roles and permissions) and making use of those of a rich set of APIs of the unified IAM control plane as appropriate for the desired level of service integration (e.g., direct integration, brokered change events, and authentication level enforcement); and Paragraph [0051]: implementation of a unified Identity and Access Management (IAM) control plane by a Managed Service Provider (MSP) 230).
It would have been obvious before the effective filing date of the claimed invention to one of ordinary skill in the art to modify Wu, Grinstein, Almutairi, and Wardell, further incorporating Tripp to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Tripp’s unified IAM control plane for providing resources, roles, and permissions of various external cloud environments from a single source provider into Wu, Grinstein, Almutairi, and Wardell’s method for secure and private service access across multiple cloud environments offered by different cloud service providers. Tripp’s explicit teaching of unified IAM control plane enabling cross-cloud collaboration demonstrates a known technique in the art for seamless provision of multi-cloud resources from a single source point. This consideration naturally combines with the teachings of Wu, Grinstein, Almutairi, and Wardell, all applied to comparable scenarios for facilitating intercloud processes.
Regarding Claim 11:
Wu, Grinstein, Almutairi, Wardell, and Tripp combine to teach the one or more computer readable non-transitory media storing specific computer-executable instructions of claim 10.
Wu further teaches wherein the computer system is further configured for: sending [by the compute instance], the request to the source intercloud service gateway disposed in the source cloud environment (Wu – P. 57, Col. 1: When a user wants to access the resource (or service) of one collaborative enterprise, he sends a request to the local authenticator A1 along with his authentication information (e.g., credential, identity/role/attribute) … After the local authenticator A1 verifies (user) authenticity, it sends the request to the gateway G1; and P. 56, Figure 2: illustrates that authentication is performed within the Data security unit, which is component of the security gateway) the request including an identity principal [associated with the compute instance] (Wu – P. 57, Col. 1: When a user wants to access the resource (or service) of one collaborative enterprise, he sends a request to the local authenticator A1 along with his authentication information (e.g., credential, identity/role/attribute)); and validating, by the source intercloud service gateway, the identity principal of the compute instance (Wu – P. 57, Col. 1: after the local authenticator A1 verifies their authenticity, it sends the request to the gateway G1; and P. 56, Figure 2: illustrates that authentication is performed within the Data security unit, which is a component of the security gateway).
Grinstein further teaches wherein the computer system is further configured for: sending by the compute instance, the request (Grinstein – Paragraph [0006]: an instance metadata service request sent by a workload operating on the first execution environment); the request including an identity principal associated with the compute instance (Grinstein – Paragraph [0058]: the WCS may track the canonical identity of the workload and may determine the canonical identity of the workload from requests made to the WCS on behalf of the workload).
The motivation to combine the arts is the same as that of claim 10.
Regarding Claim 12:
Wu, Grinstein, Almutairi, Wardell, and Tripp combine to teach the one or more computer readable non-transitory media storing specific computer-executable instructions of claim 11.
Grinstein further teaches wherein validating the identity principal includes verifying whether the compute instance is permitted to access the service in the target cloud environment (Grinstein – Paragraph [0047]: The credentials may represent a local identity with an associated logical authorization policy that has an associated local authorization policy. The retrieved credentials, being associated with a local authorization policy that grants sufficient authorization permissions to permit the workload 214 to access the target execution environment/cloud platform).
The motivation to combine the arts is the same as that of Claim 10.
Regarding Claim 13:
Wu, Grinstein, Almutairi, Wardell, and Tripp combine to teach the one or more computer readable non-transitory media storing specific computer-executable instructions of claim 11.
Almutairi further teaches wherein the computer system is further configured for: responsive to the identity principal being successfully validated, obtaining, by the source intercloud service gateway, the access role [associated with the compute instance] (Almutairi et al. – P. 39, Col. 3: If the request contains an authenticating credential, the credential evaluator assigns a user a local role based on the user-to-role assignment rules stored in the RBAC policy base) from preconfigured information stored in the source cloud environment (Almutairi et al. – P. 39, Col. 3: local role based on the user-to-role assignment rules stored in the RBAC policy base).
Grinstein further teaches the access role associated with the compute instance ((Grinstein – Paragraph [0025]: The WCS 102 maps an identity associated with the workload 214 to a logical identity that is acceptable on another execution environment; and Paragraph [0029]: The logical identity or identity construct may have different structures or be referenced by different names in different cloud platforms, such as a “role” on AWS, a “service account” on GCP and a “managed identity” on Microsoft Azure).
The motivation to combine the arts is the same as that of Claim 10.
Regarding Claim 15:
Wu, Grinstein, Almutairi, Wardell, and Tripp combine to teach the one or more computer readable non-transitory media storing specific computer-executable instructions of claim 10.
Wu further teaches wherein the source intercloud service gateway is disposed in a first data plane of the source cloud environment and the target intercloud service gateway is disposed in a second data plane of the target cloud environment (Wu – P. 55, Figure 1: Gateway-based architecture of virtual private cloud, illustrating gateways present within each collaborating environment), the source intercloud service gateway being communicatively coupled to the target intercloud service gateway via a trusted communication channel (Wu – P. 57, Col. 2: To guarantee the security level defined by the enterprises, the VPC gateways should ensure end-to-end security. Loosely speaking, both gateways should create a secure channel for any information exchange between them).
The motivation to combine the arts is the same as that of Claim 10.
Regarding Claim 16:
Wu, Grinstein, Almutairi, Wardell, and Tripp combine to teach the one or more computer readable non-transitory media storing specific computer-executable instructions of claim 10.
Grinstein further teaches wherein the computer system is further configured for: extracting, by the target intercloud service gateway, the access role associated with the compute instance from the modified request (Grinstein – Paragraph [0047]: The retrieved credentials, being associated with a local authorization policy that grants sufficient authorization permissions to permit the workload 214 to access the target execution environment/cloud platform) and obtaining, by the target intercloud service gateway, a token associated with the access role from a management service included in the target cloud environment (Grinstein – Paragraph [0047]: the request to the STS 220b acts as an “assumeRole” request, which is an operation that requests a token representing a particular identity; The STS token is returned to the UIMS 218 and the UIMS 218, in turn, returns the received token to the workload 214).
The motivation to combine the arts is the same as that of Claim 10, with the addition that Grinstein teaches implementation of an access token as a security feature to be included in the executable instructions.
Regarding Claim 18:
Wu teaches a system comprising: a processor; and a memory including instructions that, when executed with the processor, cause the system to, at least (Wu – P. 57, Col. 2: Each cloud is constructed with computers supporting BIOS virtualization … Examiner’s Comment: computers having the memory/storage to store instruction codes for execution by a processor(s)): generate, [by a compute instance executed] in a source cloud environment, a request to use a service provided in a target cloud environment (Wu – P. 57, Col. 1: Access to Inter-cloud Resources: In the VPC diagram shown in Figure 4, the gateway can represent any user within its enterprise to send and receive data across clouds. When a user requests a service or resource from the collaborative enterprise, the gateway is authorized to complete the request on the user’s behalf) the source cloud environment being different than the target cloud environment (Wu – p. 57, Col. 1: a VPC gateway should translate the access request from its local user to a standard format e.g. SAML (Security Assertion Markup Language)) so that the gateway in the target enterprise can enforce the access control. For instance, if the user requests access to the resources of a peer cloud, the gateway in the user’s enterprise will translate the request into another format that is compliant with the target enterprise, so that the request can be handled as a local request by the target enterprise) and transmit the request from the source cloud environment to the target cloud environment (Wu – P. 57, Col. 1: The gateway G1 translates the request into a “standard” Collaborative Clouds request format (e.g., SAML format), replaces the requestor with an authorized identity, and signs on the translated request. Then it sends the request to the target gateway G2) via a source intercloud service gateway disposed in [a first service tenancy in] the source cloud environment (Wu – Figure 4: illustrates access request from a local organization to a separate target organization. G1 is the source gateway) and a target intercloud service gateway disposed in [a second service tenancy in] the target cloud environment (Wu – Figure 4: illustrates access request from a local organization to a separate target organization. G2 is the target gateway), wherein the transmitting the request includes: send [by the compute instance], the request to the source intercloud service gateway (Wu – P. 57, Col. 1: When a user wants to access the resource (or service) of one collaborative enterprise, he sends a request to the local authenticator A1. After the local authenticator A1 verifies (user) authenticity, it sends the request to the gateway G1; and P. 56, Figure 2: illustrates that authentication is performed within the Data security unit, which is component of the security gateway) wherein the source intercloud service gateway (a) modifies the request to generate a modified request (Wu – P. 57, Col. 1: The gateway G1 translates the request into a “standard” Collaborative Clouds request format (e.g., SAML format), replaces the requestor with an authorized identity, and signs on the translated request) at least by removing a credential from the request (Wu – P. 58, Col. 2: The user’s home VPC gateway processes the request before sending it through the channel, replacing the requestor identity with a pseudo user name to achieve anonymity) and (b) transmits the modified request to the target intercloud service gateway (Wu – P. 57, Col. 1: Then (gateway G1) sends the request to the target gateway G2), and cause, by the target intercloud service gateway, the service to be executed in the target cloud environment (Wu – P. 57, Col. 1-2: The target gateway G2 verifies the request based on the signature of the sending gateway G1 and translates the “standard” request format into its own request format. Then it sends the request to its own authenticator A2. Once A2 authenticates the request, the user can access the resource or service); and based on the modified request (Wu – P.57, Col. 1-2: user sends a request to the local authenticator A1 along with his authentication information (e.g., credential, identity/role/attribute; The target gateway G2 verifies the request based on the signature of the sending gateway G1 and translates the “standard” request format into its own request format. Then it sends the
request to its own authenticator A2. Once A2 authenticates the request, the user can access the resource or service).
Wu does not expressly teach a system comprising: a processor; and a memory including instructions that, when executed with the processor, cause the system to, at least: generate, by a compute instance executed in a source cloud environment, a request; send, by the compute instance, the request; and adding an access role in the target cloud environment associated with the compute instance; wherein the source cloud environment is provided by a first cloud service provider and the source cloud environment provides a first plurality of cloud services, and the target cloud environment is provided by a second cloud service provider and the target cloud environment provides a second plurality of services, wherein the second cloud service provider is different than the first cloud service provider.
However, Grinstein teaches system comprising: a processor; and a memory including instructions that, when executed with the processor, cause the system to, at least (Grinstein et al. – Paragraph [0004]: An embodiment system may have a non-transitory computer readable medium having a program stored thereon for execution by a computer processor, the program including instructions; and Paragraph [0021]: The WCS 102 may be software stored on a non-transitory computer readable medium and executed on one or more computers having one or more processors and memory): generate, by a compute instance executed in a source cloud environment, a request (Grinstein – Paragraph [0006]: an instance metadata service request sent by a workload operating on the first execution environment; Examiner’s Comment: the generation of the request by the workload is implicit) to use a service provided in a target cloud environment the source cloud environment being different than the target cloud environment (Grinstein – Paragraph [0001]: a system and method for handling requests from workloads in a first cloud computing platform and providing credentials for the workloads to seamlessly access cloud services on a second, different, cloud platform); send by the compute instance, the request (Grinstein – Paragraph [0006]: an instance metadata service request sent by a workload operating on the first execution environment); and [and adding] an access role in the target cloud environment associated with the compute instance (Grinstein – Paragraph [0025]: The WCS 102 maps an identity associated with the workload 214 to a logical identity that is acceptable on another execution environment, such as the second execution environment 104b, so that the workload 214 can access a second cloud service 222b on the second execution environment 104b; and Paragraph [0029]: The logical identity or identity construct may have different structures or be referenced by different names in different cloud platforms, such as a “role” on AWS, a “service account” on GCP and a “managed identity” on Microsoft Azure); wherein the source cloud environment is provided by a first cloud service provider (Grinstein – Paragraph [0019]: The different execution environments 104a . . . 104n may be execution environments of different cloud service providers, and may have different operational formats such as different communications formats, data structures to accessing data or operating within the execution environment, different metadata access formats, different authentication structures, and the like) and the source cloud environment provides a first plurality of cloud services (Grinstein – Paragraph [0017]: Embodiments of the present disclosure are directed to providing a workload control system that allows a workload deployed on a cloud platform execution environment to access features, services, data, or other software deployed or available on another cloud platform) , and the target cloud environment is provided by a second cloud service provider (Grinstein – Paragraph [0019]: The different execution environments 104a . . . 104n may be execution environments of different cloud service providers, and may have different operational formats such as different communications formats, data structures to accessing data or operating within the execution environment, different metadata access formats, different authentication structures, and the like) and the target cloud environment provides a second plurality of services (Grinstein – Paragraph [0017]: Embodiments of the present disclosure are directed to providing a workload control system that allows a workload deployed on a cloud platform execution environment to access features, services, data, or other software deployed or available on another cloud platform), wherein the second cloud service provider is different than the first cloud service provider (Grinstein – Paragraph [0019]: The different execution environments 104a . . . 104n may be execution environments of different cloud service providers).
It would have been obvious before the effective filing date of the claimed invention to one of ordinary skill in the art to modify Wu, further incorporating Grinstein to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Grinstein’s teachings of system for executing storable instructions to implement APIs of one execution environment to associate a requesting workload with an access role applicable to another execution environment of a different cloud provider in order to fulfill a request for an intercloud resource/service into Wu’s teachings of security gateways residing in participating clouds to facilitate and fulfill requests for users to access services offered on foreign cloud platforms. This combination of the functionality taught by Grinstein – providing intercloud access to resources and services – and the structure taught by Wu – a gateway established at each collaborating cloud environment – would result in a practically executable process for cloud workloads to make requests for and receive appropriate levels of access to services provided in different cloud environments.
The combination of Wu and Grinstein does not expressly teach and adding an access role in the target cloud environment associated with the compute instance; and the modified request including the access role.
However, Almutairi teaches and adding an access role in the target cloud environment associated with the compute instance (Almutairi – P. 42, Col. 3: If X requires a remote resource, the participating SLA assigns it a mapped role (say, Ry); and Figure 6: Flow of request via the access control module and virtual resource manager across multiple clouds; and P. 43, Col. 1: In scenario B.2, the local SaaS needs to access virtual resources managed by CP2’s PaaS and IaaS. Assuming cross-layered SLA architecture, the local SaaS’s VRM generates the authorization request Ry, execute, PaaSCP2, CompInstx(isolation = 1), which is then forwarded to CP2’s PaaS’s ACM through the SLA); and the modified request including the access role (Almutairi – P. 39, Figure 3: SLA architecture including Role Mapper; and P. 39 Col. 2, P 40, Col. 1: If the request contains an authenticating credential, the credential evaluator assigns a user a local role based on the user-to-role assignment rules stored in the RBAC policy base. The process of user-to-role assignment re- quires input from the context evaluator regarding contextual constraints. If the request contains an authorization credential, the credential evaluator assesses if the role corresponds to a local role. If not, the implication is that this is a single-sign-on request and requires role mapping by a relevant SLA. Subsequently, the user acquires the privileges of the locally assigned role or of a mapped role in a remote cloud).
It would have been obvious before the effective filing date of the claimed invention to one of ordinary skill in the art to modify Wu and Grinstein, further incorporating Almutairi to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Almutairi’s teachings of modifying an intercloud service request by adding a role defining a user’s access privileges on a foreign cloud into Wu and Grinstein’s teachings of security gateways residing in participating clouds to facilitate and fulfill requests for users to access services offered on separate cloud platforms. This teaching enhances Grinstein’s teaching by injecting a role directly into the service request for a more streamlined authorization process in facilitating access to intercloud services.
The combination of Wu, Grinstein, and Almutairi does not expressly teach a source intercloud service gateway disposed in a first service tenancy in the source cloud environment and a target intercloud service gateway disposed in a second service tenancy in the target cloud environment.
However, Wardell teaches a source intercloud service gateway disposed in a first service tenancy in the source cloud environment and a target intercloud service gateway disposed in a second service tenancy in the target cloud environment (Wardell – Paragraph [0118]: In one embodiment, IDCS implements a “Cloud Gate” in the web tier. In one embodiment, Cloud Gate is implemented by a web server plugin that enables web applications to externalize user SSO to an identity management system (e.g., IDCS), similar to WebGate or WebAgent technologies that work with enterprise IDM stacks. In one embodiment, Cloud Gate acts as a security gatekeeper that secures access to IDCS APIs. In one embodiment, Cloud Gate is implemented by a web/proxy server plugin that provides a web PEP for protecting HTTP resources based on OAuth. In one embodiment, Cloud Gate also performs authentication (e.g., OAuth authentication); and Paragraph [0119]: In one embodiment, Cloud Gate may be deployed to protect a single-tenant application or a multi-tenant application, and may be deployed in proxy-mode front-ending different types of applications. In one embodiment, Cloud Gate supports single-tenant and multi-tenant applications by using respective default configurations for <Tenant> (represents what tenant owns the Cloud Gate instance) and <Host Identifier> (represents what application is being accessed). In one embodiment, local configurations specify default values for these artifacts, and may be overwritten on a per-request basis via HTTP headers supplied by the routing tier. For example, for a multi-tenant application, <Tenant> defines Cloud Gate's tenancy and is used to construct IDCS service URLs when contacting an IDCS server, and may be overwritten on a per-request basis by an optional X-RESOURCE-IDENTITY-DOMAIN-NAME header including <tenant-name> (e.g., “acme”); and Paragraph [0120]: In one embodiment, one instance of Cloud Gate is deployed for each tenant).
It would have been obvious before the effective filing date of the claimed invention to one of ordinary skill in the art to modify Wu, Grinstein, and Almutairi, further incorporating Wardell to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Wardell’s teachings to deploy per-tenant Cloud Gates to facilitate and authenticate requests to access resources between multiple tenancies into Wu, Grinstein, and Almutairi’s teachings of security gateways residing in participating clouds to facilitate and fulfill requests for users to access services offered on separate cloud platforms. Wardell’s per-tenant Cloud Gates address a known need for tenant-level policy customization and identity and access management. Thus, the addition of this aspect to the combination of Wu, Grinstein, and Almutairi provides the obvious benefit of inter-tenant resource access and simultaneous protection.
The combination of Wu, Grinstein, Almutairi, and Wardell does not expressly teach and wherein the source intercloud service gateway disposed in the source cloud environment and the target intercloud service gateway disposed in the target cloud environment are deployed and being controlled by a control plane of the source cloud environment.
However, Tripp teaches and wherein the source intercloud service [gateway] disposed in the source cloud environment and the target intercloud service [gateway] disposed in the target cloud environment are deployed and being controlled by a control plane of the source cloud environment (Tripp – Paragraph [0033], [0039], [0040]: Embodiments described herein further seek to support one or more of the following features … Per tenant inbound/outbound authentication via industry standards (e.g., Oauth2, OIDC with Proof Key for Code Exchange (PKCE), SAML, and LDAP); and Per tenant local users, groups, Single-Sign-On (SSO) and authorization policies; and Paragraph [0045]: As used herein, a “unified Identity and Access Management control plane” generally refers to APIs and associated services that support integration of multiple internal and/or external services, potentially using differing IAM protocols and/or schemes, into a cohesive model. In one embodiment, multiple service integrations are supported by enabling internal and/or external services to plugin to the unified IAM control plane by exposing appropriate APIs (e.g., for retrieval of resources, roles and permissions) and making use of those of a rich set of APIs of the unified IAM control plane as appropriate for the desired level of service integration (e.g., direct integration, brokered change events, and authentication level enforcement); and Paragraph [0051]: implementation of a unified Identity and Access Management (IAM) control plane by a Managed Service Provider (MSP) 230).
It would have been obvious before the effective filing date of the claimed invention to one of ordinary skill in the art to modify Wu, Grinstein, Almutairi, and Wardell, further incorporating Tripp to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Tripp’s unified IAM control plane for providing resources, roles, and permissions of various external cloud environments from a single source provider into Wu, Grinstein, Almutairi, and Wardell’s method for secure and private service access across multiple cloud environments offered by different cloud service providers. Tripp’s explicit teaching of unified IAM control plane enabling cross-cloud collaboration demonstrates a known technique in the art for seamless provision of multi-cloud resources from a single source point. This consideration naturally combines with the teachings of Wu, Grinstein, Almutairi, and Wardell, all applied to comparable scenarios for facilitating intercloud processes.
Regarding Claim 19:
Wu, Grinstein, Almutairi, Wardell, and Tripp combine to teach the system of claim 18.
Wu further teaches send, [by the compute instance], the request to the source intercloud service gateway disposed in the source cloud environment (Wu – P. 57, Col. 1: When a user wants to access the resource (or service) of one collaborative enterprise, he sends a request to the local authenticator A1 along with his authentication information (e.g., credential, identity/role/attribute) … After the local authenticator A1 verifies (user) authenticity, it sends the request to the gateway G1; and P. 56, Figure 2: illustrates that authentication is performed within the Data security unit, which is component of the security gateway) the request including an identity principal [associated with the compute instance] (Wu – P. 57, Col. 1: When a user wants to access the resource (or service) of one collaborative enterprise, he sends a request to the local authenticator A1 along with his authentication information (e.g., credential, identity/role/attribute)) and validating, by the source intercloud service gateway, the identity principal of the compute instance (Wu – P. 57, Col. 1: after the local authenticator A1 verifies their authenticity, it sends the request to the gateway G1; and P. 56, Figure 2: illustrates that authentication is performed within the Data security unit, which is a component of the security gateway).
Grinstein further teaches sending, by the compute instance, the request (Grinstein – Paragraph [0006]: an instance metadata service request sent by a workload operating on the first execution environment); the request including an identity principal associated with the compute instance (Grinstein – Paragraph [0058]: the WCS may track the canonical identity of the workload and may determine the canonical identity of the workload from requests made to the WCS on behalf of the workload).
The motivation to combine the arts is the same as that of claim 18.
Regarding Claim 20:
Wu, Grinstein, Almutairi, Wardell, and Tripp combine to teach the system of claim 19.
Grinstein further teaches wherein the system is configured to validate the identity principal by verifying whether the compute instance is permitted to access the service in the target cloud environment (Grinstein – Paragraph [0047]: The credentials may represent a local identity with an associated logical authorization policy that has an associated local authorization policy. The retrieved credentials, being associated with a local authorization policy that grants sufficient authorization permissions to permit the workload 214 to access the target execution environment/cloud platform).
The motivation to combine the arts is the same as that of Claim 18.
Regarding Claim 22:
Wu, Grinstein, Almutairi, Wardell, and Tripp combine to teach the method of Claim 1.
Wu further teaches wherein prior to removing the credential from the request, the source intercloud service gateway verifies the credential included in the request ((Wu – P. 57, Col. 1: When a user wants to access the resource (or service) of one collaborative enterprise, he sends a request to the local authenticator A1 along with his authentication information (e.g., credential, identity/role/attribute) … after the local authenticator A1 verifies their authenticity, it sends the request to the gateway G1; and P. 56, Figure 2: illustrates that authentication is performed within the Data security unit, which is a component of the security gateway), and the source intercloud service gateway modifies the request to generate the modified request (Wu – P. 58, Col. 2: The user’s home VPC gateway processes the request before sending it through the channel, replacing the requestor identity with a pseudo user name to achieve anonymity) responsive at least to successfully verifying the credential (Wu – P. 57, Col. 1: after the local authenticator A1 verifies their authenticity, it sends the request to the gateway G1; and P. 56, Figure 2: illustrates that authentication is performed within the Data security unit, which is a component of the security gateway).
Regarding Claim 23:
Wu, Grinstein, Almutairi, Wardell, and Tripp combine to teach the method of Claim 1.
Wu further teaches wherein the credential is used to substantiate the request to use the service in the source cloud environment (Wu – P. 58, Col. 1-2: a user issues a request for a local data resource (i.e., download a file) in the private cloud. In this case, the user is authenticated by his local identity server normally (via Kerberos mechanism in our setting). Upon authorization of access based on the local policy, he then accesses the data directly from the private cloud),
Grinstein further teaches and the access role is used to substantiate the modified request to use the service in the target cloud environment (Grinstein – Paragraph [0025]: The WCS 102 maps an identity associated with the workload 214 to a logical identity that is acceptable on another execution environment, such as the second execution environment 104b, so that the workload 214 can access a second cloud service 222b on the second execution environment 104b; and Paragraph [0029]: The logical identity or identity construct may have different structures or be referenced by different names in different cloud platforms, such as a “role” on AWS, a “service account” on GCP and a “managed identity” on Microsoft Azure).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 24:
Wu, Grinstein, Almutairi, Wardell, and Tripp combine to teach the method of Claim 1.
Grinstein further teaches wherein the access role in the target cloud environment associated with the compute instance is also associated with the service (Grinstein – Paragraph [0025]: The WCS 102 maps an identity associated with the workload 214 to a logical identity that is acceptable on another execution environment, such as the second execution environment 104b, so that the workload 214 can access a second cloud service 222b on the second execution environment 104b; and Paragraph [0029]: The logical identity or identity construct may have different structures or be referenced by different names in different cloud platforms, such as a “role” on AWS, a “service account” on GCP and a “managed identity” on Microsoft Azure).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 25:
Wu, Grinstein, Almutairi, Wardell, and Tripp combine to teach the method of Claim 1.
Grinstein further teaches further comprising: determining, by the control plane of the source cloud environment, whether a customer is associated with a tenancy in the target cloud environment (Grinstein – Paragraph [0030]: The IAM broker 202 uses stored cloud account credentials 208 to properly authenticate and authorize calls to the execution environment IAM APIs 210a, 210b by calling an IAM API 210a, 210b for each execution environment 104a, 104b identified in the user request. The IAM broker 202 provisions, for each of the requested execution environments 104a, 104b, a logical identity corresponding to the canonical identity created and managed by the WCS 102); and responsive to successfully determining that the customer is not associated with the tenancy in the target cloud environment, instantiating, by the control plane of the source cloud environment, a resource group for the customer in the target cloud environment (Grinstein – Paragraph [0025]: [0025] The workload 214 is deployed in the first cloud platform 104a, and in some embodiments, the workload 214 may be deployed in a particular host account 204 so that the credential handler 224 is able to seamlessly support the workload execution. The WCS 102 provides authentication across multiple execution environments 104a, 104b for the workload 214 in combination with the credential handler 224. The WCS 102 maps an identity associated with the workload 214 to a logical identity that is acceptable on another execution environment, such as the second execution environment 104b, so that the workload 214 can access a second cloud service 222b on the second execution environment 104b while still having access to a first cloud service 222a running on the same, first execution environment 104a on which the workload 214 is running. A credential handler 224 intercepts instance metadata service requests or identity requests. The credential handler 224 initiates its own request to a security token service 220b in another execution environment 104b and retrieves a security token from the second execution environment 104b. The credential handler 224 provides the credentials to the workload 214 so that the workload 214 has credentials to access a service on an execution environment 104b different than the execution environment 104a on which the workload 214 is executed; Examiner’s Comment: Examiner respectfully submits that implicit in the provision of credentials for access to a service in another execution environment is the conclusion that no such credentials exist already).
The motivation to combine the arts is the same as that of Claim 1.
Claims 8, 9, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Wu, in view of Grinstein, Almutairi, Wardell, Tripp, and Ngo et al. (Ngo, C., Demchenko, Y., & De Laat, C. (2016). Multi-tenant attribute-based access control for cloud infrastructure services. Journal of Information Security and Applications, 27–28, 65–84.), hereinafter Ngo.
Regarding Claim 8:
Wu, Grinstein, Almutairi, Wardell, and Tripp combine to teach the method of claim 7.
The combination of Wu, Grinstein, Almutairi, Wardell, and Tripp does not expressly teach further comprising: signing, by the target intercloud service gateway, the modified request with the token associated with the access role to form a signed modified request; and forwarding the signed modified request to the service that is desired to be used by the compute instance.
However, Ngo teaches further comprising: signing, by the target intercloud service gateway, the modified request with the token associated with the access role to form a signed modified request (Ngo – P. 77, Col. 2: The consequent requests from the user to (resource provider) are signed with the session key; and P. 76, Col. 1: Extended MT-ABAC for multiple providers; Examiner’s Comment: MT-ABAC acts as ICSGW for providing services from multiple providers); and forwarding the signed modified request to the service that is desired to be used by the compute instance (Ngo – P. 77, Col. 2: After having the access token, user accesses the protected resource at (the resource provider)).
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 Wu, Grinstein, Almutairi, Wardell, and Tripp, further incorporating Ngo to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Ngo’s process of signing modified access requests and forwarding the signed requests to the desired services into Wu, Grinstein, Almutairi, Wardell, and Tripp’s combined teachings of a method for securely requesting and offering intercloud services. This combination would add an additional layer of security at the site of the requested resource in order to prevent the possibility of unauthorized access within a cloud environment.
Regarding Claim 9:
Wu, Grinstein, Almutairi, Wardell, Tripp, and Ngo combine to teach the method of claim 8.
Ngo further teaches further comprising: validating, by the service, the signed modified request based on the token (Ngo – P. 77, Col. 2: Upon receiving user's request with access token, the pb's resource service validates the access token); and responsive to a successful validation, executing the request by the service (Ngo – P. 77, Col. 2: If comparison between the request with involved attributes X is positive, the service will serve the request).
The motivation to combine the arts is the same as that of Claim 8.
Regarding Claim 17:
Wu, Grinstein, Almutairi, Wardell, and Tripp combine to teach the one or more computer readable non-transitory media storing specific computer-executable instructions of claim 16.
The combination of Wu, Grinstein, Almutairi, Wardell, and Tripp does not expressly teach wherein the computer system is further configured for: signing, by the target intercloud service gateway, the modified request with the token associated with the access role to form a signed modified request; and forwarding the signed modified request to the service that is desired to be used by the compute instance.
However, Ngo teaches wherein the computer system is further configured for: signing, by the target intercloud service gateway, the modified request with the token associated with the access role to form a signed modified request (Ngo – P. 77, Col. 2: The consequent requests from the user to (resource provider) are signed with the session key; and P. 76, Col. 1: Extended MT-ABAC for multiple providers; Examiner’s Comment: MT-ABAC acts as ICSGW for providing services from multiple providers); and forwarding the signed modified request to the service that is desired to be used by the compute instance (Ngo – P. 77, Col. 2: After having the access token, user accesses the protected resource at (the resource provider)).
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 Wu, Grinstein, Almutairi, Wardell, and Tripp, further incorporating Ngo to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Ngo’s process of signing modified access requests and forwarding the signed requests to the desired services into Wu, Grinstein, Almutairi, Wardell, and Tripp’s combined teachings of a computer readable medium storing executable instructions to securely request and offer intercloud services. This combination would provide the practical, reusable capability to add an additional layer of security at the site of the requested resource in order to prevent the possibility of unauthorized access within a cloud environment.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Bannerjee et al. (US 20170093790 A1) teaches a multi-tenant cloud system that deploys cloud network gateways to each tenant
Chang et al. (US 20170339070 A1) teaches a system that implements a cloud broker gateway at each cloud environment to facilitate intercloud resource access
Schmidt et al. (US 9467395 B2) teaches a method for aggregating cloud resources from different CSP using tenant API providers and tenant API clients
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