DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to claims filed on 12/09/2025.
Claims 1-7, 9-16, and 18-20 are pending.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-7, 9-16, and 17-20 are rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, is directed to that judicial exception, an abstract idea, as it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below.
Step 1: Claims 1-7 and 9-10 are directed to a method and fall within the statutory category of processes. Claims 10-16 and 18 are directed to computer readable non-transitory media and fall within the statutory category of machines. Claims 19-20 are directed to a computing device and fall within the statutory category of machines. Therefore, “Are the claims to a process, machine, manufacture or composition of matter?” Yes.
In order to evaluate the Step 2A inquiry “Is the claim directed to a law of nature, a natural phenomenon or an abstract idea?” we must determine, at Step 2A Prong 1, whether the claim recites a law of nature, a natural phenomenon or an abstract idea and further whether the claim recites additional elements that integrate the judicial exception into a practical application.
Step 2A Prong 1:
Claims 1, 10, and 19: The limitations of “validating (validate), by the multi-cloud infrastructure, the user based on a token included in the first request,”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can mentally validate a user based on mental evaluation of a token. Further, the limitations of “the token being generated by the second cloud infrastructure;”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can mentally generate a token. This may also be done with pencil and paper. Further the limitations of “and deploying, by the multi-cloud infrastructure, a network link that communicatively couples the tenancy of the user in the first cloud infrastructure to the account of the user in the second cloud infrastructure, the network link facilitating the user to access the resource deployed in the first cloud infrastructure from the second cloud infrastructure,”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can mentally generate a network link that communicatively couples the tenancy of the user in the first cloud infrastructure to the account of the user in the second cloud infrastructure; this can be done by creating a mental association between the tenancy of the user in the first could infrastructure and the account of the user in the second cloud infrastructure. This may also be done with pencil and paper.
Therefore, Yes, claims 1, 10, and 19 recite a judicial exception.
Step 2A Prong 2:
Claims 1, 10, and 19: The judicial exception is not integrated into a practical application. In particular, the claims recite the following additional elements – “by a multi-cloud infrastructure included in a first cloud infrastructure provided by a first cloud services provider (CSP),”, “by a multi-cloud infrastructure included in a first cloud infrastructure,”, “from a user associated with an account in a second cloud infrastructure provided by a second CSP,”, “from a user associated with an account in a second cloud infrastructure,”, “the first request requesting a resource to be created in the first cloud infrastructure;”, “the link-resource object including information linking a tenancy created for the user in the first cloud infrastructure to the account associated with the user in the second cloud infrastructure;”, “the second request requesting creation of the resource, wherein the second request includes the resource-principal;”, and “One or more computer readable non-transitory media storing computer-executable instructions that, when executed by one or more processors, cause:”, which are merely recitations of technological environment/field of use (see MPEP § 2106.05(h)) which does not integrate a judicial exception into practical application. Further, the claims recite additional element recitations of “receiving (receive), … a first request”, “and responsive to successfully validating the user: obtaining (obtain) a link-resource object previously created for the user,”, “accessing (access), using the link-resource object, a resource-principal previously created for the user;”, “transmitting (transmit), by the multi-cloud infrastructure, a second request to a service provided by the first cloud infrastructure,”, which are merely recitations of data reception, retrieval, and transmission which is insignificant extra solution activity (see MPEP §2106.05(g)) which does not integrate a judicial exception into practical application. Further, the claims recite additional element recitations of “A computing device comprising: one or more processors; and a memory including instructions that, when executed with the one or more processors, cause the computing device to, at least:”, which are merely recitations of generic computing components (see MPEP § 2106.05(f)) which does not integrate a judicial exception into practical application.
Therefore, “Do the claims recite additional elements that integrate the judicial exception into a practical application? No, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
After having evaluated the inquires set forth in Steps 2A Prong 1 and 2, it has been concluded that claims 1, 10, and 19 not only recite a judicial exception but that the claims are directed to the judicial exception as the judicial exception has not been integrated into practical application.
Step 2B:
Claims 1, 10, and 19: The claims do not include additional elements, alone or in combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to no more than generic computing components, field of use/technological environment, and insignificant extra solution activity which do not amount to significantly more than the abstract idea. Further, the insignificant extra solution activity is well-understood, routine, and conventional in the art. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network…iv. Storing and retrieving information in memory” [MPEP§ 2106.05(d)(II)].
Therefore, “Do the claims recite additional elements that amount to significantly more than the judicial exception? No, these additional elements, alone or in combination, do not amount to significantly more than the judicial exception.
Having concluded analysis within the provided framework, Claims 1, 10, and 19 do not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claims 2 and 11, the claims recite additional element recitations of “wherein the link-resource object includes information linking the tenancy of the user in the first cloud infrastructure to the account of the user in the second cloud infrastructure,” which are merely recitations of technological environment/field of use (see MPEP § 2106.05(h)) which does not integrate a judicial exception into practical application. Further, the claims recite additional element recitations of “the link-resource object being stored in a compartment of the tenancy of the user in the first cloud infrastructure” which are merely recitations of data storage which is insignificant extra solution activity (see MPEP §2106.05(g)) which does not integrate a judicial exception into practical application. Further, the insignificant extra solution activity is well-understood, routine, and conventional in the art. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network…iv. Storing and retrieving information in memory” [MPEP§ 2106.05(d)(II)]. Further, claims 2 and 11 do not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claims 2 and 11 also fail both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fail Step 2B as not amounting to significantly more. Therefore, Claims 2 and 11 do not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claims 3 and 12, the claims recite additional abstract idea recitations of “wherein the resource-principal is associated with the link-resource object and is assigned one or more permissions based on the token” as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can observe a token and based on these observations can mentally assign one or more permissions to a resource-principal. Further, claims 3 and 12 do not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claims 3 and 12 also fail both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fail Step 2B as not amounting to significantly more. Therefore, Claims 3 and 12 do not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claims 4 and 13, the claims recite additional element recitations of “wherein the resource to be created in the first cloud infrastructure is a database and the service provided by the first cloud infrastructure is a database-as-a-service” which are merely recitations of technological environment/field of use (see MPEP § 2106.05(h)) which does not integrate a judicial exception into practical application. Further, claims 4 and 13 do not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claims 4 and 13 also fail both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fail Step 2B as not amounting to significantly more. Therefore, Claims 4 and 13 do not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claims 5 and 14, the claims recite additional element recitations of “wherein the multi-cloud infrastructure includes a database adaptor and a cloud-link adaptor,” which are merely recitations of technological environment/field of use (see MPEP § 2106.05(h)) which does not integrate a judicial exception into practical application. Further, the claims recite additional element recitations of “and wherein the database adaptor receives the resource-principal associated with the link-resource object from the cloud-link adaptor and transmits the resource-principal to the database-as-a-service”, which are merely recitations of data reception and transmission which is insignificant extra solution activity (see MPEP §2106.05(g)) which does not integrate a judicial exception into practical application. Further, claims 5 and 14 do not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claims 5 and 14 also fail both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fail Step 2B as not amounting to significantly more. Further, the insignificant extra solution activity is well-understood, routine, and conventional in the art. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network…iv. Storing and retrieving information in memory” [MPEP§ 2106.05(d)(II)]. Therefore, Claims 5 and 14 do not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claims 6 and 15, the claims recite additional element recitations of “wherein the database is one of: an Exa-database, a shared- autonomous database, a dedicated-autonomous database, or a virtual machine database” which are merely recitations of technological environment/field of use (see MPEP § 2106.05(h)) which does not integrate a judicial exception into practical application. Further, claims 6 and 15 do not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claims 6 and 15 also fail both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fail Step 2B as not amounting to significantly more. Therefore, Claims 6 and 15 do not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claims 7 and 16, the claims recite additional abstract idea recitations of “identifying one or more tasks/operations associated with the role;” as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can mentally identify one or more tasks/operations associated with a given role. Further, the limitations of “and determining, based on the one or more tasks/operations, whether the user is permitted to issue the first request”, as drafted, is a process that, but for the recitation of generic computing components, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, a person can evaluate tasks/operations and based on this evaluation can mentally determine whether a user is permitted to issue a first request. Further, the claims recite additional element recitations of “wherein the validating includes: obtaining a role associated with the user in the second cloud infrastructure based on the token;”, which are merely recitations of data reception which is insignificant extra solution activity (see MPEP §2106.05(g)) which does not integrate a judicial exception into practical application. Further, claims 7 and 16 do not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claims 7 and 16 also fail both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fail Step 2B as not amounting to significantly more. Further, the insignificant extra solution activity is well-understood, routine, and conventional in the art. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network…iv. Storing and retrieving information in memory” [MPEP§ 2106.05(d)(II)]. Therefore, Claims 7 and 16 do not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claims 9 and 18, the claims recite additional element recitations of “providing, by the multi-cloud infrastructure, a web-link to the resource created in the first cloud infrastructure to the second cloud infrastructure,”, which is merely a recitation of data transmission which is insignificant extra solution activity (see MPEP §2106.05(g)) which does not integrate a judicial exception into practical application. Further, the claims recite additional element recitations of “the web-link being displayed in an application that is executed in the second cloud infrastructure” which is merely a recitation of data display/output which is insignificant extra solution activity (see MPEP §2106.05(g)) which does not integrate a judicial exception into practical application. Further, claims 9 and 18 do not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claims 9 and 18 also fail both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fail Step 2B as not amounting to significantly more. Further, the insignificant extra solution activity is well-understood, routine, and conventional in the art. “The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity. i. Receiving or transmitting data over a network…iv. Storing and retrieving information in memory” [MPEP§ 2106.05(d)(II)]. “Below are examples of other types of activity that the courts have found to be well-understood, routine, conventional activity when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity: … iv. Presenting offers and gathering statistics” [MPEP§ 2106.05(d)(II)]. Therefore, Claims 9 and 18 do not recite patent eligible subject matter under 35 U.S.C. § 101.
With regard to claim 20, the claim recites additional element recitations of “wherein the first cloud infrastructure is provided by a first cloud services provider (CSP), and the second cloud infrastructure is provided by a second CSP, the second CSP being different than the first CSP” which are merely recitations of technological environment/field of use (see MPEP § 2106.05(h)) which does not integrate a judicial exception into practical application. Further, claim 20 does not recite any further additional elements and for the same reasons as above with regard to integration into practical application and whether additional elements amount to significantly more, claim 20 also fails both Step 2A prong 2, thus the claims are directed to the judicial exception as it has not been integrated into practical application, and fails Step 2B as not amounting to significantly more. Therefore, Claim 20 does not recite patent eligible subject matter under 35 U.S.C. § 101.
Therefore, Claims 1-7, 9-16, and 17-20 do not recite patent eligible subject matter under U.S.C. §101.
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, 10-13, 15, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Jensen (US 2021/0165871 A1) in view of Ivanov (US 2023/0239301 A1).
With regard to claim 1, Jensen teaches:
A method comprising: receiving, by a multi-cloud infrastructure included in a first cloud infrastructure provided by a first cloud services provider (CSP), “In an embodiment, the hybrid cloud provider (CSP) refers to an organization that manages the infrastructure or resources of at least a portion of the hybrid cloud (first cloud infrastructure). As an example, the hybrid cloud provider can manage the resources that provide a control plane (multi-cloud infrastructure) for various services to connect to and utilize various hybrid cloud capabilities” [Jensen ¶ 36].
a first request “The consumer applications 120, 130 can then be configured to generate API calls (request) that are transmitted from the consumer application 120, 130 to the identified API in a corresponding API gateway 160” [Jensen ¶ 35].
from a user associated with an account in a second cloud infrastructure provided by a second CSP, “For example, one service provider can establish an account for a person and assign that account a local identifier. A second service provider can also establish an account for the person and assign that account a different local identifier” [Jensen ¶ 25]. “Each service can be associated with user accounts that are mapped to local identifiers that identify a particular user within the context of that service… However, a single user may have different user accounts for different services. The user may have distinct credentials for each user account. Each user account can be associated with a local identifier that identifies the user account within the context of a specific service provider” [Jensen ¶ 1-2]. “In some embodiments, cloud service providers may develop consumer applications, such as a first consumer application 120, Consumer App A, and a second consumer application 130, Consumer App B. Although not shown explicitly in FIG. 1A, different cloud services providers can develop services that are hosted in one or more data centers. Each data center can be associated with one or more API gateways 160, and APIs for the services are deployed to the corresponding API gateways 160. The consumer applications 120, 130 can then be configured to generate API calls that are transmitted from the consumer application 120, 130 to the identified API in a corresponding API gateway 160” [Jensen ¶ 34-35].
validating, by the multi-cloud infrastructure, the user based on a token included in the first request, “In an embodiment, responsive to authentication ofa request for one or more local identifiers associatedvalidate) included in the sessionand transmit the one or more local identifiers to the first consumer application” [Jensen ¶ 8]. “In this manner, the payload of the session token cannot be read to obtain the individual identifier directly, but an entity that is aware of the individual identifier can verify the authenticity of the session token by checking the payload against a hashed version of the individual identifier” [Jensen ¶ 41]. “The client device 110 then sends an authentication request to the AM App 140 that includes credentials for the account associated with a user of the client device 110. The authentication engine 320 reads the credentials from the authentication engine 320 and verifies the credentials match credentials stored in the account directory 180” [Jensen ¶ 56].
the token being generated by the second cloud infrastructure; “In some embodiments, the session token is passed from the first consumer application (second cloud infrastructure) 120 to the second consumer application 130 when the initiation of the second consumer application 130 is caused by the first consumer application 120… For example, if a mobile application connected with the first consumer application 120 is re-directed to connect to a second consume application 130, then the first consumer application 120 may also share the session token with the second consumer application 130…” [Jensen ¶ 44]. “In an embodiment, responsive to authentication of the client device based on the credentials, the account management application is configured to transmit a user session token associated with a corresponding account to a first consumer application” [Jensen ¶ 8].
and responsive to successfully validating the user: obtaining a link-resource object previously created for the user, “In some embodiments, once the session token has been verified, the key-mapping module 530 is used to query the local identifier map (link-resource object) 540 to return one or more local identifiers corresponding to the individual identifier for the constituent” [Jensen ¶ 82].
“A global identifier associated with a global identity context is defined to identify unique individuals within the context of a cloud architecture. The global identity context matches multiple different accounts to a unique constituent corresponding to that global identity context and can be used to establish a link between different IT systems throughout the cloud” [Jensen ¶ 24].
the link-resource object including information linking a tenancy created for the user in the first cloud infrastructure to the account associated with the user in the second cloud infrastructure; “The individual identifier cannot be used to access the services, but the local identifier corresponding to a particular service is used to access the particular service. A local identifier map (link-resource object) 540 associates each individual identifier with zero or more local identifiers. Each of the local identifiers can be provided to the IM App 150 by a corresponding service provider and mapped to an account established by that service provider” [Jensen ¶ 79]. “In an embodiment, one or more accounts are mapped to an individual identifier for a unique constituent, and that individual identifier is mapped, by the IM App 150, to one or more local identifiers. As used herein, a local identifier can refer to an identifier (e.g., a UUID, a GUID, etc.) maintained by a cloud service provider as an identifier for the constituent within the context of a service provided by the cloud service provider. The cloud service provider does not have visibility to the individual identifier for the constituent within the context of the hybrid cloud” [Jensen ¶ 51]. “In order to provide a better consumer experience within the hybrid cloud, a global identity context can be established for unique individuals and then a global identifier assigned to the individual can be mapped to the local identifiers utilized within the context of the individual service providers” [Jensen ¶ 26].
accessing, using the link-resource object, a resource-principal previously created for the user; “In some embodiments, once the session token has been verified, the key-mapping module 530 is used to query the local identifier map 540 to return one or more local identifiers (resource-principal) corresponding to the individual identifier for the constituent. The one or more local identifiers are then transmitted to the consumer application 120 and can be used to connect to services in the hybrid cloud” [Jensen ¶ 82].
transmitting, by the multi-cloud infrastructure, a second request “The second consumer application (first cloud infrastructure) 130 is then permitted to access one or more services using the session token and the local identifier(s) without having to re-prompt the user for credentials associated with a user account” [Jensen ¶ 43]. “The consumer application 120 can then pass the session token and a corresponding local identifier to a corresponding service when making an API call (second request) to the service, which enables the consumer application 120 to access the service without requiring re-authentication at the service” [Jensen ¶ 42 Examiner notes that although this example is given for consumer application 120, the process would be the same for consumer application 130]. “Therefore, the individual identifier is used to access the local identifier for a service, which is then transmitted, along with a session token, together with an API call to allow a consumer application 120 to access the service through the account” [Jensen ¶ 90].
wherein the second request includes the resource-principal; “The consumer application 120 can then pass the session token and a corresponding local identifier (resource-principal) to a corresponding service when making an API call (second request) to the service, which enables the consumer application 120 to access the service without requiring re-authentication at the service” [Jensen ¶ 42].
and deploying, by the multi-cloud infrastructure, a network link that communicatively couples the tenancy of the user in the first cloud infrastructure to the account of the user in the second cloud infrastructure, “A global identifier associated with a global identity context is defined to identify unique individuals within the context of a cloud architecture. The global identity context matches multiple different accounts to a unique constituent corresponding to that global identity context and can be used to establish a link between different IT systems throughout the cloud. For example, one service provider can establish an account for a person and assign that account a local identifier. A second service provider can also establish an account for the person and assign that account a different local identifier. Because the local identifiers are only understood within the context of services provided by the corresponding service providers, information related to the individual in one service cannot be linked to information related to the individual in the context of another service associated with a different service provider. In order to provide a better consumer experience within the hybrid cloud, a global identity context can be established for unique individuals and then a global identifier assigned to the individual can be mapped to the local identifiers utilized within the context of the individual service providers” [Jensen ¶ 24].
the network link facilitating the user to access the resource deployed in the first cloud infrastructure from the second cloud infrastructure. “However, a single user may have different user accounts for different services. The user may have distinct credentials for each user account. Each user account can be associated with a local identifier that identifies the user account within the context of a specific service provider” [Jensen ¶ 2]. “The service providers use local identifiers that are correlated with particular accounts within the context of one or more services. Therefore, the individual identifier is used to access the local identifier for a service, which is then transmitted, along with a session token, together with an API call to allow a consumer application 120 to access the service through the account” [Jensen ¶ 90]. “In some embodiments, cloud service providers may develop consumer applications, such as a first consumer application 120, Consumer App A, and a second consumer application 130, Consumer App B. The applications can utilize one or more network based services within the hybrid cloud network architecture. Although not shown explicitly in FIG. 1A, different cloud services providers can develop services that are hosted in one or more data centers. Each data center can be associated with one or more API gateways 160, and APIs for the services are deployed to the corresponding API gateways 160. The consumer applications 120, 130 can then be configured to generate API calls that are transmitted from the consumer application 120, 130 to the identified API in a corresponding API gateway 160. Since the consumer application 120, 130 may be hosted in a different data center than the corresponding API gateways 160, there is a need for the consumer applications 120, 130 to be authenticated by the API gateways 160. Furthermore, there is a need to authorize a single user of a client device 110 to access multiple APIs associated with services from multiple cloud service providers” [Jensen ¶ 35]. “The consumer application 120 can then pass the session token and a corresponding local identifier to a corresponding service when making an API call to the service, which enables the consumer application 120 to access the service without requiring re-authentication at the service” [Jensen ¶ 42]. “In some embodiments, the session token is passed from the first consumer application 120 to the second consumer application 130 when the initiation of the second consumer application 130 is caused by the first consumer application 120 … For example, if a mobile application connected with the first consumer application 120 is re-directed to connect to a second consume application 130, then the first consumer application 120 may also share the session token with the second consumer application 130 …” [Jensen ¶ 44].
Jensen fails to explicitly teach the first request requesting a resource to be created in the first cloud infrastructure; a second request to a service provided by the first cloud infrastructure, the second request requesting creation of the resource.
However, Ivanov teaches:
the first request requesting a resource to be created in the first cloud infrastructure; “Example 1 includes an apparatus to provision cloud infrastructure resources, the apparatus comprising provisioning circuitry to, in response to a first request from a tenant to access cloud infrastructure resources…” [Ivanov ¶ 197]. “In some examples, the example cloud provider interface circuitry 302 is used by (e.g., called from) the example first tenant 212 to generate a new layer of cloud infrastructure resource references to refer to the cloud infrastructure resources of the first cloud provider 202” [Ivanov ¶ 85]. “In the illustrated example, the vRealize Automation® cloud management platform 140 is a cloud management platform that can be used to build and manage a multi-vendor cloud infrastructure… In other examples, the example vRealize Automation® cloud management platform 140 may be offered as a Software as a Service (e.g., SaaS) wherein at least one instance of the vRealize Automation® cloud management platform 140 is deployed on a cloud provider (e.g., Amazon Web Services)” [Ivanov ¶ 50]. “In some examples, the example cloud provider interface circuitry 302 allows a direct connection to the cloud infrastructure resources of the example cloud providers 202, 204, 206 (e.g., VMware vSphere cloud provider, Microsoft Azure Cloud Services, Amazon Web Services (AWS), Google Cloud Platform, Alibaba Cloud, VMware vCloud Director cloud service delivery platform, etc.)” [Ivanov ¶ 83].
a second request to a service provided by the first cloud infrastructure, the second request requesting creation of the resource, “Example 1 includes an apparatus to provision cloud infrastructure resources, the apparatus comprising provisioning circuitry to, in response to a first request from a tenant to access cloud infrastructure resources, determine a type of a cloud account, cloud provider interface circuitry to, in response to the type of the cloud account being a cloud provider interface type, access service-provider-credentials, the cloud provider interface circuitry to retrieve a first access token based on the service-provider-credentials, submit a second request for the cloud infrastructure resources to a first cloud provider, the second request corresponding to the tenant impersonating the service provider based on the first access token” [Ivanov ¶ 197]. “Cloud provisioning is the allocation of cloud provider resources to a customer when a cloud provider accepts a request from a customer. For example, the cloud provider creates a corresponding number of virtual machines and allocates resources (e.g., application servers, load balancers, network storage, databases, firewalls, IP addresses, virtual or local area networks, etc.) to support application operation” [Ivanov ¶ 28].
Ivanov is considered to be analogous to the claimed invention because it is in the same field of protocols for authentication of entities. Jensen teaches a method for allowing a user working within an account in one cloud to link to their account on a different cloud and access cloud services through this link. This can be combined with the teachings of Ivanov which teaches a similar system wherein users can request the creation of resources within a multi-cloud environment. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jensen to incorporate the teachings of Ivanov and include the first request requesting a resource to be created in the first cloud infrastructure; a second request to a service provided by the first cloud infrastructure, the second request requesting creation of the resource. Doing so would improve users ability to utilize the system to access resources of external services. “In such examples, a cloud may extend capabilities of an enterprise, for example, to deliver a specific business service through the addition of externally available public cloud services” [Ivanov ¶ 24].
With regard to claim 2, Jensen in view of Ivanov teaches the method of claim 1, as referenced above. Jensen further teaches:
wherein the link-resource object includes information linking the tenancy of the user in the first cloud infrastructure to the account of the user in the second cloud infrastructure, “The individual identifier cannot be used to access the services, but the local identifier corresponding to a particular service is used to access the particular service. A local identifier map (link-resource object) 540 associates each individual identifier with zero or more local identifiers. Each of the local identifiers can be provided to the IM App 150 by a corresponding service provider and mapped to an account established by that service provider” [Jensen ¶ 79]. “In an embodiment, one or more accounts are mapped to an individual identifier for a unique constituent, and that individual identifier is mapped, by the IM App 150, to one or more local identifiers. As used herein, a local identifier can refer to an identifier (e.g., a UUID, a GUID, etc.) maintained by a cloud service provider as an identifier for the constituent within the context of a service provided by the cloud service provider. The cloud service provider does not have visibility to the individual identifier for the constituent within the context of the hybrid cloud” [Jensen ¶ 51]. “In order to provide a better consumer experience within the hybrid cloud, a global identity context can be established for unique individuals and then a global identifier assigned to the individual can be mapped to the local identifiers utilized within the context of the individual service providers” [Jensen ¶ 26].
Jensen fails to explicitly teach the link-resource object being stored in a compartment of the tenancy of the user in the first cloud infrastructure.
However, Ivanov teaches the link-resource object being stored in a compartment of the tenancy of the user in the first cloud infrastructure. “The example cloud provider hub circuitry 180 is provided with a cloud credential database 230 and separate tenant credential databases 234, 236. The example cloud credential database 230 is provided to store cloud provider account login credentials registered with different ones of the cloud providers 202, 204, 206. Using the cloud provider account login credentials, the example service provider 210, the example first tenant 212, and/or the example second tenant 214 can log into (e.g., sign-in to) the example cloud providers 202, 204, 206 and access cloud resources of the example cloud providers 202, 204, 206 without needing to create multiple different cloud provider account login credentials for each of the example service provider 210, the example first tenant 212, and the example second tenant 214 for each of the example cloud providers 202, 204, 206” [Ivanov ¶ 62].
With regard to claim 3, Jensen in view of Ivanov teaches the method of claim 1, as referenced above. Jensen further teaches:
wherein the resource-principal is associated with the link-resource object “In order to provide a better consumer experience within the hybrid cloud, a global identity context can be established for unique individuals and then a global identifier assigned to the individual can be mapped to the local identifiers utilized within the context of the individual service providers” [Jensen ¶ 26]. “A local identifier map (link-resource object) 540 associates each individual identifier with zero or more local identifiers (resource-principal). Each of the local identifiers can be provided to the IM App 150 by a corresponding service provider and mapped to an account established by that service provider” [Jensen ¶ 79].
and is assigned one or more permissions based on the token. “Returning now to FIG. 1A, the global identity platform can provide authentication and authorization capabilities to the consumer applications. In an embodiment, these capabilities can be provided through session tokens generated by the AM App 140. A session token refers to a packet of information (e.g., a data structure having a particular format) that represents an authorization to access a particular resource” [Jensen ¶ 39].
“The consume application 120 can utilize the token to request local identifiers associated with the global identity context for the user, where each local identifier can be used to access one or more APIs hosted by an API gateway 160 in order to provide the consumer application 120 with access to various services in the hybrid cloud that are authorized for the user” [Jensen ¶ 57].
With regard to claim 4, Jensen in view of Ivanov teaches the method of claim 1, as referenced above. Jensen fails to explicitly teach wherein the resource to be created in the first cloud infrastructure is a database and the service provided by the first cloud infrastructure is a database-as-a-service.
However, Ivanov teaches:
wherein the resource to be created in the first cloud infrastructure is a database “Cloud provisioning is the allocation of cloud provider resources to a customer when a cloud provider accepts a request from a customer. For example, the cloud provider creates a corresponding number of virtual machines and allocates resources (e.g., application servers, load balancers, network storage, databases, firewalls, IP addresses, virtual or local area networks, etc.) to support application operation” [Ivanov ¶ 28].
and the service provided by the first cloud infrastructure is a database-as-a-service. “Infrastructure-as-a-Service (also commonly referred to as IaaS) generally describes a suite of technologies provided by a service provider as an integrated solution to allow for elastic creation of a virtualized, networked, and pooled computing platform (sometimes referred to as a "cloud computing platform"). Enterprises may use IaaS as a business-internal organizational cloud computing platform that gives an application developer access to infrastructure resources, such as virtualized servers, storage, and networking resources” [Ivanov ¶ 29].
With regard to claim 6, Jensen in view of Ivanov teaches the method of claim 4, as referenced above. Jensen fails to teach wherein the database is one of: an Exa-database, a shared-autonomous database, a dedicated-autonomous database, or a virtual machine database.
However, Ivanov teaches wherein the database is one of: an Exa-database, a shared-autonomous database, a dedicated-autonomous database, or a virtual machine database. “Cloud provisioning is the allocation of cloud provider resources to a customer when a cloud provider accepts a request from a customer. For example, the cloud provider creates a corresponding number of virtual machines and allocates resources (e.g., application servers, load balancers, network storage, databases, firewalls, IP addresses, virtual or local area networks, etc.) to support application operation” [Ivanov ¶ 28]. “For example, if a first tenant 212 requests provisioning of cloud infrastructure resources as a virtual machine, the first tenant 212 is not aware of which specific cloud provider 202, 204, 206 provides the cloud infrastructure resources of the provisioned virtual machine” [Ivanov ¶ 66].
With regard to claim 10, Jensen teaches:
One or more computer readable non-transitory media storing computer-executable instructions that, when executed by one or more processors, cause: “In some embodiments, a non-transitory computer-readable medium storing instructions that, when executed by a processor, cause the processor to carry out the method” [Jensen ¶ 13].
receiving, by a multi-cloud infrastructure included in a first cloud infrastructure, “In an embodiment, the hybrid cloud provider (CSP) refers to an organization that manages the infrastructure or resources of at least a portion of the hybrid cloud (first cloud infrastructure). As an example, the hybrid cloud provider can manage the resources that provide a control plane (multi-cloud infrastructure) for various services to connect to and utilize various hybrid cloud capabilities” [Jensen ¶ 36].
a first request “The consumer applications 120, 130 can then be configured to generate API calls (request) that are transmitted from the consumer application 120, 130 to the identified API in a corresponding API gateway 160” [Jensen ¶ 35].
from a user associated with an account in a second cloud infrastructure, “For example, one service provider can establish an account for a person and assign that account a local identifier. A second service provider can also establish an account for the person and assign that account a different local identifier” [Jensen ¶ 25]. “Each service can be associated with user accounts that are mapped to local identifiers that identify a particular user within the context of that service… However, a single user may have different user accounts for different services. The user may have distinct credentials for each user account. Each user account can be associated with a local identifier that identifies the user account within the context of a specific service provider” [Jensen ¶ 1-2]. “In some embodiments, cloud service providers may develop consumer applications, such as a first consumer application 120, Consumer App A, and a second consumer application 130, Consumer App B. Although not shown explicitly in FIG. 1A, different cloud services providers can develop services that are hosted in one or more data centers. Each data center can be associated with one or more API gateways 160, and APIs for the services are deployed to the corresponding API gateways 160. The consumer applications 120, 130 can then be configured to generate API calls that are transmitted from the consumer application 120, 130 to the identified API in a corresponding API gateway 160” [Jensen ¶ 34-35].
validating, by the multi-cloud infrastructure, the user based on a token included in the first request, “In an embodiment, responsive to authentication ofa request for one or more local identifiers associatedvalidate) included in the sessionand transmit the one or more local identifiers to the first consumer application” [Jensen ¶ 8]. “In this manner, the payload of the session token cannot be read to obtain the individual identifier directly, but an entity that is aware of the individual identifier can verify the authenticity of the session token by checking the payload against a hashed version of the individual identifier” [Jensen ¶ 41]. “The client device 110 then sends an authentication request to the AM App 140 that includes credentials for the account associated with a user of the client device 110. The authentication engine 320 reads the credentials from the authentication engine 320 and verifies the credentials match credentials stored in the account directory 180” [Jensen ¶ 56].
the token being generated by the second cloud infrastructure; “In some embodiments, the session token is passed from the first consumer application (second cloud infrastructure) 120 to the second consumer application 130 when the initiation of the second consumer application 130 is caused by the first consumer application 120… For example, if a mobile application connected with the first consumer application 120 is re-directed to connect to a second consume application 130, then the first consumer application 120 may also share the session token with the second consumer application 130…” [Jensen ¶ 44]. “In an embodiment, responsive to authentication of the client device based on the credentials, the account management application is configured to transmit a user session token associated with a corresponding account to a first consumer application” [Jensen ¶ 8].
and responsive to successfully validating the user: obtaining a link-resource object previously created for the user, “In some embodiments, once the session token has been verified, the key-mapping module 530 is used to query the local identifier map (link-resource object) 540 to return one or more local identifiers corresponding to the individual identifier for the constituent” [Jensen ¶ 82].
“A global identifier associated with a global identity context is defined to identify unique individuals within the context of a cloud architecture. The global identity context matches multiple different accounts to a unique constituent corresponding to that global identity context and can be used to establish a link between different IT systems throughout the cloud” [Jensen ¶ 24].
the link-resource object including information linking a tenancy created for the user in the first cloud infrastructure to the account associated with the user in the second cloud infrastructure; “The individual identifier cannot be used to access the services, but the local identifier corresponding to a particular service is used to access the particular service. A local identifier map (link-resource object) 540 associates each individual identifier with zero or more local identifiers. Each of the local identifiers can be provided to the IM App 150 by a corresponding service provider and mapped to an account established by that service provider” [Jensen ¶ 79]. “In an embodiment, one or more accounts are mapped to an individual identifier for a unique constituent, and that individual identifier is mapped, by the IM App 150, to one or more local identifiers. As used herein, a local identifier can refer to an identifier (e.g., a UUID, a GUID, etc.) maintained by a cloud service provider as an identifier for the constituent within the context of a service provided by the cloud service provider. The cloud service provider does not have visibility to the individual identifier for the constituent within the context of the hybrid cloud” [Jensen ¶ 51]. “In order to provide a better consumer experience within the hybrid cloud, a global identity context can be established for unique individuals and then a global identifier assigned to the individual can be mapped to the local identifiers utilized within the context of the individual service providers” [Jensen ¶ 26].
accessing, using the link-resource object, a resource-principal previously created for the user; “In some embodiments, once the session token has been verified, the key-mapping module 530 is used to query the local identifier map 540 to return one or more local identifiers (resource-principal) corresponding to the individual identifier for the constituent. The one or more local identifiers are then transmitted to the consumer application 120 and can be used to connect to services in the hybrid cloud” [Jensen ¶ 82].
transmitting, by the multi-cloud infrastructure, a second request “The second consumer application (first cloud infrastructure) 130 is then permitted to access one or more services using the session token and the local identifier(s) without having to re-prompt the user for credentials associated with a user account” [Jensen ¶ 43]. “The consumer application 120 can then pass the session token and a corresponding local identifier to a corresponding service when making an API call (second request) to the service, which enables the consumer application 120 to access the service without requiring re-authentication at the service” [Jensen ¶ 42 Examiner notes that although this example is given for consumer application 120, the process would be the same for consumer application 130]. “Therefore, the individual identifier is used to access the local identifier for a service, which is then transmitted, along with a session token, together with an API call to allow a consumer application 120 to access the service through the account” [Jensen ¶ 90].
and wherein the second request includes the resource-principal; “The consumer application 120 can then pass the session token and a corresponding local identifier (resource-principal) to a corresponding service when making an API call (second request) to the service, which enables the consumer application 120 to access the service without requiring re-authentication at the service” [Jensen ¶ 42].
and deploying, by the multi-cloud infrastructure, a network link that communicatively couples the tenancy of the user in the first cloud infrastructure to the account of the user in the second cloud infrastructure, “A global identifier associated with a global identity context is defined to identify unique individuals within the context of a cloud architecture. The global identity context matches multiple different accounts to a unique constituent corresponding to that global identity context and can be used to establish a link between different IT systems throughout the cloud. For example, one service provider can establish an account for a person and assign that account a local identifier. A second service provider can also establish an account for the person and assign that account a different local identifier. Because the local identifiers are only understood within the context of services provided by the corresponding service providers, information related to the individual in one service cannot be linked to information related to the individual in the context of another service associated with a different service provider. In order to provide a better consumer experience within the hybrid cloud, a global identity context can be established for unique individuals and then a global identifier assigned to the individual can be mapped to the local identifiers utilized within the context of the individual service providers” [Jensen ¶ 24].
the network link facilitating the user to access the resource deployed in the first cloud infrastructure from the second cloud infrastructure. “However, a single user may have different user accounts for different services. The user may have distinct credentials for each user account. Each user account can be associated with a local identifier that identifies the user account within the context of a specific service provider” [Jensen ¶ 2]. “The service providers use local identifiers that are correlated with particular accounts within the context of one or more services. Therefore, the individual identifier is used to access the local identifier for a service, which is then transmitted, along with a session token, together with an API call to allow a consumer application 120 to access the service through the account” [Jensen ¶ 90]. “In some embodiments, cloud service providers may develop consumer applications, such as a first consumer application 120, Consumer App A, and a second consumer application 130, Consumer App B. The applications can utilize one or more network based services within the hybrid cloud network architecture. Although not shown explicitly in FIG. 1A, different cloud services providers can develop services that are hosted in one or more data centers. Each data center can be associated with one or more API gateways 160, and APIs for the services are deployed to the corresponding API gateways 160. The consumer applications 120, 130 can then be configured to generate API calls that are transmitted from the consumer application 120, 130 to the identified API in a corresponding API gateway 160. Since the consumer application 120, 130 may be hosted in a different data center than the corresponding API gateways 160, there is a need for the consumer applications 120, 130 to be authenticated by the API gateways 160. Furthermore, there is a need to authorize a single user of a client device 110 to access multiple APIs associated with services from multiple cloud service providers” [Jensen ¶ 35]. “The consumer application 120 can then pass the session token and a corresponding local identifier to a corresponding service when making an API call to the service, which enables the consumer application 120 to access the service without requiring re-authentication at the service” [Jensen ¶ 42]. “In some embodiments, the session token is passed from the first consumer application 120 to the second consumer application 130 when the initiation of the second consumer application 130 is caused by the first consumer application 120 … For example, if a mobile application connected with the first consumer application 120 is re-directed to connect to a second consume application 130, then the first consumer application 120 may also share the session token with the second consumer application 130 …” [Jensen ¶ 44].
Jensen fails to explicitly teach the first request requesting a resource to be created in the first cloud infrastructure; a second request to a service provided by the first cloud infrastructure, the second request requesting creation of the resource.
However, Ivanov teaches:
the first request requesting a resource to be created in the first cloud infrastructure; “Example 1 includes an apparatus to provision cloud infrastructure resources, the apparatus comprising provisioning circuitry to, in response to a first request from a tenant to access cloud infrastructure resources…” [Ivanov ¶ 197]. “In some examples, the example cloud provider interface circuitry 302 is used by (e.g., called from) the example first tenant 212 to generate a new layer of cloud infrastructure resource references to refer to the cloud infrastructure resources of the first cloud provider 202” [Ivanov ¶ 85]. “In the illustrated example, the vRealize Automation® cloud management platform 140 is a cloud management platform that can be used to build and manage a multi-vendor cloud infrastructure… In other examples, the example vRealize Automation® cloud management platform 140 may be offered as a Software as a Service (e.g., SaaS) wherein at least one instance of the vRealize Automation® cloud management platform 140 is deployed on a cloud provider (e.g., Amazon Web Services)” [Ivanov ¶ 50]. “In some examples, the example cloud provider interface circuitry 302 allows a direct connection to the cloud infrastructure resources of the example cloud providers 202, 204, 206 (e.g., VMware vSphere cloud provider, Microsoft Azure Cloud Services, Amazon Web Services (AWS), Google Cloud Platform, Alibaba Cloud, VMware vCloud Director cloud service delivery platform, etc.)” [Ivanov ¶ 83].
a second request to a service provided by the first cloud infrastructure, the second request requesting creation of the resource, “Example 1 includes an apparatus to provision cloud infrastructure resources, the apparatus comprising provisioning circuitry to, in response to a first request from a tenant to access cloud infrastructure resources, determine a type of a cloud account, cloud provider interface circuitry to, in response to the type of the cloud account being a cloud provider interface type, access service-provider-credentials, the cloud provider interface circuitry to retrieve a first access token based on the service-provider-credentials, submit a second request for the cloud infrastructure resources to a first cloud provider, the second request corresponding to the tenant impersonating the service provider based on the first access token” [Ivanov ¶ 197]. “Cloud provisioning is the allocation of cloud provider resources to a customer when a cloud provider accepts a request from a customer. For example, the cloud provider creates a corresponding number of virtual machines and allocates resources (e.g., application servers, load balancers, network storage, databases, firewalls, IP addresses, virtual or local area networks, etc.) to support application operation” [Ivanov ¶ 28].
Ivanov is considered to be analogous to the claimed invention because it is in the same field of protocols for authentication of entities. Jensen teaches a method for allowing a user working within an account in one cloud to link to their account on a different cloud and access cloud services through this link. This can be combined with the teachings of Ivanov which teaches a similar system wherein users can request the creation of resources within a multi-cloud environment. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jensen to incorporate the teachings of Ivanov and include the first request requesting a resource to be created in the first cloud infrastructure; a second request to a service provided by the first cloud infrastructure, the second request requesting creation of the resource. Doing so would allow for users to utilize the system to access resources of external services. “In such examples, a cloud may extend capabilities of an enterprise, for example, to deliver a specific business service through the addition of externally available public cloud services” [Ivanov ¶ 24].
With regard to claim 11, Jensen in view of Ivanov teaches the one or more computer readable non-transitory media storing computer-executable instructions of claim 10, as referenced above. Jensen further teaches:
wherein the link-resource object includes information linking the tenancy of the user in the first cloud infrastructure to the account of the user in the second cloud infrastructure, “The individual identifier cannot be used to access the services, but the local identifier corresponding to a particular service is used to access the particular service. A local identifier map (link-resource object) 540 associates each individual identifier with zero or more local identifiers. Each of the local identifiers can be provided to the IM App 150 by a corresponding service provider and mapped to an account established by that service provider” [Jensen ¶ 79]. “In an embodiment, one or more accounts are mapped to an individual identifier for a unique constituent, and that individual identifier is mapped, by the IM App 150, to one or more local identifiers. As used herein, a local identifier can refer to an identifier (e.g., a UUID, a GUID, etc.) maintained by a cloud service provider as an identifier for the constituent within the context of a service provided by the cloud service provider. The cloud service provider does not have visibility to the individual identifier for the constituent within the context of the hybrid cloud” [Jensen ¶ 51]. “In order to provide a better consumer experience within the hybrid cloud, a global identity context can be established for unique individuals and then a global identifier assigned to the individual can be mapped to the local identifiers utilized within the context of the individual service providers” [Jensen ¶ 26].
Jensen fails to explicitly teach the link-resource object being stored in a compartment of the tenancy of the user in the first cloud infrastructure.
However, Ivanov teaches the link-resource object being stored in a compartment of the tenancy of the user in the first cloud infrastructure. “The example cloud provider hub circuitry 180 is provided with a cloud credential database 230 and separate tenant credential databases 234, 236. The example cloud credential database 230 is provided to store cloud provider account login credentials registered with different ones of the cloud providers 202, 204, 206. Using the cloud provider account login credentials, the example service provider 210, the example first tenant 212, and/or the example second tenant 214 can log into (e.g., sign-in to) the example cloud providers 202, 204, 206 and access cloud resources of the example cloud providers 202, 204, 206 without needing to create multiple different cloud provider account login credentials for each of the example service provider 210, the example first tenant 212, and the example second tenant 214 for each of the example cloud providers 202, 204, 206” [Ivanov ¶ 62].
With regard to claim 12, Jensen in view of Ivanov teaches the one or more computer readable non-transitory media storing computer-executable instructions of claim 10, as referenced above. Jensen further teaches:
wherein the resource-principal is associated with the link-resource object “In order to provide a better consumer experience within the hybrid cloud, a global identity context can be established for unique individuals and then a global identifier assigned to the individual can be mapped to the local identifiers utilized within the context of the individual service providers” [Jensen ¶ 26]. “A local identifier map (link-resource object) 540 associates each individual identifier with zero or more local identifiers (resource-principal). Each of the local identifiers can be provided to the IM App 150 by a corresponding service provider and mapped to an account established by that service provider” [Jensen ¶ 79].
and is assigned one or more permissions based on the token. “Returning now to FIG. 1A, the global identity platform can provide authentication and authorization capabilities to the consumer applications. In an embodiment, these capabilities can be provided through session tokens generated by the AM App 140. A session token refers to a packet of information (e.g., a data structure having a particular format) that represents an authorization to access a particular resource” [Jensen ¶ 39].
“The consume application 120 can utilize the token to request local identifiers associated with the global identity context for the user, where each local identifier can be used to access one or more APIs hosted by an API gateway 160 in order to provide the consumer application 120 with access to various services in the hybrid cloud that are authorized for the user” [Jensen ¶ 57].
With regard to claim 13, Jensen in view of Ivanov teaches the one or more computer readable non-transitory media storing computer-executable instructions of claim 10, as referenced above. Jensen fails to explicitly teach wherein the resource to be created in the first cloud infrastructure is a database and the service provided by the first cloud infrastructure is a database-as-a-service.
However, Ivanov teaches:
wherein the resource to be created in the first cloud infrastructure is a database “Cloud provisioning is the allocation of cloud provider resources to a customer when a cloud provider accepts a request from a customer. For example, the cloud provider creates a corresponding number of virtual machines and allocates resources (e.g., application servers, load balancers, network storage, databases, firewalls, IP addresses, virtual or local area networks, etc.) to support application operation” [Ivanov ¶ 28].
and the service provided by the first cloud infrastructure is a database-as-a-service. “Infrastructure-as-a-Service (also commonly referred to as IaaS) generally describes a suite of technologies provided by a service provider as an integrated solution to allow for elastic creation of a virtualized, networked, and pooled computing platform (sometimes referred to as a "cloud computing platform"). Enterprises may use IaaS as a business-internal organizational cloud computing platform that gives an application developer access to infrastructure resources, such as virtualized servers, storage, and networking resources” [Ivanov ¶ 29].
With regard to claim 15, Jensen in view of Ivanov teaches the one or more computer readable non-transitory media storing computer-executable instructions of claim 13, as referenced above. Jensen fails to teach wherein the database is one of: an Exa-database, a shared-autonomous database, a dedicated-autonomous database, or a virtual machine database.
However, Ivanov teaches wherein the database is one of: an Exa-database, a shared-autonomous database, a dedicated-autonomous database, or a virtual machine database. “Cloud provisioning is the allocation of cloud provider resources to a customer when a cloud provider accepts a request from a customer. For example, the cloud provider creates a corresponding number of virtual machines and allocates resources (e.g., application servers, load balancers, network storage, databases, firewalls, IP addresses, virtual or local area networks, etc.) to support application operation” [Ivanov ¶ 28]. “For example, if a first tenant 212 requests provisioning of cloud infrastructure resources as a virtual machine, the first tenant 212 is not aware of which specific cloud provider 202, 204, 206 provides the cloud infrastructure resources of the provisioned virtual machine” [Ivanov ¶ 66].
With regard to claim 17, Jensen in view of Ivanov teaches the one or more computer readable non-transitory media storing computer- executable instructions of claim 13, as referenced above. Jensen further teaches further comprising instructions that, when executed by one or more processors, cause: creating, by the multi-cloud infrastructure, a network link that communicatively couples the tenancy of the user in the first cloud infrastructure to the account of the user in the second cloud infrastructure. “In an embodiment, the network 100 is a wide area network (WAN) such as the Internet. Portions of the network 100 can be implemented as local area networks (LANs) implemented across one or more regions. The network 100 can include one or more data centers comprising processing and storage resources …Each server device can also include a network interface for communicating with other devices within the network 100” [Jensen ¶ 32, Fig. 1A Examiner notes the consumer applications 120 and 130 within network 100].
With regard to claim 19, Jensen teaches:
A computing device comprising: one or more processors; and a memory including instructions that, when executed with the one or more processors, cause the computing device to, at least: “The computer system 700 includes a processor 702, a non-volatile memory 704, and a network interface controller (NIC) 720. The processor 702 can execute instructions that cause the computer system 700 to implement the functionality of various elements of the system described above” [Jensen¶ 91].
receive, by a multi-cloud infrastructure included in a first cloud infrastructure, “In an embodiment, the hybrid cloud provider (CSP) refers to an organization that manages the infrastructure or resources of at least a portion of the hybrid cloud (first cloud infrastructure). As an example, the hybrid cloud provider can manage the resources that provide a control plane (multi-cloud infrastructure) for various services to connect to and utilize various hybrid cloud capabilities” [Jensen ¶ 36].
a first request “The consumer applications 120, 130 can then be configured to generate API calls (request) that are transmitted from the consumer application 120, 130 to the identified API in a corresponding API gateway 160” [Jensen ¶ 35].
from a user associated with an account in a second cloud infrastructure, “For example, one service provider can establish an account for a person and assign that account a local identifier. A second service provider can also establish an account for the person and assign that account a different local identifier” [Jensen ¶ 25]. “Each service can be associated with user accounts that are mapped to local identifiers that identify a particular user within the context of that service… However, a single user may have different user accounts for different services. The user may have distinct credentials for each user account. Each user account can be associated with a local identifier that identifies the user account within the context of a specific service provider” [Jensen ¶ 1-2]. “In some embodiments, cloud service providers may develop consumer applications, such as a first consumer application 120, Consumer App A, and a second consumer application 130, Consumer App B. Although not shown explicitly in FIG. 1A, different cloud services providers can develop services that are hosted in one or more data centers. Each data center can be associated with one or more API gateways 160, and APIs for the services are deployed to the corresponding API gateways 160. The consumer applications 120, 130 can then be configured to generate API calls that are transmitted from the consumer application 120, 130 to the identified API in a corresponding API gateway 160” [Jensen ¶ 34-35].
validate, by the multi-cloud infrastructure, the user based on a token included in the first request, “In an embodiment, responsive to authentication ofa request for one or more local identifiers associatedvalidate) included in the sessionand transmit the one or more local identifiers to the first consumer application” [Jensen ¶ 8]. “In this manner, the payload of the session token cannot be read to obtain the individual identifier directly, but an entity that is aware of the individual identifier can verify the authenticity of the session token by checking the payload against a hashed version of the individual identifier” [Jensen ¶ 41]. “The client device 110 then sends an authentication request to the AM App 140 that includes credentials for the account associated with a user of the client device 110. The authentication engine 320 reads the credentials from the authentication engine 320 and verifies the credentials match credentials stored in the account directory 180” [Jensen ¶ 56].
the token being generated by the second cloud infrastructure; “In some embodiments, the session token is passed from the first consumer application (second cloud infrastructure) 120 to the second consumer application 130 when the initiation of the second consumer application 130 is caused by the first consumer application 120… For example, if a mobile application connected with the first consumer application 120 is re-directed to connect to a second consume application 130, then the first consumer application 120 may also share the session token with the second consumer application 130…” [Jensen ¶ 44]. “In an embodiment, responsive to authentication of the client device based on the credentials, the account management application is configured to transmit a user session token associated with a corresponding account to a first consumer application” [Jensen ¶ 8].
and responsive to successfully validating the user: obtain a link-resource object previously created for the user, “In some embodiments, once the session token has been verified, the key-mapping module 530 is used to query the local identifier map (link-resource object) 540 to return one or more local identifiers corresponding to the individual identifier for the constituent” [Jensen ¶ 82].
“A global identifier associated with a global identity context is defined to identify unique individuals within the context of a cloud architecture. The global identity context matches multiple different accounts to a unique constituent corresponding to that global identity context and can be used to establish a link between different IT systems throughout the cloud” [Jensen ¶ 24].
the link-resource object including information linking a tenancy created for the user in the first cloud infrastructure to the account associated with the user in the second cloud infrastructure; “The individual identifier cannot be used to access the services, but the local identifier corresponding to a particular service is used to access the particular service. A local identifier map (link-resource object) 540 associates each individual identifier with zero or more local identifiers. Each of the local identifiers can be provided to the IM App 150 by a corresponding service provider and mapped to an account established by that service provider” [Jensen ¶ 79]. “In an embodiment, one or more accounts are mapped to an individual identifier for a unique constituent, and that individual identifier is mapped, by the IM App 150, to one or more local identifiers. As used herein, a local identifier can refer to an identifier (e.g., a UUID, a GUID, etc.) maintained by a cloud service provider as an identifier for the constituent within the context of a service provided by the cloud service provider. The cloud service provider does not have visibility to the individual identifier for the constituent within the context of the hybrid cloud” [Jensen ¶ 51]. “In order to provide a better consumer experience within the hybrid cloud, a global identity context can be established for unique individuals and then a global identifier assigned to the individual can be mapped to the local identifiers utilized within the context of the individual service providers” [Jensen ¶ 26].
access, using the link-resource object, a resource-principal previously created for the user; “In some embodiments, once the session token has been verified, the key-mapping module 530 is used to query the local identifier map 540 to return one or more local identifiers (resource-principal) corresponding to the individual identifier for the constituent. The one or more local identifiers are then transmitted to the consumer application 120 and can be used to connect to services in the hybrid cloud” [Jensen ¶ 82].
transmit, by the multi-cloud infrastructure, a second request “The second consumer application (first cloud infrastructure) 130 is then permitted to access one or more services using the session token and the local identifier(s) without having to re-prompt the user for credentials associated with a user account” [Jensen ¶ 43]. “The consumer application 120 can then pass the session token and a corresponding local identifier to a corresponding service when making an API call (second request) to the service, which enables the consumer application 120 to access the service without requiring re-authentication at the service” [Jensen ¶ 42 Examiner notes that although this example is given for consumer application 120, the process would be the same for consumer application 130]. “Therefore, the individual identifier is used to access the local identifier for a service, which is then transmitted, along with a session token, together with an API call to allow a consumer application 120 to access the service through the account” [Jensen ¶ 90].
wherein the second request includes the resource-principal; “The consumer application 120 can then pass the session token and a corresponding local identifier (resource-principal) to a corresponding service when making an API call (second request) to the service, which enables the consumer application 120 to access the service without requiring re-authentication at the service” [Jensen ¶ 42].
and deploying, by the multi-cloud infrastructure, a network link that communicatively couples the tenancy of the user in the first cloud infrastructure to the account of the user in the second cloud infrastructure, “A global identifier associated with a global identity context is defined to identify unique individuals within the context of a cloud architecture. The global identity context matches multiple different accounts to a unique constituent corresponding to that global identity context and can be used to establish a link between different IT systems throughout the cloud. For example, one service provider can establish an account for a person and assign that account a local identifier. A second service provider can also establish an account for the person and assign that account a different local identifier. Because the local identifiers are only understood within the context of services provided by the corresponding service providers, information related to the individual in one service cannot be linked to information related to the individual in the context of another service associated with a different service provider. In order to provide a better consumer experience within the hybrid cloud, a global identity context can be established for unique individuals and then a global identifier assigned to the individual can be mapped to the local identifiers utilized within the context of the individual service providers” [Jensen ¶ 24].
the network link facilitating the user to access the resource deployed in the first cloud infrastructure from the second cloud infrastructure. “However, a single user may have different user accounts for different services. The user may have distinct credentials for each user account. Each user account can be associated with a local identifier that identifies the user account within the context of a specific service provider” [Jensen ¶ 2]. “The service providers use local identifiers that are correlated with particular accounts within the context of one or more services. Therefore, the individual identifier is used to access the local identifier for a service, which is then transmitted, along with a session token, together with an API call to allow a consumer application 120 to access the service through the account” [Jensen ¶ 90]. “In some embodiments, cloud service providers may develop consumer applications, such as a first consumer application 120, Consumer App A, and a second consumer application 130, Consumer App B. The applications can utilize one or more network based services within the hybrid cloud network architecture. Although not shown explicitly in FIG. 1A, different cloud services providers can develop services that are hosted in one or more data centers. Each data center can be associated with one or more API gateways 160, and APIs for the services are deployed to the corresponding API gateways 160. The consumer applications 120, 130 can then be configured to generate API calls that are transmitted from the consumer application 120, 130 to the identified API in a corresponding API gateway 160. Since the consumer application 120, 130 may be hosted in a different data center than the corresponding API gateways 160, there is a need for the consumer applications 120, 130 to be authenticated by the API gateways 160. Furthermore, there is a need to authorize a single user of a client device 110 to access multiple APIs associated with services from multiple cloud service providers” [Jensen ¶ 35]. “The consumer application 120 can then pass the session token and a corresponding local identifier to a corresponding service when making an API call to the service, which enables the consumer application 120 to access the service without requiring re-authentication at the service” [Jensen ¶ 42]. “In some embodiments, the session token is passed from the first consumer application 120 to the second consumer application 130 when the initiation of the second consumer application 130 is caused by the first consumer application 120 … For example, if a mobile application connected with the first consumer application 120 is re-directed to connect to a second consume application 130, then the first consumer application 120 may also share the session token with the second consumer application 130 …” [Jensen ¶ 44].
Jensen fails to explicitly teach the first request requesting a resource to be created in the first cloud infrastructure; a second request to a service provided by the first cloud infrastructure, the second request requesting creation of the resource.
However, Ivanov teaches:
the first request requesting a resource to be created in the first cloud infrastructure; “Example 1 includes an apparatus to provision cloud infrastructure resources, the apparatus comprising provisioning circuitry to, in response to a first request from a tenant to access cloud infrastructure resources…” [Ivanov ¶ 197]. “In some examples, the example cloud provider interface circuitry 302 is used by (e.g., called from) the example first tenant 212 to generate a new layer of cloud infrastructure resource references to refer to the cloud infrastructure resources of the first cloud provider 202” [Ivanov ¶ 85]. “In the illustrated example, the vRealize Automation® cloud management platform 140 is a cloud management platform that can be used to build and manage a multi-vendor cloud infrastructure… In other examples, the example vRealize Automation® cloud management platform 140 may be offered as a Software as a Service (e.g., SaaS) wherein at least one instance of the vRealize Automation® cloud management platform 140 is deployed on a cloud provider (e.g., Amazon Web Services)” [Ivanov ¶ 50]. “In some examples, the example cloud provider interface circuitry 302 allows a direct connection to the cloud infrastructure resources of the example cloud providers 202, 204, 206 (e.g., VMware vSphere cloud provider, Microsoft Azure Cloud Services, Amazon Web Services (AWS), Google Cloud Platform, Alibaba Cloud, VMware vCloud Director cloud service delivery platform, etc.)” [Ivanov ¶ 83].
a second request to a service provided by the first cloud infrastructure, the second request requesting creation of the resource, “Example 1 includes an apparatus to provision cloud infrastructure resources, the apparatus comprising provisioning circuitry to, in response to a first request from a tenant to access cloud infrastructure resources, determine a type of a cloud account, cloud provider interface circuitry to, in response to the type of the cloud account being a cloud provider interface type, access service-provider-credentials, the cloud provider interface circuitry to retrieve a first access token based on the service-provider-credentials, submit a second request for the cloud infrastructure resources to a first cloud provider, the second request corresponding to the tenant impersonating the service provider based on the first access token” [Ivanov ¶ 197]. “Cloud provisioning is the allocation of cloud provider resources to a customer when a cloud provider accepts a request from a customer. For example, the cloud provider creates a corresponding number of virtual machines and allocates resources (e.g., application servers, load balancers, network storage, databases, firewalls, IP addresses, virtual or local area networks, etc.) to support application operation” [Ivanov ¶ 28].
Ivanov is considered to be analogous to the claimed invention because it is in the same field of protocols for authentication of entities. Jensen teaches a method for allowing a user working within an account in one cloud to link to their account on a different cloud and access cloud services through this link. This can be combined with the teachings of Ivanov which teaches a similar system wherein users can request the creation of resources within a multi-cloud environment. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jensen to incorporate the teachings of Ivanov and include the first request requesting a resource to be created in the first cloud infrastructure; a second request to a service provided by the first cloud infrastructure, the second request requesting creation of the resource. Doing so would allow for users to utilize the system to access resources of external services. “In such examples, a cloud may extend capabilities of an enterprise, for example, to deliver a specific business service through the addition of externally available public cloud services” [Ivanov ¶ 24].
With regard to claim 20, Jensen in view of Ivanov teaches the computing device of claim 19, as referenced above. Jensen further teaches wherein the first cloud infrastructure is provided by a first cloud services provider (CSP), and the second cloud infrastructure is provided by a second CSP, the second CSP being different than the first CSP. “For example, one service provider can establish an account for a person and assign that account a local identifier. A second service provider can also establish an account for the person and assign that account a different local identifier” [Jensen ¶ 25].
“It will be appreciated that the individualization procedure described above is merely one example of an automatic process for creating a global identity context for unique constituents based on transaction records created by a variety of different service providers by matching the transaction records based on demographic information. The individualization procedure not only creates new individual identifiers when needed, but maps new account identifiers within the context of different service providers to an existing global identity context having a single individual identifier within the entire scope of the hybrid cloud” [Jensen ¶ 78].
Claims 5, 7, 14, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Jensen (US 2021/0165871 A1) in view of Ivanov (US 2023/0239301 A1) in view of Durand (US 2023/0177201 A1).
With regard to claim 5, Jensen in view of Ivanov teaches the method of claim 4, as referenced above. Jensen further teaches the resource-principal associated with the link-resource object from the cloud-link adaptor “In some embodiments, once the session token has been verified, the key-mapping module 530 is used to query the local identifier map (link-resource object) 540 to return one or more local identifiers (resource-principal) corresponding to the individual identifier for the constituent. The one or more local identifiers are then transmitted to the consumer application 120 and can be used to connect to services in the hybrid cloud” [Jensen ¶ 82]. “The consumer application 120 can then pass the session token and a corresponding local identifier (resource-principal) to a corresponding service when making an API call to the service, which enables the consumer application 120 to access the service without requiring re-authentication at the service” [Jensen ¶ 42].
Jensen fails to teach wherein the multi-cloud infrastructure includes a database adaptor and a cloud-link adaptor, and wherein the database adaptor receives the resource-principal associated with the link-resource object from the cloud-link adaptor and transmits the resource-principal to the database-as-a-service.
However, Ivanov teaches:
wherein the multi-cloud infrastructure includes a database adaptor “In some examples, the vRealize Automation® cloud management platform 140 includes adapters to access (e.g., integrate with) the example cloud providers. For example, the vRealize Automation® cloud management platform 140 may include adapters for Microsoft Azure Cloud Services, Amazon Web Services, Google Cloud Platform, VMware vSphere cloud provider, Alibaba Cloud, and VMware vCloud Director cloud service delivery platform. The example cloud providers 202, 204, 206 use different methods of cloud provisioning. To interact with the cloud providers 202, 204, 206 using their respective cloud provisioning methods, the example vRealize Automation® cloud management platform 140 uses multiple different cloud provider-specific adapters for the individual cloud providers 202, 204, 206” [Ivanov ¶ 60].
and a cloud-link adaptor, “The example cloud-agnostic interface adapter (cloud-link adaptor) 228 is configured to allow example tenants 212, 214 to communicate with the example cloud provider circuitry 170 so that the example tenants 212, 214 can access the example cloud providers 202, 204, 206 via corresponding ones of the cloud-specific adapters 222, 224, 226” [Ivanov ¶ 61].
and wherein the database adaptor receives the resource-principal associated with the link-resource object from the cloud-link adaptor and transmits the resource-principal to the database-as-a-service. “The example vRealize Automation® cloud management platform 140 also includes a cloud-agnostic interface adapter 228 (shown in FIG. 2), which is a self-referential adapter. As used herein, a self-referential adapter is an adapter that, in response to a provisioning request, references the example vRealize Automation® cloud management platform 140 and the example cloud provider circuitry 170, before referencing other cloud-specific adapters 222, 224, 226 for provisioning of cloud infrastructure resources” [Ivanov ¶ 61]. “By allowing the example tenants 212, 214 access to the example cloud-agnostic interface adapter 228, the example service provider 210 allows the example tenants 212, 214 access to the first cloud provider 202, the second cloud provider 204, and the third cloud provider 206 via corresponding ones of the first cloud-specific adapter 222, the second cloud-specific adapter 224, and the third cloud-specific adapter 226 without requiring the tenants 212, 214 to possess information, software, or methods to directly communicate with the first cloud-specific adapter 222, the second cloud-specific adapter 224, and the third cloud-specific adapter 226” [Ivanov ¶ 61]. “…the cloud provider interface circuitry to retrieve a first access token based on the service-provider-credentials, submit a second request for the cloud infrastructure resources to a first cloud provider, the second request corresponding to the tenant impersonating the service provider based on the first access token” [Ivanov ¶ 197].
Jensen in view of Ivanov fails to teach wherein the multi-cloud infrastructure includes a database adaptor.
However, Durand teaches:
wherein the multi-cloud infrastructure includes a database adaptor “In a multi-tenant RDBMS service, the authorization interceptor determines the tenant who is making the database request and then is able to either apply the security policy for the specific tenant (e.g., when policy evaluation is performed in the RDBMS) or the request context sent to a policy management service encodes the tenant information… A database management system (database adaptor) may comprise a query processor 604. Query processor 604 may be a component of a database management system that is used to interpret requests (e.g., queries) received from end user via an application program into instructions” [Durand ¶ 90-91].
Durand is considered to be analogous to the claimed invention because it is in the same field of protocols for authentication of entities. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jensen to incorporate the teachings of Ivanov and include that the multi-cloud infrastructure includes a database adaptor. Doing so would allow for further security control of the cloud services. “For example, an operating system may have various permissions associated with various OS-level users, a database system may allow database administrators to grant and revoke security privileges on database resources to specific users and roles, and so forth” [Durand ¶ 2].
With regard to claim 7, Jensen in view of Ivanov teaches the method of claim 1, as referenced above. Jensen fails to teach wherein the validating includes: obtaining a role associated with the user in the second cloud infrastructure based on the token; identifying one or more tasks/operations associated with the role; and determining, based on the one or more tasks/operations, whether the user is permitted to issue the first request.
However, Ivanov teaches:
wherein the validating includes: obtaining a role (zone) associated with the user in the second cloud infrastructure based on the token; “To determine the cloud zone (e.g., one of the cloud providers 202, 204, 206) in which the virtual machine is to be provisioned, the example provisioning circuitry 160 checks for which cloud zone is identified in a project of the first tenant 212. For example, each tenant 212, 214 is associated with one or more projects, and each project is assigned one or more cloud zones (e.g., each cloud zone is implemented by one of the cloud providers 202, 204, 206)” [Ivanov ¶ 79].
identifying one or more tasks/operations associated with the role; “The example tenants 212, 214 are able to use the cloud infrastructure resources, according to the guardrails set by the example service provider 210 without modifying the underlying cloud infrastructure resources to suit the needs of the example tenants 212, 214. As used herein, "guardrails" are resource-to-tenant definitions that specify which resources from which cloud providers 202, 204, 206 are accessible by different tenants 212, 214” [Ivanov ¶ 65]. “To determine the cloud zone (e.g., one of the cloud providers 202, 204, 206) in which the virtual machine is to be provisioned, the example provisioning circuitry 160 checks for which cloud zone is identified in a project of the first tenant 212. For example, each tenant 212, 214 is associated with one or more projects (tasks/operations), and each project is assigned one or more cloud zones (e.g., each cloud zone is implemented by one of the cloud providers 202, 204, 206)” [Ivanov ¶ 79].
and determining, based on the one or more tasks/operations, whether the user is permitted to issue the first request. “For example, a particular project for a tenant 212, 214 can be bound to accessing cloud resources from a particular one or more of the cloud providers 202, 204, 206 (e.g., cloud zones) enumerated as part of that project. Such an example project-based guardrail is shown in the first row above of the cloud credential database 230 in which the "project" field is set to "3", meaning that the tenant account for the first tenant 212 is bound to accessing cloud resources in cloud zones associated with project 3” [Ivanov ¶ 79]. “For example, if the tenants 212, 214 desire access to a fourth cloud provider not selected by the example service provider 210, the guardrails set by the example service provider 210 restrict the example tenants 212, 214 from using resources from the fourth cloud provider. In another example restriction that may be imposed by guardrails, if the service provider 210 exposes a first instance type of one gigabyte of random access memory (RAM) and two central processing units (CPUs) to the example tenants 212, 214, the example tenants 212, 214 are unable to modify the exposed first instance type to a second instance type of two gigabytes of RAM and four CPUs” [Ivanov ¶ 65]. “In some examples, the policy management circuitry 308 may determine to grant the example first tenant 212 access based on the example cloud provider interface circuitry 302 accessing an infrastructure resource identifier from the request and comparing the identifier to infrastructure resource identifiers stored in a database to determine whether the infrastructure resource identified by the request is accessible by the first tenant 212 according to the guardrails set by the example service provider 210” [Ivanov ¶ 154].
Jensen in view of Ivanov fails to explicitly teach obtaining a role associated with the user in the second cloud infrastructure based on the token.
However, Durand teaches:
obtaining a role associated with the user in the second cloud infrastructure based on the token; “Determining a request context may involve determining a principal, a resource, and an action. A principal may refer to the entity that is requesting a specific action to be performed. The principal may be an OS-level user, a role that a user may assume by receiving a time-sensitive token from a computing resource service provider that has certain rights associated with it, and so forth” [Durand ¶ 82].
With regard to claim 14, Jensen in view of Ivanov teaches the one or more computer readable non-transitory media storing computer-executable instructions of claim 13, as referenced above. Jensen further teaches the resource-principal associated with the link-resource object from the cloud-link adaptor “In some embodiments, once the session token has been verified, the key-mapping module 530 is used to query the local identifier map (link-resource object) 540 to return one or more local identifiers (resource-principal) corresponding to the individual identifier for the constituent. The one or more local identifiers are then transmitted to the consumer application 120 and can be used to connect to services in the hybrid cloud” [Jensen ¶ 82]. “The consumer application 120 can then pass the session token and a corresponding local identifier (resource-principal) to a corresponding service when making an API call to the service, which enables the consumer application 120 to access the service without requiring re-authentication at the service” [Jensen ¶ 42].
Jensen fails to teach wherein the multi-cloud infrastructure includes a database adaptor and a cloud-link adaptor, and wherein the database adaptor receives the resource-principal associated with the link-resource object from the cloud-link adaptor and transmits the resource-principal to the database-as-a-service.
However, Ivanov teaches:
wherein the multi-cloud infrastructure includes a database adaptor “In some examples, the vRealize Automation® cloud management platform 140 includes adapters to access (e.g., integrate with) the example cloud providers. For example, the vRealize Automation® cloud management platform 140 may include adapters for Microsoft Azure Cloud Services, Amazon Web Services, Google Cloud Platform, VMware vSphere cloud provider, Alibaba Cloud, and VMware vCloud Director cloud service delivery platform. The example cloud providers 202, 204, 206 use different methods of cloud provisioning. To interact with the cloud providers 202, 204, 206 using their respective cloud provisioning methods, the example vRealize Automation® cloud management platform 140 uses multiple different cloud provider-specific adapters for the individual cloud providers 202, 204, 206” [Ivanov ¶ 60].
and a cloud-link adaptor, “The example cloud-agnostic interface adapter (cloud-link adaptor) 228 is configured to allow example tenants 212, 214 to communicate with the example cloud provider circuitry 170 so that the example tenants 212, 214 can access the example cloud providers 202, 204, 206 via corresponding ones of the cloud-specific adapters 222, 224, 226” [Ivanov ¶ 61].
and wherein the database adaptor receives the resource-principal associated with the link-resource object from the cloud-link adaptor and transmits the resource-principal to the database-as-a-service. “The example vRealize Automation® cloud management platform 140 also includes a cloud-agnostic interface adapter 228 (shown in FIG. 2), which is a self-referential adapter. As used herein, a self-referential adapter is an adapter that, in response to a provisioning request, references the example vRealize Automation® cloud management platform 140 and the example cloud provider circuitry 170, before referencing other cloud-specific adapters 222, 224, 226 for provisioning of cloud infrastructure resources” [Ivanov ¶ 61]. “By allowing the example tenants 212, 214 access to the example cloud-agnostic interface adapter 228, the example service provider 210 allows the example tenants 212, 214 access to the first cloud provider 202, the second cloud provider 204, and the third cloud provider 206 via corresponding ones of the first cloud-specific adapter 222, the second cloud-specific adapter 224, and the third cloud-specific adapter 226 without requiring the tenants 212, 214 to possess information, software, or methods to directly communicate with the first cloud-specific adapter 222, the second cloud-specific adapter 224, and the third cloud-specific adapter 226” [Ivanov ¶ 61]. “…the cloud provider interface circuitry to retrieve a first access token based on the service-provider-credentials, submit a second request for the cloud infrastructure resources to a first cloud provider, the second request corresponding to the tenant impersonating the service provider based on the first access token” [Ivanov ¶ 197].
Jensen in view of Ivanov fails to teach wherein the multi-cloud infrastructure includes a database adaptor.
However, Durand teaches:
wherein the multi-cloud infrastructure includes a database adaptor “In a multi-tenant RDBMS service, the authorization interceptor determines the tenant who is making the database request and then is able to either apply the security policy for the specific tenant (e.g., when policy evaluation is performed in the RDBMS) or the request context sent to a policy management service encodes the tenant information… A database management system (database adaptor) may comprise a query processor 604. Query processor 604 may be a component of a database management system that is used to interpret requests (e.g., queries) received from end user via an application program into instructions” [Durand ¶ 90-91].
Durand is considered to be analogous to the claimed invention because it is in the same field of protocols for authentication of entities. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jensen to incorporate the teachings of Ivanov and include that the multi-cloud infrastructure includes a database adaptor. Doing so would allow for further security control of the cloud services. “For example, an operating system may have various permissions associated with various OS-level users, a database system may allow database administrators to grant and revoke security privileges on database resources to specific users and roles, and so forth” [Durand ¶ 2].
With regard to claim 16, Jensen in view of Ivanov teaches the one or more computer readable non-transitory media storing computer-executable instructions of claim 13, as referenced above. Jensen fails to teach wherein the validating includes: obtaining a role associated with the user in the second cloud infrastructure based on the token; identifying one or more tasks/operations associated with the role; and determining, based on the one or more tasks/operations, whether the user is permitted to issue the first request.
However, Ivanov teaches:
wherein the validating includes: obtaining a role (zone) associated with the user in the second cloud infrastructure based on the token; “To determine the cloud zone (e.g., one of the cloud providers 202, 204, 206) in which the virtual machine is to be provisioned, the example provisioning circuitry 160 checks for which cloud zone is identified in a project of the first tenant 212. For example, each tenant 212, 214 is associated with one or more projects, and each project is assigned one or more cloud zones (e.g., each cloud zone is implemented by one of the cloud providers 202, 204, 206)” [Ivanov ¶ 79].
identifying one or more tasks/operations associated with the role; “The example tenants 212, 214 are able to use the cloud infrastructure resources, according to the guardrails set by the example service provider 210 without modifying the underlying cloud infrastructure resources to suit the needs of the example tenants 212, 214. As used herein, "guardrails" are resource-to-tenant definitions that specify which resources from which cloud providers 202, 204, 206 are accessible by different tenants 212, 214” [Ivanov ¶ 65]. “To determine the cloud zone (e.g., one of the cloud providers 202, 204, 206) in which the virtual machine is to be provisioned, the example provisioning circuitry 160 checks for which cloud zone is identified in a project of the first tenant 212. For example, each tenant 212, 214 is associated with one or more projects (tasks/operations), and each project is assigned one or more cloud zones (e.g., each cloud zone is implemented by one of the cloud providers 202, 204, 206)” [Ivanov ¶ 79].
and determining, based on the one or more tasks/operations, whether the user is permitted to issue the first request. “For example, a particular project for a tenant 212, 214 can be bound to accessing cloud resources from a particular one or more of the cloud providers 202, 204, 206 (e.g., cloud zones) enumerated as part of that project. Such an example project-based guardrail is shown in the first row above of the cloud credential database 230 in which the "project" field is set to "3", meaning that the tenant account for the first tenant 212 is bound to accessing cloud resources in cloud zones associated with project 3” [Ivanov ¶ 79]. “For example, if the tenants 212, 214 desire access to a fourth cloud provider not selected by the example service provider 210, the guardrails set by the example service provider 210 restrict the example tenants 212, 214 from using resources from the fourth cloud provider. In another example restriction that may be imposed by guardrails, if the service provider 210 exposes a first instance type of one gigabyte of random access memory (RAM) and two central processing units (CPUs) to the example tenants 212, 214, the example tenants 212, 214 are unable to modify the exposed first instance type to a second instance type of two gigabytes of RAM and four CPUs” [Ivanov ¶ 65]. “In some examples, the policy management circuitry 308 may determine to grant the example first tenant 212 access based on the example cloud provider interface circuitry 302 accessing an infrastructure resource identifier from the request and comparing the identifier to infrastructure resource identifiers stored in a database to determine whether the infrastructure resource identified by the request is accessible by the first tenant 212 according to the guardrails set by the example service provider 210” [Ivanov ¶ 154].
Jensen in view of Ivanov fails to explicitly teach obtaining a role associated with the user in the second cloud infrastructure based on the token.
However, Durand teaches:
obtaining a role associated with the user in the second cloud infrastructure based on the token; “Determining a request context may involve determining a principal, a resource, and an action. A principal may refer to the entity that is requesting a specific action to be performed. The principal may be an OS-level user, a role that a user may assume by receiving a time-sensitive token from a computing resource service provider that has certain rights associated with it, and so forth” [Durand ¶ 82].
Claims 9 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Jensen (US 2021/0165871 A1) in view of Ivanov (US 2023/0239301 A1) in view of Sekharan (US 10,686,887 B2).
With regard to claim 9, Jensen in view of Ivanov teaches the method of claim 1, as referenced above. Jensen further teaches an application that is executed in the second cloud infrastructure. “In some embodiments, cloud service providers may develop consumer applications, such as a first consumer application 120 (second cloud infrastructure), Consumer App A, and a second consumer application 130, Consumer App B” [Jensen ¶ 34].
Jensen in view of Ivanov fails to explicitly teach further comprising: providing, by the multi-cloud infrastructure, a web-link to the resource created in the first cloud infrastructure to the second cloud infrastructure, the web-link being displayed in an application.
However, Sekharan teaches:
further comprising: providing, by the multi-cloud infrastructure, a web-link to the resource created in the first cloud infrastructure to the second cloud infrastructure, the web-link being displayed in an application “…establishing, through a second page of the web browser application, a bidirectional communication channel with a service instance hosted on a second domain of the cloud computing system, the second page of the web browser application (web-link) embedded in the first page of the web browser application and configured to retrieve and display information resources hosted on the second domain (first cloud infrastructure)…” [Sekharan claim 1].
Sekharan is considered to be analogous to the claimed invention because it is in the same field of network arrangements for supporting services. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jensen in view of Ivanov to incorporate the teachings of Sekharan and include providing, by the multi-cloud infrastructure, a web-link to the resource created in the first cloud infrastructure to the second cloud infrastructure, the web-link being displayed in an application. Doing so would allow for the user to easily access a resource in a different cloud infrastructure. “The instructions also cause the at least one processing unit to receive data for the collaboration session 10 through the first page of the web browser application” [Sekharan Col. 3 Lines 9-11].
With regard to claim 18, Jensen in view of Ivanov teaches the one or more computer readable non-transitory media storing computer-executable instructions of claim 10, as referenced above. Jensen further teaches an application that is executed in the second cloud infrastructure. “In some embodiments, cloud service providers may develop consumer applications, such as a first consumer application 120 (second cloud infrastructure), Consumer App A, and a second consumer application 130, Consumer App B” [Jensen ¶ 34].
Jensen in view of Ivanov fails to explicitly teach further comprising instructions that, when executed by one or more processors, cause: providing, by the multi-cloud infrastructure, a web-link to the resource created in the first cloud infrastructure to the second cloud infrastructure, the web-link being displayed in an application.
However, Sekharan teaches:
further comprising instructions that, when executed by one or more processors, cause: further comprising: providing, by the multi-cloud infrastructure, a web-link to the resource created in the first cloud infrastructure to the second cloud infrastructure, the web-link being displayed in an application “…establishing, through a second page of the web browser application, a bidirectional communication channel with a service instance hosted on a second domain of the cloud computing system, the second page of the web browser application (web-link) embedded in the first page of the web browser application and configured to retrieve and display information resources hosted on the second domain (first cloud infrastructure)…” [Sekharan claim 1].
Sekharan is considered to be analogous to the claimed invention because it is in the same field of network arrangements for supporting services. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jensen in view of Ivanov to incorporate the teachings of Sekharan and include providing, by the multi-cloud infrastructure, a web-link to the resource created in the first cloud infrastructure to the second cloud infrastructure, the web-link being displayed in an application. Doing so would allow for the user to easily access a resource in a different cloud infrastructure. “The instructions also cause the at least one processing unit to receive data for the collaboration session 10 through the first page of the web browser application” [Sekharan Col. 3 Lines 9-11].
Response to Arguments
Applicant's arguments filed 12/09/2025 have been fully considered but they are not persuasive. Applicant argues in substance:
I. Here, the Examiner improperly abstracts Applicant's detailed claims to an observation, evaluation, and making predictions in an attempt to fit the claims to an abstract idea. Specifically, the Office Action asserts that the claimed features of the present invention relate to a process that can be performed mentally in the human mind. However, by doing so, the Examiner describes the claims at an improperly high level of abstraction, untethered from the language of the claims. For example, at least the limitation of "transmitting, by the multi-cloud infrastructure, a second request to a service provided by the first cloud infrastructure, the second request requesting creation of the resource, wherein the second request includes the resource- principal', and "deploying, by the multi-cloud infrastructure, a network link that communicatively couples the tenancy of the user in the first cloud infrastructure to the account of the user in the second cloud infrastructure, the network link facilitating the user to access the resource deployed in the first cloud infrastructure from the second cloud infrastructure " are steps that cannot be performed completely in a mental manner.
Like the facts in Enfish, the Examiner's alleged abstract idea comparison "describ[es] the claims at such a high level of abstraction ... untethered from the language of the claims all but ensures that the exceptions to § 101 swallow the rule." As such, the Examiner has failed to establish that the claims are prima facie invalid under 35 U.S.C. 101 for yet another reason.
a) Examiner respectfully disagrees. As detailed in the rejection above, the independent claims recite mental processes of validating, generating a token, and deploying a network link. A person can mentally couple the tenancy of a user in a first cloud infrastructure with the account of the user in a second cloud infrastructure through mental association. Further, the limitation of “transmitting, by the multi-cloud infrastructure, a second request to a service provided by the first cloud infrastructure, the second request requesting creation of the resource, wherein the second request includes the resource- principal” is not considered an abstract idea in the above rejection but rather additional claim elements. These additional claim elements amount to no more than generic computing components, field of use/technological environment, and insignificant extra solution activity of data transmission. Each limitation of the claims as well as the claims as a whole are considered within the 101 rejection above. The arguments have been considered but were not found to be persuasive.
II. Embodiments of the invention address a number of technical problems and provide for a number of technical improvements. The instant claims share substantial similarities to the claims of DDR Holdings, LLC v. Hotels.com, et al. (Fed. Cir. Dec. 5, 2014). In DDR Holdings, the claims involved were found to not be directed to an abstract idea because they were necessarily rooted in computer technology in order to overcome a problem specifically arising in the realm of computer technology. Similarly, here, embodiments of the invention solve problems associated with providing one or more services that are offered in a first cloud environment (provided by a first CSP) to one or more customers of a second cloud environment that is provided by a second CSP. A technical problem to be solved is how to provide services offered by a first cloud infrastructure to the customers of a different cloud infrastructure. The customers need such services to execute for instance, one or more workloads in their native environments. Accordingly, the claims provide a technical solution to a technical problem, and the claims are consequently not abstract. There is no need to even continue the analysis with (Step 2B) of the flowchart. But even if the analysis were to continue to (Step 2B), the claims would still be patent eligible.
a) Examiner respectfully disagrees. It is unclear from the arguments what specific improvements applicant is referencing. Further, as detailed in the rejection above, the independent claims recite mental processes of validating, generating a token, and deploying a network link. A person can mentally couple the tenancy of a user in a first cloud infrastructure with the account of the user in a second cloud infrastructure through mental association. This association does not represent improvements to computer functionality or other technology. “… it is important to keep in mind that an improvement in the abstract idea itself (e.g. a recited fundamental economic concept) is not an improvement in technology. For example, in Trading Technologies Int’l v. IBG, 921 F.3d 1084, 1093-94, 2019 USPQ2d 138290 (Fed. Cir. 2019), the court determined that the claimed user interface simply provided a trader with more information to facilitate market trades, which improved the business process of market trading but did not improve computers or technology” [MPEP § 2106.05(a) II]. An improvement to the abstract idea of association does not amount to significantly more than the abstract idea. Further, the additional elements of the claim also fail to amount to significantly more than the abstract idea. The arguments have been considered but were not found to be persuasive.
III. Here, is it clear that the claims involve more than performance of "well understood, routine, [and] conventional activities previously known to the industry." For instance, it is not common practice for customers of a particular cloud environment to seek services provided in another (i.e., completely independent) cloud environment. Furthermore, the claimed invention utilizes token exchange mechanisms for gaining access to services to provided in the cloud environment. Thus, the claim as a whole provides for a technical solution to provision users/customers of the first clous environment to access service(s) provided in another distinct cloud environment in order to execute one or more workloads (e.g., on compute instances) in the customer's native cloud environment. For at least these reasons, the Applicant respectfully requests withdrawal of the § 101 rejection of the pending claims.
a) Examiner respectfully disagrees. As detailed in the rejection above, the additional elements of the claims amount to no more than generic computing components, field of use/technological environment, and insignificant extra solution activity. Further, validating a user based on a token is an abstract idea, as it is a mental process which can be preformed in the human mind by making a determination about a user based on observations. Further, in response to applicant's further argument that the independent claims overcome the 101 rejection through the inclusion of additional elements, it is noted that the features upon which applicant relies (i.e., “provision users/customers of the first clous environment to access service(s) provided in another distinct cloud environment in order to execute one or more workloads (e.g., on compute instances) in the customer's native cloud environment”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). The arguments have been considered but were not found to be persuasive.
IV. The outstanding Office Action relies on Jensen to describe the claimed features of: "a first cloud infrastructure provided by a first cloud services provider (CSP), a second cloud infrastructure provided by a second CSP, and a link-resource object that include linking information of a tenancy created for the user in the first cloud infrastructure to the account associated with the user in the second cloud infrastructure. Applicant respectfully submit that the portions of Jensen relied upon by the Office Action do not correspond to the claimed features of the present application.
For instance, the Office Action asserts that the first consumer application A (part labeled 120 in FIG. 1) corresponds to the first cloud infrastructure provided by a first cloud services provider (CSP), and the second consumer application B (part labeled 130 in FIG. 1) corresponds to the second cloud infrastructure provided by a second cloud services provider (CSP). Applicant respectfully submit that consumer applications A and B correspond to at best, applications that are executed in a cloud environment. These do not correspond to a first cloud infrastructure provided by a first CSP and a second cloud infrastructure provided by the second CSP. With regard to the claimed feature of a link-resource object, the Office Action relies on the mapping of an account to a user identifier as described by Jensen to correspond to the claimed link resource object. In the claimed invention, an account of the user in the first cloud environment is linked (i.e., mapped) to a tenancy (e.g., account) of the user in the second cloud environment. Thus, in the claimed invention, the mapping is that of an account-to-account mapping of the user. In contrast, according to the teachings of Jensen, the mapping is between an account to a user ID. Applicant respectfully submit that the mapping as described by Jensen does not correspond to the link-resource object.
a) Examiner respectfully disagrees. As detailed in the rejection above, Jensen teaches: A method comprising: receiving, by a multi-cloud infrastructure included in a first cloud infrastructure provided by a first cloud services provider (CSP), [Jensen ¶ 36] a first request [Jensen ¶ 35] from a user associated with an account in a second cloud infrastructure provided by a second CSP, [Jensen ¶ 1-2, 25, 34-35]. Jensen teaches a hybrid cloud system consisting of clouds from multiple service providers. These service providers provide consumer applications as well as services to users. Consumer applications A and B are examples of applications of the cloud service providers which can be used to access other services from the range of cloud service providers [Jensen ¶ 35].
Further, Jensen teaches the link-resource object including information linking a tenancy created for the user in the first cloud infrastructure to the account associated with the user in the second cloud infrastructure; [Jensen ¶ 26, 51, 79]. Jensen teaches associating user accounts from different cloud service providers through a global identity mapping [Jensen ¶ 4, 24, 57] this mapping links the accounts to each other [Jensen ¶ 25-26]. Thus, the “account to user ID” mapping that Applicant argues is the teaching of Jensen is also an account-to-account mapping because multiple accounts can be associated with a global identity. The arguments have been considered but were not found to be persuasive.
V. Furthermore, with an aim to expedite prosecution, Applicant has amended the independent claims to recite: deploying, by the multi-cloud infrastructure, a network link that communicatively couples the tenancy of the user in the first cloud infrastructure to the account of the user in the second cloud infrastructure, the network link facilitating the user to access the resource deployed in the first cloud infrastructure from the second cloud infrastructure.
Applicant submits that assuming arguendo that the consumer applications correspond to the user accounts in two different cloud environments (which is not the case), Jensen does not describe the feature of deploying (and utilizing) the network link to access the resource deployed in the first cloud infrastructure from the second cloud infrastructure.
a) Examiner respectfully disagrees. As detailed in the rejection above, Jensen teaches and deploying, by the multi-cloud infrastructure, a network link that communicatively couples the tenancy of the user in the first cloud infrastructure to the account of the user in the second cloud infrastructure, [Jensen ¶ 24] the network link facilitating the user to access the resource deployed in the first cloud infrastructure from the second cloud infrastructure [Jensen ¶ 35, 42]. Jensen includes a global identity which maps between user accounts across different cloud service providers [Jensen ¶ 78] this global identity serves as a link between the accounts to provide users access to other services from a consumer application [Jensen ¶ 24]. The arguments have been considered but were not found to be persuasive.
Conclusion
THIS ACTION IS MADE FINAL. 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.
Examiner respectfully requests, in response to this Office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line number(s) in the specification and/or drawing figure(s). This will assist Examiner in prosecuting the application.
When responding to this Office Action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections. See 37 CFR 1.111(c).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARI F RIGGINS whose telephone number is (571)272-2772. The examiner can normally be reached Monday-Friday 7:00AM-4:30PM.
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, Bradley Teets can be reached at (571) 272-3338. 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.
/A.F.R./Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197