DETAILED ACTION
Response to Amendment
Claims 1-18 are pending.
Response to Arguments
Applicant’s arguments filed 09/03/2025 have been fully considered.
Regarding the rejection of claim 1 under 35 U.S.C. 103 as being unpatentable over Shaw et al. (US20190342280A1) in view of in view of Sridharan et al. (US20190334887A1), Applicant argues on page 10 from Sridharan does not teach or suggest "provisioning, based at least in part on the association between the first indication of authorization and the second indication of authorization and further based at least in part on a validation of a first identity token stored at a user device corresponding with the user with respect to a second identity token stored at the authorization management entity, a user account that is for the second application and that corresponds to the user."
Applicant’s arguments are persuasive. After further search and consideration, claim 1 is rejected under 35 U.S.C. 103 as being unpatentable over Shaw in view of Sridharan and McClain et al. (US20080244688A1), where in McClain is relied upon to disclose the limitiation above.
As to any argument not specifically addressed, they are the same as those discussed above.
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-5, 7-11 and 13-17 are rejected under 35 U.S.C. 103 as being unpatentable over Shaw et al. (US20190342280A1) in view of Sridharan et al. (US20190334887A1) and McClain et al. (US20080244688A1).
Regarding claim 1, Shaw discloses a method for user authentication at an application server, comprising (para [0010] shows in order to avoid a user having to separately authenticate with multiple services, the user can authenticate with a single sign-on (SSO) user interface of an identity manager. The user can then be authenticated with various services):
transmitting, from an authorization management entity [authentication service 119] to a first authorization entity [data store 126 of federated service 123] associated with a first application [federated service 123], a first authorization request based at least in part on a state parameter [username or user identifier] that identifies a user; receiving, at the authorization management entity and from the first authorization entity, a first access token [access token 143 and a refresh token 146] associated with the first application ([Abstract] shows a single sign-on (SSO) token is received; para [0030] shows the federated service verifies that the user account 129 associated with the SSO token 136 is allowed to access the federated service 123. Upon successful authorization, the federated service 123 can generate an access token 143 and a refresh token 146 and provide them to the authentication service 119; para [0023] shows the access token 143 has a time-limit associated with it, such as 1 hour, 3 hours, 6 hours, 8 hours, or some other period of time; para [0024] shows the refresh token 146 can be used to acquire a new access token 143 once a current or previous access token 143 expires. The refresh token 146 often has a much longer time-limit associated with it, such as 1 day, 1 week, 30 days, 3 months, or 1 year, which allows for the refresh token 146 to be used to acquire a series of access tokens 143 after an initial successful authentication);
storing, at the authorization management entity [authentication service 119], a first indication of authorization associated with the user and the first application based at least in part on receiving the first access token (para [0030] shows the federated service verifies that the user account 129 associated with the SSO token 136 is allowed to access the federated service 123. Upon successful authorization, the federated service 123 can generate an access token 143 and a refresh token 146 and provide them to the authentication service 119; para [0031] shows the authentication service 119 can then cache or otherwise store the access token 143 and the refresh token 146 for future use);
transmitting, from the authorization management entity [authentication service 119] to a second authorization entity [data store 126 of one or more applications or services] associated with a second application [one or more applications or services], a second authorization request based at least in part on the state parameter [username or user identifier]; receiving, at the authorization management entity and from the second authorization entity, a second access token associated with the second application (para [0010] shows authentication credentials of users on behalf of one or more applications or services; para [0021] shows the single SSO token 136 can be generated and used to provide the client device 106 with access to several of the federated services 123; para [0030] shows in response to an authentication request from the authentication service 119, the federated service verifies that the user account 129 associated with the SSO token 136 is allowed to access one or more federated services. Upon successful authorization, the one or more federated service can generate an access token 143 and a refresh token 146 and provide them to the authentication service 119);
storing, at the authorization management entity, a second indication of authorization associated with the user and the second application based at least in part on receiving the second access token (para [0031] shows the authentication service 119 can then cache or otherwise store the access token 143 and the refresh token 146 for future use).
Shaw fails to teach:
associating, at the authorization management entity, the first indication of authorization and the second indication of authorization, to permit integration, at a platform associated with the authorization management entity, of first resources of the first application and second resources of the second application with third resources of the platform of an on-demand database service that is associated with the platform and through which user interaction with the first application and the second application is performed; and
provisioning, based at least in part on the association between the first indication of authorization and the second indication of authorization and further based at least in part on a validation of a first identity token stored at a user device corresponding with the user with respect to a second identity token stored at the authorization management entity, a user account that is for the second application and that corresponds to the user.
However Sridharan, in an analogous art ([Abstract] shows a Cross-Platform Single Sign On (CP-SSO) to enable users to access multiple services via a single login when working across different platforms), discloses:
associating, at the authorization management entity [proxy token server], the first indication of authorization and the second indication of authorization (Fig 7 and para [0070] show a server 720 provides the proxy token service 220 to clients; para [0021] shows after a user has logged into a first application, the user will be provided with the access tokens to access a second application or other account without having to manually input user credentials again),
to permit integration, at a platform [Cross-Platform Single Sign On (CP-SSO)] associated with the authorization management entity, of first resources of the first application and second resources of the second application with third resources [security database] of the platform of an on-demand database service that is associated with the platform and through which user interaction with the first application and the second application is performed (Fig 7 and para [0070] show the proxy token service 220 for providing a cross-platform single sign-on (CP-SSO) system; para [0027] shows the secure storage 150 is a database that maintains the access information related to the user (e.g., whether a token has expired); para [0028] shows the token server 130 provides access tokens for identified users. When a user sends an authentication request (e.g., on-demand), the token server 130 verifies the user's shared secret by comparing it with information stored in a security database.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the system of Shaw with the teaching of Sridharan in order to enable users to access multiple services via a single login when working across different platforms (Sridharan; [Abstract]).
Shaw-Sridharan as combined fails to teach:
provisioning, based at least in part on the association between the first indication of authorization and the second indication of authorization and further based at least in part on a validation of a first identity token stored at a user device corresponding with the user with respect to a second identity token stored at the authorization management entity, a user account that is for the second application and that corresponds to the user.
However, McClain discloses:
provisioning, based at least in part on the association between the first indication of authorization and the second indication of authorization and further based at least in part on a validation of a first identity token stored at a user device corresponding with the user with respect to a second identity token stored at the authorization management entity, a user account that is for the second application and that corresponds to the user (para [0015] shows a remote application as a remote service to a local application; para [0020] shows single sign-on to access a variety of other services or resources; [Abstract] shows an entire policy and role provisioning environment is packaged in a first environment and sent to a second environment. The second environment authenticates and initiates the policy and role provisioning environment as a virtualized federated role provisioning service or a shared policy decision point service; para [0047] shows the virtualized policy decision point service (PDP) may include a specialized service that is pre-configured to communicate with a local identity service and supply a temporary access token that a remote identity service supplied. The local identity service then validates the token with the remote identity service and may also validate a signature for the configuration of the virtualized PDP and if all is well supplies a permanent identity for the virtualized PDP to use within a local environment.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the system of Shaw-Sridharan with the teaching of McClain in order to enable inter-enterprise integration (McClain; para [0043]).
Regarding claim 2, Shaw-Sridharan-McClain as applied to claim 1 discloses:
transmitting the first authorization request is based at least in part on a first identity token [SSO token 136] associated with the first authorization request; and transmitting the second authorization request is based at least in part on a second identity token associated with the second authorization request (Shaw; para [0010] shows authentication credentials of users on behalf of one or more applications or services; para [0030] shows in response to an authentication request from the authentication service 119, the federated service verifies that the user account 129 associated with the SSO token 136 is allowed to access the one or more applications or services.)
Regarding claim 3, Shaw-Sridharan-McClain as applied to claim 2 discloses:
verifying the first identity token [SSO token 136], wherein transmitting the second authorization request is based at least in part on verifying the first identity token (Shaw; para [0030] shows in response to an authentication request from the authentication service 119, the federated service verifies that the user account 129 associated with the SSO token 136 is allowed to access the one or more applications or services.)
Regarding claim 4, Shaw-Sridharan-McClain as applied to claim 1 discloses:
receiving, from a user, an authorization association request for the first application and the second application (Sridharan; para [0021] shows after a user has logged into a first application, the user will be provided with the access tokens to access a second application or other account without having to manually input user credentials again.)
Regarding claim 5, Shaw-Sridharan-McClain as applied to claim 1 discloses:
receiving, at the authorization management entity and from the first application, the state parameter [username or user identifier], wherein the state parameter is associated with a user account associated with the first application (Shaw; para [0030] shows in response to an authentication request from the authentication service 119, the federated service verifies that the user account 129 associated with the SSO token 136 is allowed to access the federated service 123. For example, the federated service 123 can query the data store 126 to retrieve a username or other user identifier for the user account 129 associated with the single sign-on token 136. The federated service 123 can then compare the retrieved username or other user identifier with its own list of registered or authorized users. If the retrieved username or other user identifier matches a username or user identifier stored in the list of registered or authorized users maintained by the federated service 123, then the federated service 123 can determine that the user account 129 linked to the SSO token 136 is authorized to access the federated service 123. Upon successful authorization, the federated service 123 can generate an access token 143 and a refresh token 146 and provide them to the authentication service 119).
Regarding claims 7-11, claims 7-11 are directed to an apparatus. Claims 7-11 require limitations that are similar to those recited in the method claims 1-6 to carry out the method steps. And since the references of Shaw-Sridharan combined teach the method including limitations required to carry out the method steps, therefore claims 7-11 would have also been obvious in view of the structures disclosed in Shaw-Sridharan combined.
Furthermore, Shaw-Sridharan discloses a processor; memory coupled with the processor; and instructions stored in the memory and executable by the processor (Shaw; para [0067]).
Regarding claim 13, Shaw discloses a method for user authentication at an application server, comprising (para [0010] shows in order to avoid a user having to separately authenticate with multiple services, the user can authenticate with a single sign-on (SSO) user interface of an identity manager. The user can then be authenticated with various services):
transmit, from an authorization management entity [authentication service 119] to a first authorization entity [data store 126 of federated service 123] associated with a first application [federated service 123], a first authorization request based at least in part on a state parameter [username or user identifier] that identifies a user; receive, at the authorization management entity and from the first authorization entity, a first access token [access token 143 and a refresh token 146] associated with the first application (para [0030] shows in response to an authentication request from the authentication service 119, the federated service verifies that the user account 129 associated with the SSO token 136 is allowed to access the federated service 123. For example, the federated service 123 can query the data store 126 to retrieve a username or other user identifier for the user account 129 associated with the single sign-on token 136. The federated service 123 can then compare the retrieved username or other user identifier with its own list of registered or authorized users. If the retrieved username or other user identifier matches a username or user identifier stored in the list of registered or authorized users maintained by the federated service 123, then the federated service 123 can determine that the user account 129 linked to the SSO token 136 is authorized to access the federated service 123. Upon successful authorization, the federated service 123 can generate an access token 143 and a refresh token 146 and provide them to the authentication service 119);
store, at the authorization management entity, a first indication of authorization associated with the user and the first application based at least in part on receiving the first access token (para [0031] shows the authentication service 119 can then cache or otherwise store the access token 143 and the refresh token 146 for future use);
transmit, from the authorization management entity [authentication service 119] to a second authorization entity [data store 126 of one or more applications or services] associated with a second application [one or more applications or services], a second authorization request based at least in part on the state parameter [username or user identifier]; receive, at the authorization management entity and from the second authorization entity, a second access token (para [0010] shows authentication credentials of users on behalf of one or more applications or services; para [0030] shows in response to an authentication request from the authentication service 119, the federated service verifies that the user account 129 associated with the SSO token 136 is allowed to access one or more federated service. For example, the one or more federated service can query the data store to retrieve a username or other user identifier for the user account 129 associated with the single sign-on token 136. The one or more federated service can then compare the retrieved username or other user identifier with its own list of registered or authorized users. If the retrieved username or other user identifier matches a username or user identifier stored in the list of registered or authorized users maintained by the federated service 123, then the one or more federated service can determine that the user account 129 linked to the SSO token 136 is authorized to access the one or more federated service. Upon successful authorization, the one or more federated service can generate an access token 143 and a refresh token 146 and provide them to the authentication service 119);
store, at the authorization management entity, a second indication of authorization associated with the user and the second application based at least in part on receiving the second access token (para [0031] shows the authentication service 119 can then cache or otherwise store the access token 143 and the refresh token 146 for future use).
Shaw fails to teach:
the second access token is associated with the first application; and
associate, at the authorization management entity, the first indication of authorization and the second indication of authorization, to permit integration, at a platform associated with the authorization management entity, of first resources of the first application and second resources of the second application with third resources of an on-demand database service that is associated with [[of)] the platform and through which user interaction with the first application and the second application is performed; and
provision, based at least in part on the association between the first indication of authorization and the second indication of authorization and further based at least in part on a validation of a first identity token stored at a user device corresponding with the user with respect to a second identity token stored at the authorization management entity, a user account that is for the second application and that corresponds to the user.
However Sridharan, in an analogous art ([Abstract] shows a Cross-Platform Single Sign On (CP-SSO) to enable users to access multiple services via a single login when working across different platforms), discloses:
the second access token is associated with the first application; and associate, at the authorization management entity [proxy token server], the first indication of authorization and the second indication of authorization (Fig 7 and para [0070] show a server 720 provides the proxy token service 220 to clients; para [0021] shows after a user has logged into a first application, the user will be provided with the access tokens to access a second application or other account without having to manually input user credentials again),
to permit integration, at a platform [Cross-Platform Single Sign On (CP-SSO)] associated with the authorization management entity, of first resources of the first application and second resources of the second application with third resources [security database] of an on-demand database service that is associated with [[of)] the platform and through which user interaction with the first application and the second application is performed (Fig 7 and para [0070] shows the proxy token service 220 for providing a cross-platform single sign-on (CP-SSO) system; para [0027] shows the secure storage 150 is a database that maintains the access information related to the user (e.g., whether a token has expired); para [0028] shows the token server 130 provides access tokens for identified users. When a user sends an authentication request (e.g., on-demand), the token server 130 verifies the user's shared secret by comparing it with information stored in a security database.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the system of Shaw with the teaching of Sridharan in order to enable users to access multiple services via a single login when working across different platforms (Sridharan; [Abstract]).
Shaw-Sridharan as combined fails to teach:
provision, based at least in part on the association between the first indication of authorization and the second indication of authorization and further based at least in part on a validation of a first identity token stored at a user device corresponding with the user with respect to a second identity token stored at the authorization management entity, a user account that is for the second application and thatcorresponds to the user.
However, McClain discloses:
provision, based at least in part on the association between the first indication of authorization and the second indication of authorization and further based at least in part on a validation of a first identity token stored at a user device corresponding with the user with respect to a second identity token stored at the authorization management entity, a user account that is for the second application and thatcorresponds to the user (para [0015] shows a remote application as a remote service to a local application; para [0020] shows single sign-on to access a variety of other services or resources; [Abstract] shows an entire policy and role provisioning environment is packaged in a first environment and sent to a second environment. The second environment authenticates and initiates the policy and role provisioning environment as a virtualized federated role provisioning service or a shared policy decision point service; para [0047] shows the virtualized policy decision point service (PDP) may include a specialized service that is pre-configured to communicate with a local identity service and supply a temporary access token that a remote identity service supplied. The local identity service then validates the token with the remote identity service and may also validate a signature for the configuration of the virtualized PDP and if all is well supplies a permanent identity for the virtualized PDP to use within a local environment.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the system of Shaw-Sridharan with the teaching of McClain in order to enable inter-enterprise integration (McClain; para [0043]).
Regarding claim 14, Shaw-Sridharan-McClain as applied to claim 1 discloses:
transmitting the first authorization request is based at least in part on a first identity token [SSO token 136] associated with the first authorization request; and transmitting the second authorization request is based at least in part on a second identity token associated with the second authorization request (Shaw; para [0010] shows authentication credentials of users on behalf of one or more applications or services; para [0030] shows in response to an authentication request from the authentication service 119, the federated service verifies that the user account 129 associated with the SSO token 136 is allowed to access the one or more applications or services.)
Regarding claim 15, Shaw-Sridharan-McClain as applied to claim 2 discloses:
verifying the first identity token [SSO token 136], wherein transmitting the second authorization request is based at least in part on verifying the first identity token (Shaw; para [0030] shows in response to an authentication request from the authentication service 119, the federated service verifies that the user account 129 associated with the SSO token 136 is allowed to access the one or more applications or services.)
Regarding claim 16, Shaw-Sridharan-McClain as applied to claim 1 discloses:
receiving, from a user, an authorization association request for the first application and the second application (Sridharan; para [0021] shows after a user has logged into a first application, the user will be provided with the access tokens to access a second application or other account without having to manually input user credentials again.)
Regarding claim 17, Shaw-Sridharan-McClain as applied to claim 1 discloses:
receiving, at the authorization management entity and from the first application, the state parameter [username or user identifier], wherein the state parameter is associated with a user account associated with the first application (para [0030] shows in response to an authentication request from the authentication service 119, the federated service verifies that the user account 129 associated with the SSO token 136 is allowed to access the federated service 123. For example, the federated service 123 can query the data store 126 to retrieve a username or other user identifier for the user account 129 associated with the single sign-on token 136. The federated service 123 can then compare the retrieved username or other user identifier with its own list of registered or authorized users. If the retrieved username or other user identifier matches a username or user identifier stored in the list of registered or authorized users maintained by the federated service 123, then the federated service 123 can determine that the user account 129 linked to the SSO token 136 is authorized to access the federated service 123. Upon successful authorization, the federated service 123 can generate an access token 143 and a refresh token 146 and provide them to the authentication service 119).
Claims 6 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Shaw in view of Sridharan and McClain, further in view of Hinton et al. (US7631346B2).
Regarding claims 6 and 12, Shaw-Sridharan-McClain as applied to claims 1 and 7 discloses:
creating a user account associated with the first application, wherein the state parameter is based at least in part on creating the user account associated with the first application.
However, Hinton discloses:
creating a user account associated with the first application, wherein the state parameter is based at least in part on creating the user account associated with the first application ([Abstract] shows a single-sign-on operation can pull user attributes to perform the user account creation operation; [col 40 lines 14-18] shows the federated user lifecycle management (FULM) application/service 352 or 708 might store the user information into some form of local datastore which may, in turn, trigger a local workflow/approval process.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the system of Shaw-Sridharan with the teaching of Hinton in order to trigger a local workflow/approval process (Hinton; [col 40 lines 14-18]).
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Shaw in view of Sridharan and McClain, further in view of Hinton.
Regarding claim 18, Shaw-Sridharan-McClain as applied to claim 13 discloses:
creating a user account associated with the first application, wherein the state parameter is based at least in part on creating the user account associated with the first application.
However, Hinton discloses:
creating a user account associated with the first application, wherein the state parameter is based at least in part on creating the user account associated with the first application ([Abstract] shows a single-sign-on operation can pull user attributes to perform the user account creation operation; [col 40 lines 14-18] shows the federated user lifecycle management (FULM) application/service 352 or 708 might store the user information into some form of local datastore which may, in turn, trigger a local workflow/approval process.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the system of Shaw- Sridharan with the teaching of Hinton in order to trigger a local workflow/approval process (Hinton; [col 40 lines 14-18]).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TAN DOAN whose telephone number is (571)270-0162. The examiner can normally be reached Monday - Friday 8am - 5pm ET.
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, William Trost can be reached at 571-272-7872. 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.
/TAN DOAN/ Primary Examiner, Art Unit 2442