Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections
set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed
invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have
been obvious before the effective filing date of the claimed invention to a person having
ordinary skill in the art to which the claimed invention pertains. Patentability shall not be
negated by the manner in which the invention was made.
Claim(s) 1,2,5,8,10,11,14,17,20 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20160308851 A, Tiwari, 2016-10-20, in view of US 20230300135 A1 Krishnan, 2022-03-21.
Tiwari teaches the following substantially as claimed.
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,
[0089] At block 820, the cloud service provider sends, to a validation service provider, a validation request for the user device, wherein the validation request includes the token identifier.
The described validation service provider corresponds to a distinct second service provider.
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;
[0019] A cloud-based validation system ensures that only users authorized to access cloud services do so. In some implementations, the validation system generates authentication tokens that indicate, among other things, the cloud services that a user is authorized to access.
[0089] At block 820, the cloud service provider sends, to a validation service provider, a validation request for the user device, wherein the validation request includes the token identifier.
The reference describes both elements of the above limitation, a request by a first CSP to a token service provided by a distinct second CSP, and a token generated (or issued) by a CSP. Albeit, the reference does not describe an actual token as having been included within the request. However, it would have been obvious to one skilled in the art at the time of this application’s filing to modify the design such that the initial cloud service could generate its own token and send it along with its service request as it could heighten security of the system by necessitating the verification of multiple fields
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,
[0019] In some implementations, the validation system generates authentication tokens that indicate, among other things, the cloud services that a user is authorized to access.
[0033] In response to receiving the validation request including the token identifier 220 from the cloud service provider 121, the validation service provider 131 transmits a validation response including the token 230 to the cloud service provider
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,
[0034] FIG. 3 is a signaling diagram of encrypted authorization in accordance with some implementations. To perform validation of a user device 111, the validation service provider 131 and cloud service provider 121 share knowledge of a private key 310. Thus, in some implementations, the validation service provider 131 transmits the private key 310 to the cloud service provider 121 (and possibly other cloud service providers).
[0080] At block 720, the validation service provider receives, from the cloud service provider, a validation request for the user device, wherein the validation request includes the token identifier. At block 730, the validation service provider sends, to the cloud service provider in response to validation request, a validation response based on the key.
The described process of validation via the sharing of private key corresponds to a trust configuration.
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.
[0022] In some implementations, each cloud service provider 121-123 provides an application programming interface (API) by which the user device 111 can access the resources 126-128 via the cloud service provider 121-123. In some implementations, the API is a web-based API.
[0019] A cloud-based validation system ensures that only users authorized to access cloud services do so. In some implementations, the validation system generates authentication tokens that indicate, among other things
[0089] the cloud service provider sends, to a validation service provider,
The reference describes each of the elements of the above limitation, a request by a first CSP to a token service provided by a distinct second CSP, API’s being provided by the service provides and, a token generated (or issued) by a CSP. Albeit, the reference does not describe an actual token as having been included within the request. However, it would have been obvious to one skilled in the art at the time of this application’s filing to modify the design such that the initial cloud service could send a token along with its service request as it could heighten security of the system by necessitating the verification of a broader array of data.
Tiwari does not teach the following limitation.
wherein the second token is usable by the first service to access the second service provided in the second cloud environment,
Krishnan does however
[0014] The present disclosure is directed towards systems and methods for pairing on-premise clusters in a private cloud to third party clouds using identity service providers. Cloud pairing is an event of establishing trust between two tenants on two different clouds via authentication so that resources for one tenant are available to the other tenant and vice-versa, thereby achieving a symmetric view of resources on both clouds and forming a single logical entity. As a result of cloud pairing, a tenant should be able to use all availability zones on the other cloud without having to establish trust with each availability zone separately. As used herein, the availability zones may be physical data centers or logical zones. The trust between the clouds can be established by way of exchanging tokens. The tokens are generated by an identity service provider. Tokens are then saved on each system and enable authentication by the systems before data from one system is received by the other
Tiwari teaches the following substantially as claimed.
It would have been obvious to one skilled in the art at the time of this application’s filing to modify the design of Tiwari such that a received token would allow for access to a service of a separate cloud environment as it would negate the need for one to register duplicate credentials between these.
Claim 2 inherits from claim 1 and therefore inherits its rejection.
Tiwari teaches the following substantially as claimed.
2. The method of claim 1, wherein the step of transmitting further comprises:
obtaining, by the first service offered in the first cloud environment, a native token issued by an identity management system of the first cloud environment; and transmitting, by the first service, a third request to a token exchange module of the first cloud environment, the third request requesting exchanging the native token for the first token.
[0019] A cloud-based validation system ensures that only users authorized to access cloud services do so. In some implementations, the validation system generates authentication tokens that indicate, among other things
[0089] the cloud service provider sends, to a validation service provider,
The reference describes both elements of the above limitation, a request by one CSP to a token service provided by a distinct other CSP and a token generated (or issued) by a CSP. Albeit, the reference does not describe an actual token as having been included within the request. However, it would have been obvious to one skilled in the art at the time of this application’s filing to modify the design such that the initial cloud service could generate its own token and send it along with its service request as it could heighten security of the system by necessitating the verification of multiple fields.
Tiwari does not teach the following limitation.
Claim 5 inherits from claim 1 and therefore inherits its rejection.
5. The method of claim 1,
a. wherein the first token is not usable by the first service offered in the first cloud environment to access the second service provided in the second cloud environment.
Krishnan does however.
[0003] a first token that is configured to authenticate to a first API endpoint to access the first access-restricted resource but is not configured to authenticate to a second API endpoint to access the second access-restricted resource
Tiwari in view of Krishnan teaches the following substantially as claimed.
Claim 8 inherits from claim 1 and therefore inherits its rejection.
Tiwari teaches the following substantially as claimed.
8. The method of claim 1,
a. wherein the first cloud environment is different than the second cloud environment,
and the first CSP is different than the second CSP.
[0089]the cloud service provider sends, to a validation service provider, a validation request for the user device, wherein the validation request includes the token identifier.
The described validation service provider corresponds to a distinct second service provider.
Tiwari teaches the following substantially as claimed.
10.
One or more computer readable non-transitory media storing computer-executable instructions that, when executed by one or more processors, cause:
[0098] The memory 906 optionally includes one or more storage devices remotely located from the CPU(s) 902. The memory 906 comprises a non-transitory computer readable storage medium.
Limitations 10 b-g correspond to limitations 1 a-f and therefore inherit the same rejections.
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.
Limitation 11a correspond to limitation 2a and therefore inherits the same rejections.
11. The one or more computer readable non-transitory media storing computer-executable instructions of claim 10, further comprising instructions that, when executed by one or more processors, cause:
a. obtaining, by the first service offered in the first cloud environment, a native token issued by an identity management system of the first cloud environment; and transmitting, by the first service, a third request to a token exchange module of the first cloud environment, the third request requesting exchanging the native token for the first token.
Limitation 14a correspond to limitation 5a and therefore inherits the same rejections.
14. The one or more computer readable non-transitory media storing computer-executable instructions of claim 10,
a. wherein the first token is not usable by the first service offered in the first cloud environment to access the second service provided in the second cloud environment.
Limitations 17 a corresponds to limitation 8a and therefore inherits the same rejections.
17. The one or more computer readable non-transitory media storing computer-executable instructions of claim 10,
A .wherein the first cloud environment is different than the second cloud environment, and the first CSP is different than the second CSP.
Limitations 19 a-g correspond to limitations 10 a-g and therefore inherit the same rejections.
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.
Limitation 20a correspond to limitation 2a and therefore inherits the same rejections.
20. The computing device of claim 19, wherein the computing device is further configured to:
a. obtain, by the first service offered in the first cloud environment, a native token issued by an identity management system of the first cloud environment; and transmit, by the first service, a third request to a token exchange module of the first cloud environment, the third request requesting exchanging the native token for the first token.
Claim(s) 3,4,12,13 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20160308851 A, Tiwari, 2016-10-20. in view of 20230300135 A1 Krishnan, 2022-03-21.. As well as in further view of US 20200136825 A1 Nutanix, 2018-10-31
Claim 3 inherits from claim 2 and therefore inherits its rejection.
Tiwari does not teach the following limitation.
3. The method of claim 2,
wherein the native token is not compatible with the token service provided in the second cloud environment, and the first token is compatible with the token service provided in the second cloud environment.
Nutanix does however.
[0003] In some of the disclosed embodiments, a method involves receiving, by a first computing system, a first message indicating that a resource owner has authorized a client application to make application programming interface (API) calls to both (A) a first access-restricted resource controlled by the resource owner, and (B) a second access-restricted resource controlled by the resource owner; in response to the first message, generating, by the first computing system, both (A) a first token that is configured to authenticate to a first API endpoint to access the first access-restricted resource but is not configured to authenticate to a second API endpoint to access the second access-restricted resource, and (B) a second token that is configured to authenticate to the second API endpoint to access the second access-restricted resource but is not configured to authenticate to the first API endpoint to access the first access-restricted resource; and sending, from the first computing system to a second computing system, the first token and the second token to enable the second computing system to use the first token to make a first API call to the first API endpoint to access the first access-restricted resource, and to use the second token to make a second API call to the second API endpoint to access the second access-restricted resource.
It would have been obvious to one skilled in the art at the time of this application’s filing to modify the design of Tiwari such that it would utilize two distinct tokens wherein an initial token is not compatible with the token service provided by a second cloud environment, and the subsequent token is compatible with the token service provided in the second cloud environment, as this would ensure outside resources are only able to be utilized following an exchange.
Claim 4 inherits from claim 3 and therefore inherits its rejection.
Tiwari teaches the following substantially as claimed.
4. The method of claim 3,
a. wherein the first token is a JavaScript Object Notation (JSON) web token.
[0044] In some implementations, the token 420 is a JSON (JavaScript Object Notation) token
Limitation 12a correspond to limitation 3a and therefore inherits the same rejections.
12. The one or more computer readable non-transitory media storing computer-executable instructions of claim 11,
wherein the native token is not compatible with the token service provided in the second cloud environment, and the first token is compatible with the token service provided in the second cloud environment.
Limitation 13a correspond to limitation 4a and therefore inherits the same rejections.
13. The one or more computer readable non-transitory media storing computer-executable instructions of claim 12,
wherein the first token is a JavaScript Object Notation (JSON) web token.
Claim(s) 6,15 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20160308851 A, Tiwari, 2016-10-20. in view of 20230300135 A1 Krishnan, 2022-03-21. As well as in further view of WO 2010119976 A1, MINAMIZAWA, 2010-10-21.
Claim 6 inherits from claim 1 and therefore inherits its rejection.
Tiwari in view of Krishnan teaches the following substantially as claimed.
6. The method of claim 1,
wherein validating the first token with respect to the trust configuration includes verifying
[0034] FIG. 3 is a signaling diagram of encrypted authorization in accordance with some implementations. To perform validation of a user device 111, the validation service provider 131 and cloud service provider 121 share knowledge of a private key 310. Thus, in some implementations, the validation service provider 131 transmits the private key 310 to the cloud service provider 121 (and possibly other cloud service providers).
[0080] At block 720, the validation service provider receives, from the cloud service provider, a validation request for the user device, wherein the validation request includes the token identifier. At block 730, the validation service provider sends, to the cloud service provider in response to validation request, a validation response based on the key.
Tiwari in view of Krishnan does not teach the following limitation.
one or more parameters included in the trust configuration corresponding to the first CSP.
Minamaizawa does however.
Page 13, Paragraph 8, When the anonymity of the anonymous communication device 410 satisfies the anonymity required by the service device 300, the communication control unit 120 further refers to the user permission information 111 of the user permission information storage unit 110, and determines the service provider ID. Anonymity is acquired in the search key (step S210).
Tiwari provides a process of validation via the sharing of a private key which corresponds to a trust configuration. Minamaizawa provides parameters. It would have been obvious to one skilled in the art at the time of this applications filing to modify the design of Tiwari in view of Krishnan to consider parameters in addition to a shared key in the trust configuration as it would allow for human readability.
Limitation 15a,b correspond to limitation 6a,b and therefore inherits the same rejections.
15. The one or more computer readable non-transitory media storing computer-executable instructions of claim 10,
a. wherein validating the first token with respect to the trust configuration includes verifying
b .one or more parameters included in the trust configuration corresponding to the first CSP.
Claim(s) 7,16 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20160308851 A, Tiwari, 2016-10-20. in view of 20230300135 A1 Krishnan, 2022-03-21.. As well as in further view of WO 2010119976 A1, MINAMIZAWA, 2010-10-21. And MATSUMOTO , JP 2015118459 A, 2015-06-25.
Claim 7 inherits from claim 6 and therefore inherits its rejection.
Tiwari in view of Krishnan does not teach the following limitation.
7. The method of claim 6,
wherein the one or more parameters included in the trust configuration comprise at least: an identifier of the first service provided in the first CSP,
Minamaizawa does however.
Page 13, Paragraph 8, When the anonymity of the anonymous communication device 410 satisfies the anonymity required by the service device 300, the communication control unit 120 further refers to the user permission information 111 of the user permission information storage unit 110, and determines the service provider ID. Anonymity is acquired in the search key (step S210).
Tiwari in view of Krishnan does not teach the following limitation.
an account ID of a user in the first cloud environment that is using the first service,
Matsumoto does however.
Page 4 Paragraph 5, The permission token management table 2100 shown in FIG. 9A includes a permission token ID 2110, a token type 2111, an expiration date 2120, a device ID 2112, a user ID 2113, a sub token request device ID 2114, and a restriction information ID 2115. Details of the processing of the permission token management table 2100 will be described later.
Tiwari in view of Krishnan does not teach the following limitation.
a set of permissions associated with the user,
Minamaizawa does however.
Page 13, Paragraph 8, When the anonymity of the anonymous communication device 410 satisfies the anonymity required by the service device 300, the communication control unit 120 further refers to the user permission information 111 of the user permission information storage unit 110, and determines the service provider ID. Anonymity is acquired in the search key (step S210).
Tiwari in view of Krishnan does not teach the following limitation.
a set of restrictions associated with user,
Matsumoto does however.
Page 8, Paragraph 8, FIG. 11B shows a restriction information management table 2300, which includes a restriction information ID 2310, a restriction type 2311, and restriction information 2312. Details of the processing of the restriction information management table 2300 will be described later.
Tiwari in view of Krishnan does not teach the following limitation.
a time/session duration for which the second token is to be kept active.
Matsumoto does however.
Page 4 Paragraph 5, The permission token management table 2100 shown in FIG. 9A includes a permission token ID 2110, a token type 2111, an expiration date 2120, a device ID 2112, a user ID 2113, a sub token request device ID 2114, and a restriction information ID 2115. Details of the processing of the permission token management table 2100 will be described later.
It would have been obvious to one skilled in the art at the time of this applications filing to modify the design of Tiwari in view of Krishnan to consider parameters in addition to a shared key in the trust configuration as it would allow for human readability.
Limitation 16 a,b correspond to limitation 7 a,b and therefore inherits the same rejections.
16. The one or more computer readable non-transitory media storing computer-executable instructions of claim 15,
a. wherein the one or more parameters included in the trust configuration comprise at least: an identifier of the first service provided in the first CSP,
b. an account ID of a user in the first cloud environment that is using the first service,
c. a set of permissions associated with the user,
d. a set of restrictions associated with user,
e. a time/session duration for which the second token is to be kept active.
Claim(s) 9,18 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20160308851 A, Tiwari, 2016-10-20. in view of 20230300135 A1 Krishnan, 2022-03-21. As well as in further view of US 20230188515 A1, Liang, 2021-12-10.
Claim 9 inherits from claim 1 and therefore inherits its rejection.
Tiwari does not state the following limitation.
9. 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 first cloud environment to the second cloud environment.
Liang however provides this.
[0007] According to an embodiment of the present invention, a computer-implemented method for optimizing security token exchange, the computer-implemented method comprising: receiving, by one or more processors, at a second service in a second domain, a first request from a client in a first domain; extracting, by the one or more processors, a second security token, associated with a security service in the second domain, and a reference to an application programming interface (API) associated with the first request; validating, by the one or more processors, the second security token at the second security service; and responsive to the second security token being valid, executing actions comprising: retrieving, by the one or more processors, a first security token, associated with the first domain, based on a call to the API; embedding, by the one or more processors, the second security token in the API; and sending, by the one or more processors, a second request comprising a third security token and the reference to the API to a third service in a third domain; responsive to the second security token not being valid, sending, by the one or more processors, a reply to the client in the first domain denying the first request.
Liand describes a corresponding process without mention of identity federation.
It would have been obvious to one skilled in the art at the time of this application’s filing to modify the design of Tiwari such that it would utilize a token exchange in its security validation wherein the exchange takes place without identify federation as this would circumvent requiring identities to be registered across clouds.
Limitation 18 a corresponds to limitation 9 a and therefore inherits the same rejection.
18. The one or more computer readable non-transitory media storing computer-executable instructions of claim 10,
wherein the first token is exchanged for the second token without performing an identity federation of a plurality of users associated with the first cloud environment to the second cloud environment.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Luke Absher whose telephone number is (571) 270-1057. The examiner can normally be reached M-F: 8:00 am - 4:00 pm. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the US PTO 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.
/LUCAS DONALD ABSHER/Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights