DETAILED ACTION
Claims 1-20 are pending in this application.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
Claims 5, 9, 15 and 19 are objected to because of the following informalities:
Claims 5, 9, 15 and 19 include the terms “ID” and “API”.
Abbreviations are allowed in claims; however, the first occurrence of the abbreviation MUST be spelled out.
For instance, identifier (ID).
Additionally, the term “and” is missing from claim 5. Specifically, the last limitation must be preceded by an “and”.
A correction is required, for instance, “The method of claim 4, wherein the one or more parameters included in the trust configuration comprise at least:
an identifier of the second CSP,
an account ID of the user in the second cloud environment,
a set of permissions associated with the user,
a set of restrictions associated with user, and
a time/session duration for which the second token is to be kept active”.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 11 and 20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 12 and 20 of copending Application No. 18/162,947 in view of U.S. Pub. No. 2021/0266306 A1 to Furman et al.
This is a provisional nonstatutory double patenting rejection.
Instant Application No. 18/825,612
U.S. Application No. 18/162,947
Claim 1:
A method comprising:
receiving, by a multi-cloud infrastructure included in a first cloud environment provided by a first cloud services provider (CSP), a first request from a user, the first request requesting use of a service provided by the first cloud environment and including a first token issued by the second CSP;
obtaining, by the multi-cloud infrastructure, a second token issued by the first CSP based on validating the first token with respect to a trust configuration corresponding to the user, the trust configuration being previously generated and maintained by the first CSP in the first cloud environment; and
transmitting, by the multi-cloud infrastructure, the second token to the service, wherein the second token enables the user to utilize the service provided by the first cloud environment
Claim 1:
A method comprising:
receiving, by a multi-cloud infrastructure included in a first cloud infrastructure provided by a first cloud services provider (CSP), a first request from a user associated with an account in a second cloud infrastructure provided by a second CSP, the first request requesting use of a service provided by the first cloud infrastructure and including a first token issued by the second CSP;
obtaining, by the multi-cloud infrastructure, a second token issued by the first CSP, wherein the second token is usable by the service, and the first token is not usable by the service; and
transmitting, by the multi-cloud infrastructure, the second token to the service, wherein the second token enables the user to utilize the service provided by the first cloud infrastructure.
Claim 11:
One or more computer readable non-transitory media storing computer-
executable instructions that, when executed by one or more processors, cause:
receiving, by a multi-cloud infrastructure included in a first cloud environment provided
by a first cloud services provider (CSP), a first request from a user associated with an account in
a second cloud environment provided by a second CSP, the first request requesting use of a
service provided by the first cloud environment and including a first token issued by the second
CSP;
obtaining, by the multi-cloud infrastructure, a second token issued by the first CSP based
on validating the first token with respect to a trust configuration corresponding to the second
CSP, the trust configuration being previously generated and maintained by the first CSP in the first cloud environment; and
transmitting, by the multi-cloud infrastructure, the second token to the service, wherein
the second token enables the user to utilize the service provided by the first cloud environment.
Claim 12;
One or more computer readable non-transitory media storing computer-executable instructions that, when executed by one or more processors, cause:
receiving, by a multi-cloud infrastructure included in a first cloud infrastructure provided by a first cloud services provider (CSP), a first request from a user associated with an account in a second cloud infrastructure provided by a second CSP, the
first request requesting use of a service provided by the first cloud infrastructure and including a first token issued by the second CSP;
obtaining, by the multi-cloud infrastructure, a second token issued by the first CSP, wherein the second token is usable by the service, and the first token is not usable by the service; and
transmitting, by the multi-cloud infrastructure, the second token to the service, wherein the second token enables the user to utilize the service provided by the first cloud infrastructure.
Claim 20:
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:
receive, by a multi-cloud infrastructure included in a first cloud environment
provided by a first cloud services provider (CSP), a first request from a user associated with an account in a second cloud environment provided by a second CSP, the first request requesting use of a service provided by the first cloud environment and including a first token issued by the second CSP;
obtain, by the multi-cloud infrastructure, a second token issued by the first CSP
based on validating the first token with respect to a trust configuration corresponding to the second CSP, the trust configuration being previously generated and maintained by the first CSP
in the first cloud environment; and
transmit, by the multi-cloud infrastructure, the second token to the service, wherein the second token enables the user to utilize the service provided by the first cloud
environment.
Claim 20:
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:
receive, by a multi-cloud infrastructure included in a first cloud infrastructure provided by a first cloud services provider (CSP), a first request from a user associated with an account in a second cloud infrastructure provided by a second CSP, the first request requesting use of a service provided by the first cloud infrastructure and including a first token issued by the second CSP;
obtain, by the multi-cloud infrastructure, a second token issued by the first CSP, wherein the second token is usable by the service, and the first token is not usable by the service; and
transmit, by the multi-cloud infrastructure, the second token to the service, wherein the second token enables the user to utilize the service provided by the first cloud infrastructure.
Nagaraja is silent with reference to validating, by the multi-cloud infrastructure, the first token issued by the second CSP; responsive to successfully validating the first token, sending by the multi-cloud infrastructure, a second request requesting a second token to an identity system of the first CSP, wherein the second request is a signed request including the first token, and wherein the identity system of the first CSP validates the first token based on a public key obtained from the second cloud infrastructure.
Furman teaches validating, by the multi-cloud infrastructure, the first token issued by the second CSP; responsive to successfully validating the first token, sending by the multi-cloud infrastructure, a second request requesting a second token to an identity system of the first CSP, wherein the second request is a signed request including the first token, and wherein the identity system of the first CSP validates the first token based on a public key obtained from the second cloud infrastructure (Identity Provider 104/Token Validator 126) (“…As shown in FIG. 1, an identity provider 104 receives a request 114 to authenticate a user. The identity provider 104 issues a user token 116 that contains identifying information of the user. The user token 116 is digitally signed with the identity provider's signature and provided to the user's device 112. A client application 110, at the user's device 112, uses the user token 116 to request 115 another cloud service, such as a middle-tier service 102B, to obtain an access token for the resource on behalf of the client application 110…The middle-tier cloud service 102B receives the request 115 and uses the token validator 126 to extract the user token and validate the signature. Upon successful validation, the middle-tier cloud service 102B uses an access token requestor 128 to request 120 an access token 122 on behalf of the client application 110 from the identity provider 104. Upon receipt of the access token 122, the middle-tier service 102B uses the target identifier 130 to determine the target service. The forwarding packager 132 generates an authenticated request to the target service 102A on behalf of the client application 110. The target service 102A validates the access token 122 in the authenticated request 124 against one or more policies before releasing the requested resource in a response 126 to the client application 110…” paragraphs 0027/0028).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Nagaraja with the teaching of Furman because the teaching of Furman would improve the system of Nagaraja by providing a technique of using signed document to authenticate a user.
Claims 1, 11 and 20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 10 and 19 of copending Application No. 18/825,661 to Evani et al. Although the claims at issue are not identical, they are not patentably distinct from each other because all claim limitations of the instant application are present in the 18/825,661 application.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Instant Application No. 18/825,612
U.S. Application No. 18/825,661
Claim 1:
A method comprising:
receiving, by a multi-cloud infrastructure included in a first cloud environment provided by a first cloud services provider (CSP), a first request from a user, the first request requesting use of a service provided by the first cloud environment and including a first token issued by the second CSP;
obtaining, by the multi-cloud infrastructure, a second token issued by the first CSP based on validating the first token with respect to a trust configuration corresponding to the user, the trust configuration being previously generated and maintained by the first CSP in the first cloud environment; and
transmitting, by the multi-cloud infrastructure, the second token to the service, wherein the second token enables the user to utilize the service provided by the first cloud environment
Claim 1:
A method comprising:
transmitting, by a first service offered in a first cloud environment that is managed by a first cloud services provider (CSP), a first request to a token service deployed in a second cloud environment that is managed by a second CSP, the first request including a first token issued by the first CSP and requesting use of a second service that is provided in the second cloud environment by the second CSP;
receiving, by the first service offered in the first cloud environment, from the token service provided in the second cloud environment, a second token issued by the second CSP, wherein the second token is usable by the first service to access the second service provided in the second cloud environment, and wherein the token service is configured to issue the second token in response to validating the first token with respect to a trust configuration corresponding to the first CSP, the trust configuration being established in the second cloud environment by the first CSP; and
responsive to receiving the second token, sending, by the first service, a second request to an API provided by the second cloud environment, the second request including the second token and requesting access to the second service.
Claim 11:
One or more computer readable non-transitory media storing computer-
executable instructions that, when executed by one or more processors, cause:
receiving, by a multi-cloud infrastructure included in a first cloud environment provided
by a first cloud services provider (CSP), a first request from a user associated with an account in
a second cloud environment provided by a second CSP, the first request requesting use of a
service provided by the first cloud environment and including a first token issued by the second
CSP;
obtaining, by the multi-cloud infrastructure, a second token issued by the first CSP based
on validating the first token with respect to a trust configuration corresponding to the second
CSP, the trust configuration being previously generated and maintained by the first CSP in the first cloud environment; and
transmitting, by the multi-cloud infrastructure, the second token to the service, wherein
the second token enables the user to utilize the service provided by the first cloud environment.
Claim 10:
One or more computer readable non-transitory media storing computer-executable instructions that, when executed by one or more processors, cause:
transmitting, by a first service offered in a first cloud environment that is managed by a first cloud services provider (CSP), a first request to a token service deployed in a second cloud environment that is managed by a second CSP, the first request including a first token issued by the first CSP and requesting use of a second service that is provided in the second cloud environment by the second CSP;
receiving, by the first service offered in the first cloud environment, from the token service provided in the second cloud environment, a second token issued by the second CSP, wherein the second token is usable by the first service to access the second service provided in the second cloud environment, and wherein the token service is configured to issue the second token in response to validating the first token with respect to a trust configuration corresponding to the first CSP, the trust configuration being established in the second cloud environment by the first CSP; and
responsive to receiving the second token, sending, by the first service, a second request to an API provided by the second cloud environment, the second request including the second token and requesting access to the second service.
Claim 20:
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:
receive, by a multi-cloud infrastructure included in a first cloud environment
provided by a first cloud services provider (CSP), a first request from a user associated with an account in a second cloud environment provided by a second CSP, the first request requesting use of a service provided by the first cloud environment and including a first token issued by the second CSP;
obtain, by the multi-cloud infrastructure, a second token issued by the first CSP
based on validating the first token with respect to a trust configuration corresponding to the second CSP, the trust configuration being previously generated and maintained by the first CSP
in the first cloud environment; and
transmit, by the multi-cloud infrastructure, the second token to the service, wherein the second token enables the user to utilize the service provided by the first cloud
environment.
Claim 19:
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:
transmit, by a first service offered in a first cloud environment that is managed by a first cloud services provider (CSP), a first request to a token service deployed in a second cloud environment that is managed by a second CSP, the first request including a first token issued by the first CSP and requesting use of a second service that is provided in the second cloud environment by the second CSP;
receive, by the first service offered in the first cloud environment, from the token service provided in the second cloud environment, a second token issued by the second CSP, wherein the second token is usable by the first service to access the second service provided in the second cloud environment, and wherein the token service is configured to issue the second token in response to validating the first token with respect to a trust configuration corresponding to the first CSP, the trust configuration being established in the second cloud environment by the first CSP; and
responsive to receiving the second token, send, by the first service, a second request to an API provided by the second cloud environment, the second request including the second token and requesting access to the second service.
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-3, 8, 10-13, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 2021/0266306 A1 to Furman et al. in view of U.S. Pub. No. 2018/0270219 A1 to LI.
As to claim 1, Furman teaches a method comprising:
receiving, by a multi-cloud infrastructure included in a first cloud environment provided by a first cloud services provider (CSP) (Cloud Service/Target Service 102A/Middle-Tier Client Service 102B), a first request from a user (User's Device 112), the first request requesting use of a service provided by the first cloud environment and including a first token issued by the second CSP (Initial Token 114/Request 115/User Token 116) (“…The On-Behalf-Of authentication flow allows a client application, at a user's device, that invokes a web service/API, to pass user authentication to another service. Initially, the user authenticates with an identity provider 104 to obtain a token 116 that authenticates the user. A client application 110 at the user's device 112 uses the initial token 114 to request 115 that a middle-tier client service 102B perform the request 120 to access a web API that resides on or is associated with target cloud service 102A. The target cloud service 102A obtains an access token 122 from an identity provider 104 based on the authenticated identify information from the first token. The middle-tier client service 102B obtains the access token 122 from the identity provider 104 and the middle-tier client service 102B then forwards the authenticated request 124 to the target cloud service 102A…As shown in FIG. 1, an identity provider 104 receives a request 114 to authenticate a user. The identity provider 104 issues a user token 116 that contains identifying information of the user. The user token 116 is digitally signed with the identity provider's signature and provided to the user's device 112. A client application 110, at the user's device 112, uses the user token 116 to request 115 another cloud service, such as a middle-tier service 102B, to obtain an access token for the resource on behalf of the client application 110…The middle-tier cloud service 102B receives the request 115 and uses the token validator 126 to extract the user token and validate the signature. Upon successful validation, the middle-tier cloud service 102B uses an access token requestor 128 to request 120 an access token 122 on behalf of the client application 110 from the identity provider 104. Upon receipt of the access token 122, the middle-tier service 102B uses the target identifier 130 to determine the target service. The forwarding packager 132 generates an authenticated request to the target service 102A on behalf of the client application 110. The target service 102A validates the access token 122 in the authenticated request 124 against one or more policies before releasing the requested resource in a response 126 to the client application 110…” paragraphs 0026-0028);
obtaining, by the multi-cloud infrastructure, a second token (Access Token 122) issued by the first CSP based on validating the first token with respect to a trust configuration corresponding to the user (Token Validator 126), the trust configuration being previously generated and maintained by the first CSP in the first cloud environment (“…As shown in FIG. 1, an identity provider 104 receives a request 114 to authenticate a user. The identity provider 104 issues a user token 116 that contains identifying information of the user. The user token 116 is digitally signed with the identity provider's signature and provided to the user's device 112. A client application 110, at the user's device 112, uses the user token 116 to request 115 another cloud service, such as a middle-tier service 102B, to obtain an access token for the resource on behalf of the client application 110…The middle-tier cloud service 102B receives the request 115 and uses the token validator 126 to extract the user token and validate the signature. Upon successful validation, the middle-tier cloud service 102B uses an access token requestor 128 to request 120 an access token 122 on behalf of the client application 110 from the identity provider 104. Upon receipt of the access token 122, the middle-tier service 102B uses the target identifier 130 to determine the target service. The forwarding packager 132 generates an authenticated request to the target service 102A on behalf of the client application 110. The target service 102A validates the access token 122 in the authenticated request 124 against one or more policies before releasing the requested resource in a response 126 to the client application 110…” paragraphs 0027/0028); and
transmitting, by the multi-cloud infrastructure, the second token to the service, wherein the second token enables the user to utilize the service provided by the first cloud environment (“…The middle-tier cloud service 102B receives the request 115 and uses the token validator 126 to extract the user token and validate the signature. Upon successful validation, the middle-tier cloud service 102B uses an access token requestor 128 to request 120 an access token 122 on behalf of the client application 110 from the identity provider 104. Upon receipt of the access token 122, the middle-tier service 102B uses the target identifier 130 to determine the target service. The forwarding packager 132 generates an authenticated request to the target service 102A on behalf of the client application 110. The target service 102A validates the access token 122 in the authenticated request 124 against one or more policies before releasing the requested resource in a response 126 to the client application 110…The authenticated request 124 is made to an endpoint 134 where a web API can access the resources needed to carry out its functions. The endpoint 134 supports a set of HTTP operations or methods, which create, retrieve, update or delete a resource of the cloud service 102A. The request 124 includes a Uniform Resource Identifier (URI) and a HTTP request message header. The URI indicates the protocol used to transmit the request (e.g., http, https), the domain name or Internet Protocol (IP) address of the server of the service endpoint, the resource path and parameters. The HTTP request message header includes a HTTP method (e.g., GET, HEAD, PUT, POST, and PATCH methods) that tells the service the type of operation that is being requested and includes the access token. The response 142 may include a HTTP response message header and a HTTP response message body. The HTTP response message header may include a status code and other optional data…” paragraphs 0028-0031).
Furman is silent with reference to a first request from a user associated with an account in a second cloud environment provided by a second CSP.
LI teaches to a first request from a user associated with an account in a second cloud environment provided by a second CSP (“…As shown, process 500 may include receiving a request from UE 210 for access to cloud computing services (block 510). For example, cloud admin server 230 may provide a user interface (UI) to UE 210 (e.g., in the form of a webpage). The UI may enable a user of UE 210 to enter a single set of login information (e.g., a username and password) that corresponds to a user account associated with multiple cloud services (e.g., cloud services provided by different cloud platform deployments). Via the UI and UE 210, the user may communicate a request (along with the user information) to cloud admin server 230 for access to the cloud services corresponding to the user information and/or user account…” paragraph 0037).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Furman with the teaching of LI because the teaching of LI would improve the system of Furman by providing a technique for securely identifying user before accessing computing resources.
As to claim 2, Furman teaches the method of claim 1, wherein the second token is usable by the service provided by the first cloud environment (Access Token 122), and the first token is not usable by the service provided by the first cloud environment CSP (Initial Token 114/Request 115/User Token 116).
As to claim 3, Furman teaches the method of claim 1, wherein the step of obtaining further comprises: sending (Access Token Requestor 128/Request 120), by the multi-cloud infrastructure, a second request to a token exchange module implemented in an identity system of the first CSP, the second request requesting the second token (Access Token 122) (“…The middle-tier cloud service 102B receives the request 115 and uses the token validator 126 to extract the user token and validate the signature. Upon successful validation, the middle-tier cloud service 102B uses an access token requestor 128 to request 120 an access token 122 on behalf of the client application 110 from the identity provider 104. Upon receipt of the access token 122, the middle-tier service 102B uses the target identifier 130 to determine the target service. The forwarding packager 132 generates an authenticated request to the target service 102A on behalf of the client application 110. The target service 102A validates the access token 122 in the authenticated request 124 against one or more policies before releasing the requested resource in a response 126 to the client application 110…The authenticated request 124 is made to an endpoint 134 where a web API can access the resources needed to carry out its functions. The endpoint 134 supports a set of HTTP operations or methods, which create, retrieve, update or delete a resource of the cloud service 102A. The request 124 includes a Uniform Resource Identifier (URI) and a HTTP request message header. The URI indicates the protocol used to transmit the request (e.g., http, https), the domain name or Internet Protocol (IP) address of the server of the service endpoint, the resource path and parameters. The HTTP request message header includes a HTTP method (e.g., GET, HEAD, PUT, POST, and PATCH methods) that tells the service the type of operation that is being requested and includes the access token. The response 142 may include a HTTP response message header and a HTTP response message body. The HTTP response message header may include a status code and other optional data…” paragraphs 0028-0031).
As to claim 8, LI teaches the method of claim 1, wherein the first cloud environment is different than the second cloud environment, and the first CSP is different than the second CSP (multiple cloud services) (“…As shown, process 500 may include receiving a request from UE 210 for access to cloud computing services (block 510). For example, cloud admin server 230 may provide a user interface (UI) to UE 210 (e.g., in the form of a webpage). The UI may enable a user of UE 210 to enter a single set of login information (e.g., a username and password) that corresponds to a user account associated with multiple cloud services (e.g., cloud services provided by different cloud platform deployments). Via the UI and UE 210, the user may communicate a request (along with the user information) to cloud admin server 230 for access to the cloud services corresponding to the user information and/or user account…” paragraph 0037).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Furman with the teaching of LI because the teaching of LI would improve the system of Furman by providing a technique for securely identifying user before accessing computing resources.
As to claim 10, Furman teaches the method of claim 1, wherein the first token is exchanged for the second token without performing an identity federation of a plurality of users associated with the second cloud environment to the first cloud environment (“…As shown in FIG. 1, an identity provider 104 receives a request 114 to authenticate a user. The identity provider 104 issues a user token 116 that contains identifying information of the user. The user token 116 is digitally signed with the identity provider's signature and provided to the user's device 112. A client application 110, at the user's device 112, uses the user token 116 to request 115 another cloud service, such as a middle-tier service 102B, to obtain an access token for the resource on behalf of the client application 110…The middle-tier cloud service 102B receives the request 115 and uses the token validator 126 to extract the user token and validate the signature. Upon successful validation, the middle-tier cloud service 102B uses an access token requestor 128 to request 120 an access token 122 on behalf of the client application 110 from the identity provider 104. Upon receipt of the access token 122, the middle-tier service 102B uses the target identifier 130 to determine the target service. The forwarding packager 132 generates an authenticated request to the target service 102A on behalf of the client application 110. The target service 102A validates the access token 122 in the authenticated request 124 against one or more policies before releasing the requested resource in a response 126 to the client application 110…” paragraphs 0027/0028).
As to claims 11 and 20, see the rejection of claim 1 above, expect for one or more computer readable non-transitory media/Memory and one or more processors.
Furman teaches one or more computer readable non-transitory media/Memory (Storage Devices 552/568/508/532) and one or more processors (Processors 548/564/528/504).
As to claim 12, see the rejection of claim 2 above.
As to claim 13, see the rejection of claim 3 above.
As to claim 18, see the rejection of claim 8 above.
Claims 4, 5, 14 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 2021/0266306 A1 to Furman et al. in view of U.S. Pub. No. 2018/0270219 A1 to LI as applied to claims 1 and 11 above, and further in view of C.N. No. 114386009 A to LI et al. (hereinafter referred to as LI’009).
As to claim 4, Furman as modified by LI teaches the method of claim 1, however it is silent with reference to wherein validating the first token with respect to the trust configuration includes verifying one or more parameters included in the trust configuration of the second CSP.
LI’009 teaches wherein validating the first token with respect to the trust configuration includes verifying one or more parameters included in the trust configuration of the second CSP (user login information) (“…According to a first aspect of the present invention, there is provided a multi-cloud deployment authentication method, comprising the following steps:
step 1: obtaining the user login information, sending the user login information to any one of the cloud server cloud server, receiving the user login information is the transfer cloud server;
step 2: the transfer cloud server generates a first token according to the user login information, and judges the accessible target cloud server returning the access address of the first token and the target cloud server
step 3: carrying the first token access target cloud server the cloud server to the transfer cloud server verifies the first token, after the check is passed, the transfer cloud server sends the user login information to the target cloud server
step 4: generating a second token according to the user login information by the target cloud server and returning to the second token;
step 5: carrying the second token to re-access target cloud server the target cloud server verified by the second token, after checking, returning the data needed by the user…”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Furman and LI with the teaching of Li’009 because the teaching of Li’009 would improve the system of Furman and LI by providing a technique for using a user’s specific identification to authenticate the user to allow for secure computing resource usage.
As to claim 5, Furman as modified by LI teaches the method of claim 4, however it is silent with reference to (HOWEVER, Li’009 teaches) wherein the one or more parameters included in the trust configuration comprise at least:
an identifier of the second CSP,
an account ID of the user in the second cloud environment,
a set of permissions associated with the user (user login information),
a set of restrictions associated with user,
a time/session duration for which the second token is to be kept active (“…According to a first aspect of the present invention, there is provided a multi-cloud deployment authentication method, comprising the following steps:
step 1: obtaining the user login information, sending the user login information to any one of the cloud server cloud server, receiving the user login information is the transfer cloud server;
step 2: the transfer cloud server generates a first token according to the user login information, and judges the accessible target cloud server returning the access address of the first token and the target cloud server
step 3: carrying the first token access target cloud server the cloud server to the transfer cloud server verifies the first token, after the check is passed, the transfer cloud server sends the user login information to the target cloud server
step 4: generating a second token according to the user login information by the target cloud server and returning to the second token;
step 5: carrying the second token to re-access target cloud server the target cloud server verified by the second token, after checking, returning the data needed by the user…”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Furman and LI with the teaching of Li’009 because the teaching of Li’009 would improve the system of Furman and LI by providing a technique for using a user’s specific identification to authenticate the user to allow for secure computing resource usage.
As to claim 14, see the rejection of claim 4 above.
As to claim 15, see the rejection of claim 5 above.
Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 20210266306 A1 to Furman et al. in view of U.S. Pub. No. 2018/0270219 A1 to LI as applied to claims 1 and 11 above, and further in view of U.S. Pub. No. 2023/0034835 A1 to Reyes.
As to claim 6, Furman as modified by LI teaches the method of claim 1, however it is silent with reference to wherein a type of second token issued by the first CSP is determined based on a type of service provided by the first cloud environment that is requested by the user.
Reyes teaches wherein a type of second token (second type of token) issued by the first CSP (first cloud instance) is determined based on a type of service provided by the first cloud environment that is requested by the user (user) (“…In some examples, the first cloud instance may receive a first type of token when the first cloud instance receives instructions to initiate the execution of the task. The first cloud instance may determine the first portion of the task based on the first token type. A second type of token may be determined based on the performance of the first portion by the first cloud instance. When the first cloud instance requests to add the task for executing the remaining portion to the task queue, the first cloud instance request may be accompanied by the second type of token. When the task for executing the remaining portion is assigned to the second cloud instance, the second type of token may be sent to the second cloud instance such that the second cloud instance may initiate execution of the remaining portion based on the second type of token. Receiving a third type of token may indicate all portions of the initially requested task have been assigned for execution…FIG. 3 depicts a schematic diagram showing an example cloud computing environment 300 comprising a task management system 302 for distributing and managing serial and parallel executions of computing tasks. The cloud computing environment 300 may comprise one or more task requesting devices (e.g., the task requesting devices 304A-C), a task management system 302, and one or more host cloud servers hosting cloud instances (e.g., the cloud server 306 hosting the cloud instances 306A-B and the cloud server 308 hosting the cloud instances 308A-C). For the sake of the current discussion, only three task requesting devices, one task management system, and two cloud servers are shown in FIG. 3. However, any number of task requesting devices and cloud servers may be coupled to the task management system 302. References to the task requesting devices may include users of the requesting devices…” paragraphs 0007/0040).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Furman and LI with the teaching of Reyes because the teaching of Reyes would improve the system of Furman and LI by providing a technique for applying varying number of token types to be used in authentication.
As to claim 16, see the rejection of claim 6 above.
Claims 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 20210266306 A1 to Furman et al. in view of U.S. Pub. No. 2018/0270219 A1 to LI as applied to claims 1 and 11 above, and further in view of U.S. Pub. No. 2019/0379663 A1 to Odenheimer et al.
As to claim 7, Furman as modified by LI teaches7the method of claim 1, however it is silent with reference to wherein the first cloud environment maintains a plurality of trust configurations in an identity system of the first CSP, each trust configuration of the plurality of trust configurations corresponding to a different external CSP of a plurality of external CSPs, the plurality of external CSPs including the second CSP.
Odenheimer teaches wherein the first cloud environment maintains a plurality of trust configurations in an identity system of the first CSP (Trusted Provider 106), each trust configuration of the plurality of trust configurations corresponding to a different external CSP of a plurality of external CSPs, the plurality of external CSPs including the second CSP (Customer Landscape 107) (“…As described in following paragraphs, the user 102 can use the cloud service 104 provided by the trusted provider 106 without requiring a dedicated named user account for the trusted provider 106. The customer company can have an established business relationship with the trusted provider 106. The customer may have a registered customer account with the trusted provider 106, for example. As described in following paragraphs, the registered customer account can be used for the user 102, in the background, without the user 102 needing to know the details of, or to specify, the registered customer account…The user 102 can be uniquely identifiable within a customer landscape 107 of the customer, for example by an E-mail address or some other user identifier. The user 102 does not have a direct named account with the trusted provider 106. The user 102 can be logged into the customer landscape 107. The customer landscape 107 can include a local network, interfaces to external networks, a firewall, and other components. The customer landscape 107 can use SSO (Single Sign On) so a browser 108 of the user 102 may have a SSO token associated with the customer…The user 102 uses the browser 108 running in the customer landscape 107 to send an initial request 109 to the trusted provider 106 to use the cloud service 104. The initial request 109 can include a service endpoint for the cloud service 104 and an email address of the user 102, but does not include other identifying information about the user 102. A cloud services component 110 can send a sign-in request to the browser 108. The user 102 can enter a company email address, but does not enter a corresponding password (since the user 102 does not want to supply company credentials to the external trusted provider 106…” paragraphs 0020-0022).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Furman and LI with the teaching of Odenheimer because the teaching of Odenheimer would improve the system of Furman and LI by providing registered customer account/account identifier that is known to a trusted provider that would indicate that respective users are allowed to use services provided by the trusted provider (Odenheimer paragraph 0030).
As to claim 17, see the rejection of claim 7 above.
Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 20210266306 A1 to Furman et al. in view of U.S. Pub. No. 2018/0270219 A1 to LI as applied to claims 1 and 11 above, and further in view of E.P.O. No. 3614643 A1 to Deshpande et al.
As to claim 9, Furman as modified by LI teaches the method of claim 1, however it is silent with reference to invoking, by the multi-cloud infrastructure included in the first cloud environment, one or more APIs of the second cloud environment using the first token issued by the second CSP.
Deshpande teaches invoking, by the multi-cloud infrastructure included in the first cloud environment, one or more APIs of the second cloud environment using the first token issued by the second CSP (“…The method of claim 1, wherein the user information request is sent using a first set of native APIs (Application Programming Interfaces) specific to the first cloud platform.
4. The method of claim 1, wherein the first token request is made using a token request interface provided by the token service.
5. The method of claim 4, further comprising deploying the token service to a third cloud platform including configuring the token service to invoke a second set of native APIs specific to the second cloud platform, to receive user information provided by the second cloud platform, and to receive token requests from the integration component using the same token request interface…” claims 3-5).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Furman and LI with the teaching of Deshpande because the teaching of Deshpande would improve the system of Furman and LI by providing a set of rules (API) that allows different software applications to communicate and exchange data with each other.
As to claim 19, see the rejection of claim 9 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Pub. No. 2012/0216268 A1 to Anthony et al. and directed to systems and methods for implementing an identity assertion framework to authenticate a user in a federation of security domains.
U.S. No. 9,183,374 B2 issued to Carter et al. and directed techniques for identity-enabled interface deployment.
U.S. Pat. No. 8,607,322 B2 issued to Hinton to et al. and directed to a method and a system are presented in which federated domains interact within a federated environment..
U.S. Pub. No. 2019/0273613 A1 to Diaz et al. and directed to a method involves receiving an access request from a user containing a token comprising a payload and a current user cryptographic key by a storage system to access a service.
U.S. Pat. No. 9,509,694 B2 issued to Parmar et al. and directed to a method for parallel authentication comprises receiving a download request from a client computer system to download a document stored in a first storage system.
U.S. Pub. No. 2020/0204371 A1 to Chengalvala et al. and directed to a system including one or more servers, programmed to responsive to receiving a token request from a vehicle to access content stored in a content cloud, validate the token request against pre-defined policies.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLES E ANYA whose telephone number is (571)272-3757. The examiner can normally be reached Mon-Fir. 9-6pm.
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, KEVIN YOUNG can be reached at 571-270-3180. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/CHARLES E ANYA/Primary Examiner, Art Unit 2194
Prosecution Insights