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 .
DETAILED ACTION
Claims 1-20 pending in Instant Application.
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-8, 10-20 are rejected under 35 U.S.C. 103 as being unpatentable over CHENG et al., “hereinafter CHENG” (U.S. Patent Application: 20210336946) in view of Borneman et al., “hereinafter Borneman” (U.S. Patent Application: 20060129817) and further in view of Zigman et al., “hereinafter Zigman” (U.S. Patent: 10965674).
As per Claim 1, CHENG discloses a first software domain to participate in an identity provider (IDP) mesh network (CHENG, Para.53, SSO authentication method can work, the organization, company, or enterprise, on behalf of the user, establishes a trust relationship with the IDP),
the first software domain comprising: one or more processors (CHENG, Para.138, processing system, e.g., by one or more processors); and one or more non-transitory computer-readable media having computer-readable instructions stored thereon, the computer-readable instructions configured to instruct the one or more processors to (CHENG, Para.137, a computer readable storage medium storing instructions in a non-transitory manner, which are executable by a processor to perform any of the methods):
manage one or more first software applications of the first software domain (CHENG, Para.10, SSO allows users of an organization to authenticate at a single location, with a single account, and access a broad range of SaaS applications. With SSO, a user does not need to be signed on several times to call various applications, and can reuse the authenticated status of a previous application in the same session, Para.37, “Netskope-CASB” is a network security system that serves as a cloud-based security apparatus or on-premises policy enforcement point, placed between users and SaaS applications to combine and interject enterprise security policies as the SaaS applications are accessed.); and
operate a first IDP to: provide access to the one or more first software applications of the first software domain to first users responsive to first verified login credentials provided to the first IDP (CHENG, Para.10, federated Single Sign-on (SSO) capability or federated identity across all of an organization's SaaS application subscriptions. SSO allows users of an organization to authenticate at a single location, with a single account, and access a broad range of SaaS applications. With SSO, a user does not need to be signed on several times to call various applications, and can reuse the authenticated status of a previous application in the same session., Para.73, the IDP 408 authenticates the user 326, for example, by a multi-factor authentication mechanism or a previous IDP authentication session where the IDP 408 is part of a larger trust relationship and where the user 326 already has an assertion provided to it from another IDP, Para.59, The IDP 208 is the authority system that provides information confirming the user's identity. The SP 202 is the system that trusts the identity provider's user information, and uses this information to provide access to the SaaS application, Para.60, The “identity” is an “assertion” that the IDP 208 provides to the user 326 once the IDP 208 has validated the identity of the user 326. This forms a trust relationship between the IDP 208 and the SaaS application hosted by the SP 202, as the user 326 takes the assertion provided by the IDP 208 and uses it as authentication to access the SaaS application, instead of having to log in again with a different set of credentials to the SP 202 for authentication.);
However CHENG does not disclose first users registered with the first software domain and federate, with a second IDP of a second software domain participating in the IDP mesh network, access of the first users to one or more second software applications of the second software domain responsive to the first verified login credentials.
Borneman discloses first users registered with the first software domain (Borneman, Para.19, identities and other attributes can continue to be stored, managed, and controlled locally by the administrators of the domain in which they are registered.) and federate, with a second IDP of a second software domain, access of the first users to one or more second software applications of the second software domain responsive to the first verified login credentials (Borneman, Para.84, A request from a user not previously authenticated, or where credential information is required for any resource request, may require credential information (e.g., username, password, and biometric data) and authentication by the identity provider (step 815). A user may provide credential information, Para.85, successful authentication of a requesting user, identity provider may generate, sign, and transmit to the service provider, an identity assertion data structure together with the user request (step 820). To generate an identity assertion, identity provider may access user attributes stored in user credential store 460 and assemble into a data structure as defined by the policies and procedures of the federation., Para.15, A federation is any networked application environment within which interoperability spans two or more autonomous administrative domains, such as when two or more independent organizations interoperate within a business-to-business value chain, or among different business units within a large enterprise. A domain may be regarded as autonomous if it supports unilateral administration of its own users, resources, and policies, independent of other domains. Federated domains choose to interoperate in accordance with business agreements, trust relationships, interoperability arrangements, and their respective local policies.).
[The primary reference CHANG teaches a software domain including software applications and identity provider to identity the authenticated users to access the multiple software application by Single Sign-on (SSO) and federated Single Sign-on (SSO) capability or federated identity across all of an organization's SaaS application subscriptions. And the secondary reference Borneman teaches multiple software domain (the first software domain, second software) and multiple identity providers. The reference Borneman also teaches the federation federation model, in which users' identities are managed by Identity provider]
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in CHENG with the teachings as in Borneman. The motivation for doing so would have been for implementing systems and methods consistent with the present invention enable explicit and multilateral trust across a networked community of federated organizations, which may perform Identity provider, service provider, or both roles within the context of a particular identity federation. A trusted third party establishes a framework of policies and procedures governing a federation. Identity providers joining the federation submit to an audit process of internal policies and procedures to ensure compliance with the policies and procedures of the federation. (Borneman, Para.27).
However CHENG and Borneman do not disclose participating in the IDP mesh network.
Zigman discloses participating in the IDP mesh network (Zigman, Col.7, Line:3-10, Computing device 110, trustee resource 120, identity provider 130, and secure resource 140 may communicate through one or more network 150. Communications over network 150 may occur across various types of networks, such as the Internet, a wired Wide Area Network (WAN), a wired Local Area Network (LAN), a wireless WAN (e.g., WiMAX), a wireless LAN (e.g., IEEE 802.11, etc.), a mesh network, a mobile/cellular network, an enterprise or private data network, a storage area network).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in CHENG, Borneman with the teachings as in Zigman. The motivation for doing so would have been for security protection against threats to network identity providers. For example, in an exemplary embodiment, there may be a non-transitory computer readable medium including instructions that, when executed by at least one processor, may cause the at least one processor to perform operations for secure and efficient communications between clients and secure network resources. The operations may comprise identifying a first request from a client for access to a secure network resource; redirecting the client to an identity provider, wherein the identity provider is configured to: authenticate the client, and provide the client with data signed using a first identity provider key; identifying a second request from the client, the second request including a doubly-signed version of the data, which is the data signed using the first identity provider key and also signed using a first client key; verifying the doubly-signed version of the data using a second identity provider key corresponding to the first identity provider key, and a second client key corresponding to the first client key; and allowing, conditional on a result of the verifying, the client to access the secure network resource. (Zigman, Col.1, Line:44-65).
As per Claim 2, the modified CHENG discloses the first software domain of claim 1, wherein the computer-readable instructions are further configured to instruct the one or more processors to
provide access to the one or more first software applications of the first software domain to second users registered with the second software domain responsive to federation of the second IDP with the first IDP (CHENG, Para.60, The “identity” is an “assertion” that the IDP 208 provides to the user 326 once the IDP 208 has validated the identity of the user 326. This forms a trust relationship between the IDP 208 and the SaaS application hosted by the SP 202, as the user 326 takes the assertion provided by the IDP 208 and uses it as authentication to access the SaaS application, instead of having to log in again with a different set of credentials to the SP 202 for authentication, Para.50, the N-CASB can be used for its original purposes of managing access to the SaaS applications, while not hindering the security and user identity management (UID) that IDP provides for federated SSO authentication with the SaaS applications.).
however CHENG does not disclose first software domain and second software domain.
Borneman discloses first software domain and second software domain (Borneman, Para.15, A federation is any networked application environment within which interoperability spans two or more autonomous administrative domains, such as when two or more independent organizations interoperate within a business-to-business value chain, or among different business units within a large enterprise. A domain may be regarded as autonomous if it supports unilateral administration of its own users, resources, and policies, independent of other domains. Federated domains choose to interoperate in accordance with business agreements, trust relationships, interoperability arrangements, and their respective local policies.).
The same motivation that was utilized for combining CHENG, Borneman as set forth in claim 1 is equally applicable to claim 2.
As per Claim 3, the modified CHENG discloses the first software domain of claim 2, wherein the computer-readable instructions are further configured to instruct the one or more processors to
operate the first IDP to match user attributes of a second user provided by the second IDP during federation of the second IDP with the first IDP with registered user attributes associated with a registered first user of the first software domain to reduce duplications of registered users of the first software domain and the second software domain (Borneman, Para.17, Federated IdM environments define what amounts to an abstraction layer over the legacy identity and security environments of diverse domains. Each domain maps its local identities and attributes to the agreed-upon schemas and syntaxes,Para.18, Federated IdM is enabled through standards, technologies, and agreements that allow organizations to interchange and validate identities, attributes, roles, and permissions across autonomous domains. Within a federated IdM environment, a user can log into his or her company's domain and then leverage that authentication to access resources transparently in external domains, such as those managed by customers or suppliers, subject to various policies defined by local and external administrators., Para.16, Federated IdM (identity management) is an emerging industry best practice for dealing with the heterogeneous, dynamic, loosely coupled trust relationships that characterize companies' external and internal supply chains. Federated IdM enables strong authentication, Web single sign-on (SSO), role-based access control (RBAC), and other trust-enabled security services across diverse identity, security, and application domains.).
The same motivation that was utilized for combining CHENG, Borneman as set forth in claim 1 is equally applicable to claim 3.
As per Claim 4, the modified CHENG discloses the first software domain of claim 1, wherein the computer-readable instructions are configured to instruct the one or more processors to
operate the first IDP to federate, with a third IDP of a third software domain, access of the first users to one or more third software applications of the third software domain responsive to the first verified login credentials (Borneman, Para.15, A federation is any networked application environment within which interoperability spans two or more autonomous administrative domains, such as when two or more independent organizations interoperate within a business-to-business value chain, or among different business units within a large enterprise. A domain may be regarded as autonomous if it supports unilateral administration of its own users, resources, and policies, independent of other domains. Federated domains choose to interoperate in accordance with business agreements, trust relationships, interoperability arrangements, and their respective local policies.).
However CHENG and Borneman do not disclose participating in the IDP mesh network.
Zigman discloses participating in the IDP mesh network (Zigman, Col.7, Line:3-10, Computing device 110, trustee resource 120, identity provider 130, and secure resource 140 may communicate through one or more network 150. Communications over network 150 may occur across various types of networks, such as the Internet, a wired Wide Area Network (WAN), a wired Local Area Network (LAN), a wireless WAN (e.g., WiMAX), a wireless LAN (e.g., IEEE 802.11, etc.), a mesh network, a mobile/cellular network, an enterprise or private data network, a storage area network).
The same motivation that was utilized for combining CHENG, Borneman, Zigman as set forth in claim 1 is equally applicable to claim 4.
As per Claim 5, the modified CHENG discloses the first software domain of claim 4, wherein the computer-readable instructions are further configured to instruct the one or more processors to
provide access to the one or more first software applications of the first software domain to third users registered with the third software domain responsive to federation of the third IDP with the first IDP (CHENG, Para.10, federated Single Sign-on (SSO) capability or federated identity across all of an organization's SaaS application subscriptions. SSO allows users of an organization to authenticate at a single location, with a single account, and access a broad range of SaaS applications. With SSO, a user does not need to be signed on several times to call various applications, and can reuse the authenticated status of a previous application in the same session., Para.73, the IDP 408 authenticates the user 326, for example, by a multi-factor authentication mechanism or a previous IDP authentication session where the IDP 408 is part of a larger trust relationship and where the user 326 already has an assertion provided to it from another IDP).
However CHENG does not disclose first software domain and the third software domain.
Borneman discloses first software domain and the third software domain and federation of the third IDP with the first IDP (Borneman, Para.15, A federation is any networked application environment within which interoperability spans two or more autonomous administrative domains, such as when two or more independent organizations interoperate within a business-to-business value chain, or among different business units within a large enterprise. A domain may be regarded as autonomous if it supports unilateral administration of its own users, resources, and policies, independent of other domains. Federated domains choose to interoperate in accordance with business agreements, trust relationships, interoperability arrangements, and their respective local policies.).
The same motivation that was utilized for combining CHENG, Borneman as set forth in claim 1 is equally applicable to claim 5.
As per Claim 6, the modified CHENG discloses the first software domain of claim 1, wherein at least one of the one or more first software applications or the one or more second software applications comprises a dealer management system software application (Borneman, Para.64, a framework outlining a policy whereby identification of a user's credentials involves only presentation of a valid driver's license and a utility bill indicating current address may require a comparison of documents with information from the department of motor vehicles. In another embodiment, organization review and auditing procedures may be carried out by a third party contractor to trusted third party 300. Auditing of an applicant organization for compliance with federation policies and procedures is discussed further with reference to FIG. 7.).
The same motivation that was utilized for combining CHENG, Borneman as set forth in claim 1 is equally applicable to claim 6.
As per Claim 7, the modified CHENG discloses the first software domain of claim 1, wherein the computer-readable instructions are configured to instruct the one or more processors to
operate the first IDP to provide user attributes of a first user to the second IDP during a federation of the first IDP to the second IDP to enable the second IDP to reduce duplications of registered users of the first software domain and the second software domain (Borneman, Para.18, Federated IdM is enabled through standards, technologies, and agreements that allow organizations to interchange and validate identities, attributes, roles, and permissions across autonomous domains. Within a federated IdM environment, a user can log into his or her company's domain and then leverage that authentication to access resources transparently in external domains, such as those managed by customers or suppliers, subject to various policies defined by local and external administrators, Para.19, In a federated environment, identity information need not be replicated or synchronized across diverse federated domains. Instead, identities and other attributes can continue to be stored, managed, and controlled locally by the administrators of the domain in which they are registered.).
The same motivation that was utilized for combining CHENG, Borneman as set forth in claim 1 is equally applicable to claim 7.
As per Claim 8, the modified CHENG discloses the first software domain of claim 1, wherein the first IDP is communicatively coupled with all other IDPs of the IDP mesh network (CHENG, Para.27, Identity providers joining the federation submit to an audit process of internal policies and procedures to ensure compliance with the policies and procedures of the federation. Upon successful completion of an audit, an Identity provider may receive an identifying artifact such as a digital certificate, from a trusted third party indicating the trusted third party's approval of the Identity provider's identity, credential, and account management policies and practices.).
However CHENG and Borneman do not disclose participating in the IDP mesh network.
Zigman discloses participating in the IDP mesh network (Zigman, Col.7, Line:3-10, Computing device 110, trustee resource 120, identity provider 130, and secure resource 140 may communicate through one or more network 150. Communications over network 150 may occur across various types of networks, such as the Internet, a wired Wide Area Network (WAN), a wired Local Area Network (LAN), a wireless WAN (e.g., WiMAX), a wireless LAN (e.g., IEEE 802.11, etc.), a mesh network, a mobile/cellular network, an enterprise or private data network, a storage area network).
The same motivation that was utilized for combining CHENG, Borneman, Zigman as set forth in claim 1 is equally applicable to claim 8.
As per Claim 10, the modified CHENG discloses the first software domain of claim 1, wherein user provisioning from the first IDP to the second IDP is on (Borneman, Para.84, identity provider may determine if the requesting user has been authenticated within the identity, credential, and account management policies and practices of the identity provider (step 810). To be authenticated, a user may be required to have been proofed and vetted in accordance with the policies and procedures defined by the federation. Further, an account provisioned through the identity provider and secured by credential parameters defined by policies and procedures of the federation may be created. A previously authenticated user may not be required to provide credential information. Alternatively, credential information may be required at any time a request for resources is made).
The same motivation that was utilized for combining CHENG, Borneman as set forth in claim 1 is equally applicable to claim 10.
As per Claim 11, the modified CHENG discloses the first software domain of claim 1, wherein user provisioning from the first IDP to the second IDP is off (Borneman, Para.84, Certificate server 430 may also maintain a CRL for the federation, thereby enabling federation members to ensure the validity of a digital certificate from an identity provider. A CRL is a list of digital certificates which have been revoked, are no longer valid, and should not be relied upon by any federation member. Reasons for revocation of a digital certificate may include, for example, discovery that the trusted third party 300 has improperly issued a digital certificate, where a private-key has been compromised, and failure of the revoked organization to adhere to policy and procedure requirements of the federation. Federation members may access the CRL for each identity assertion received in order to ensure that reliance is not placed on a revoked digital certificate.).
The same motivation that was utilized for combining CHENG, Borneman as set forth in claim 1 is equally applicable to claim 11.
As per Claim 12, the modified CHENG discloses the first software domain of claim 1, wherein user provisioning from the second IDP to the first IDP is on (Borneman, Para.84, identity provider may determine if the requesting user has been authenticated within the identity, credential, and account management policies and practices of the identity provider (step 810). To be authenticated, a user may be required to have been proofed and vetted in accordance with the policies and procedures defined by the federation. Further, an account provisioned through the identity provider and secured by credential parameters defined by policies and procedures of the federation may be created. A previously authenticated user may not be required to provide credential information. Alternatively, credential information may be required at any time a request for resources is made).
The same motivation that was utilized for combining CHENG, Borneman as set forth in claim 1 is equally applicable to claim 12.
As per Claim 13, the modified CHENG discloses the first software domain of claim 1, wherein user provisioning from the second IDP to the first IDP is off (Borneman, Para.84, Certificate server 430 may also maintain a CRL for the federation, thereby enabling federation members to ensure the validity of a digital certificate from an identity provider. A CRL is a list of digital certificates which have been revoked, are no longer valid, and should not be relied upon by any federation member. Reasons for revocation of a digital certificate may include, for example, discovery that the trusted third party 300 has improperly issued a digital certificate, where a private-key has been compromised, and failure of the revoked organization to adhere to policy and procedure requirements of the federation. Federation members may access the CRL for each identity assertion received in order to ensure that reliance is not placed on a revoked digital certificate.).
The same motivation that was utilized for combining CHENG, Borneman as set forth in claim 1 is equally applicable to claim 13.
As per Claim 14, CHENG discloses one or more servers, comprising:
one or more processors communicatively coupled with the network interface, the one or more processors configured (CHENG, Para.138, processing system, e.g., by one or more processors, CHENG, Para.137, a computer readable storage medium storing instructions in a non-transitory manner, which are executable by a processor to perform any of the methods):
to operate a superapp to provide, to users, a platform for accessing software applications provided responsive sign-on credentials (CHENG, Para.37, “Netskope-CASB” is a network security system that serves as a cloud-based security apparatus or on-premises policy enforcement point, placed between users and SaaS applications to combine and interject enterprise security policies as the SaaS applications are accessed. N-CASB consolidates multiple types of security policy enforcement. Example security policies include authentication, federated single sign-on (SSO), authorization, credential mapping, device profiling, encryption, tokenization, data leakage prevention (DLP), logging, alerting, malware detection/prevention, and so on.).
However CHENG does not disclose the plurality of software domains and a network interface to enable communication with a plurality of software domains arranged in an identity provider (IDP) mesh network;
Borneman discloses the plurality of software domains and a network interface to enable communication with a plurality of software domains (Borneman, Para.15, A federation is any networked application environment within which interoperability spans two or more autonomous administrative domains, such as when two or more independent organizations interoperate within a business-to-business value chain, or among different business units within a large enterprise. A domain may be regarded as autonomous if it supports unilateral administration of its own users, resources, and policies, independent of other domains. Federated domains choose to interoperate in accordance with business agreements, trust relationships, interoperability arrangements, and their respective local policies.).
[The primary reference CHANG teaches a software domain including software applications and identity provider to identity the authenticated users to access the multiple software application by Single Sign-on (SSO) and federated Single Sign-on (SSO) capability or federated identity across all of an organization's SaaS application subscriptions. And the secondary reference Borneman teaches multiple software domain (the first software domain, second software) and multiple identity providers. The reference Borneman also teaches the federation federation model, in which users' identities are managed by Identity provider]
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in CHENG with the teachings as in Borneman. The motivation for doing so would have been for implementing systems and methods consistent with the present invention enable explicit and multilateral trust across a networked community of federated organizations, which may perform Identity provider, service provider, or both roles within the context of a particular identity federation. A trusted third party establishes a framework of policies and procedures governing a federation. Identity providers joining the federation submit to an audit process of internal policies and procedures to ensure compliance with the policies and procedures of the federation. (Borneman, Para.27).
However CHENG and Borneman do not disclose participating in the IDP mesh network.
Zigman discloses participating in the IDP mesh network (Zigman, Col.7, Line:3-10, Computing device 110, trustee resource 120, identity provider 130, and secure resource 140 may communicate through one or more network 150. Communications over network 150 may occur across various types of networks, such as the Internet, a wired Wide Area Network (WAN), a wired Local Area Network (LAN), a wireless WAN (e.g., WiMAX), a wireless LAN (e.g., IEEE 802.11, etc.), a mesh network, a mobile/cellular network, an enterprise or private data network, a storage area network).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in CHENG, Borneman with the teachings as in Zigman. The motivation for doing so would have been for security protection against threats to network identity providers. For example, in an exemplary embodiment, there may be a non-transitory computer readable medium including instructions that, when executed by at least one processor, may cause the at least one processor to perform operations for secure and efficient communications between clients and secure network resources. The operations may comprise identifying a first request from a client for access to a secure network resource; redirecting the client to an identity provider, wherein the identity provider is configured to: authenticate the client, and provide the client with data signed using a first identity provider key; identifying a second request from the client, the second request including a doubly-signed version of the data, which is the data signed using the first identity provider key and also signed using a first client key; verifying the doubly-signed version of the data using a second identity provider key corresponding to the first identity provider key, and a second client key corresponding to the first client key; and allowing, conditional on a result of the verifying, the client to access the secure network resource. (Zigman, Col.1, Line:44-65).
As per Claim 15, the modified CHENG discloses the one or more servers of claim 14, wherein the software operations are automobile dealership software applications (Borneman, Para.64, a framework outlining a policy whereby identification of a user's credentials involves only presentation of a valid driver's license and a utility bill indicating current address may require a comparison of documents with information from the department of motor vehicles. In another embodiment, organization review and auditing procedures may be carried out by a third party contractor to trusted third party 300. Auditing of an applicant organization for compliance with federation policies and procedures is discussed further with reference to FIG. 7.).
The same motivation that was utilized for combining CHENG, Borneman as set forth in claim 1 is equally applicable to claim 15.
As per Claim 16, CHENG discloses a method of operating an IDP mesh network, the method comprising:
receiving, by a first IDP of a first software domain via a user device, a request from a user registered with the first software domain to access a second software application (CHENG, Para.10, federated Single Sign-on (SSO) capability or federated identity across all of an organization's SaaS application subscriptions. SSO allows users of an organization to authenticate at a single location, with a single account, and access a broad range of SaaS applications. With SSO, a user does not need to be signed on several times to call various applications, and can reuse the authenticated status of a previous application in the same session., Para.73, the IDP 408 authenticates the user 326, for example, by a multi-factor authentication mechanism or a previous IDP authentication session where the IDP 408 is part of a larger trust relationship and where the user 326 already has an assertion provided to it from another IDP, Para.59, The IDP 208 is the authority system that provides information confirming the user's identity. The SP 202 is the system that trusts the identity provider's user information, and uses this information to provide access to the SaaS application, Para.60, The “identity” is an “assertion” that the IDP 208 provides to the user 326 once the IDP 208 has validated the identity of the user 326. This forms a trust relationship between the IDP 208 and the SaaS application hosted by the SP 202, as the user 326 takes the assertion provided by the IDP 208 and uses it as authentication to access the SaaS application, instead of having to log in again with a different set of credentials to the SP 202 for authentication.); and
initiating, by the first IDP, federation to obtain, for the user, access to the second software application (CHENG, Para.69, the organizations have a service level agreement (SLA) with the identity providers, such as the IDaaS providers, which facilitate the federated SSO. Invariably, the SLA's technical requirement is that the organizations establish and maintain a direct trust relationship between the IDaaS provider and its SaaS application subscriptions, Para.34, DaaS also provides user authentication, SSO, and authorization enforcement. Examples of common IDaaS providers today include Okta™, Ping Identity™, Windows Azure Active Directory™, EmpowerID™, OneLogin™, Bitium™ Centrify™, Identacor™, and LastPass™ ).
However CHANG does not disclose first software domain, second software domain and federation with a second IDP.
Borneman discloses first software domain, second software domain (Borneman, Para.15, A federation is any networked application environment within which interoperability spans two or more autonomous administrative domains, such as when two or more independent organizations interoperate within a business-to-business value chain, or among different business units within a large enterprise. A domain may be regarded as autonomous if it supports unilateral administration of its own users, resources, and policies, independent of other domains. Federated domains choose to interoperate in accordance with business agreements, trust relationships, interoperability arrangements, and their respective local policies.), federation with a second IDP (Borneman, Para.27, federated organizations, which may perform Identity provider, service provider, or both roles within the context of a particular identity federation. A trusted third party establishes a framework of policies and procedures governing a federation. Identity providers joining the federation submit to an audit process of internal policies and procedures to ensure compliance with the policies and procedures of the federation. Upon successful completion of an audit, an Identity provider may receive an identifying artifact such as a digital certificate, from a trusted third party indicating the trusted third party's approval of the Identity provider's identity, credential, and account management policies and practices. The Identity provider may then use its digital private key (which is cryptographically bound to their public key and identity on that certificate) for signing security assertions associated with a request for resources managed by a federated service provider. The service provider may trust the assertion from the Identity provider based on trust placed in the trusted third party by the service provider and the trust placed in the Identity provider by the trusted third party.).
[The primary reference CHANG teaches a software domain including software applications and identity provider to identity the authenticated users to access the multiple software application by Single Sign-on (SSO) and federated Single Sign-on (SSO) capability or federated identity across all of an organization's SaaS application subscriptions. And the secondary reference Borneman teaches multiple software domain (the first software domain, second software) and multiple identity providers. The reference Borneman also teaches the federation federation model, in which users' identities are managed by Identity provider]
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in CHENG with the teachings as in Borneman. The motivation for doing so would have been for implementing systems and methods consistent with the present invention enable explicit and multilateral trust across a networked community of federated organizations, which may perform Identity provider, service provider, or both roles within the context of a particular identity federation. A trusted third party establishes a framework of policies and procedures governing a federation. Identity providers joining the federation submit to an audit process of internal policies and procedures to ensure compliance with the policies and procedures of the federation. (Borneman, Para.27).
However CHENG and Borneman do not disclose participating in the IDP mesh network.
Zigman discloses participating in the IDP mesh network (Zigman, Col.7, Line:3-10, Computing device 110, trustee resource 120, identity provider 130, and secure resource 140 may communicate through one or more network 150. Communications over network 150 may occur across various types of networks, such as the Internet, a wired Wide Area Network (WAN), a wired Local Area Network (LAN), a wireless WAN (e.g., WiMAX), a wireless LAN (e.g., IEEE 802.11, etc.), a mesh network, a mobile/cellular network, an enterprise or private data network, a storage area network).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in CHENG, Borneman with the teachings as in Zigman. The motivation for doing so would have been for security protection against threats to network identity providers. For example, in an exemplary embodiment, there may be a non-transitory computer readable medium including instructions that, when executed by at least one processor, may cause the at least one processor to perform operations for secure and efficient communications between clients and secure network resources. The operations may comprise identifying a first request from a client for access to a secure network resource; redirecting the client to an identity provider, wherein the identity provider is configured to: authenticate the client, and provide the client with data signed using a first identity provider key; identifying a second request from the client, the second request including a doubly-signed version of the data, which is the data signed using the first identity provider key and also signed using a first client key; verifying the doubly-signed version of the data using a second identity provider key corresponding to the first identity provider key, and a second client key corresponding to the first client key; and allowing, conditional on a result of the verifying, the client to access the secure network resource. (Zigman, Col.1, Line:44-65).
As per Claim 17, the modified CHENG discloses the method of claim 16, further comprising:
transmitting, by the first IDP, an assertion to a custom trusted endpoint representing the second IDP; determining, by the second IDP, whether a sender of the assertion is trusted, whether the assertion is valid, and whether the user has access to the requested second software application; and minting, by the second IDP, an access token for the user to access the one or more second software applications responsive to determining that the assertion sender is trusted, that the assertion is valid, and that the user has access to the requested second software application (CHENG, Para.59, the IDP 208 is the asserting party, the SP 202 is the party relying on the assertion, and the user 326 operating a client with browser 336 is the subject of the assertion. The IDP 208 is the authority system that provides information confirming the user's identity. The SP 202 is the system that trusts the identity provider's user information, and uses this information to provide access to the SaaS application. The transaction from the IDP 208 to the SP 202 is called a SAML assertion. The structure of the SAML assertion is defined by an XML schema that is specified by the Organization for the Advancement of Structured Information Standards (OASIS) SAML standard. The SAML assertion contains header information, and statements about the subject in the form of attributes and conditions such as a start and logout URL. Web browser SSO is SAML's most widely used feature and is typically used in conjunction with the Hypertext Transfer Protocol (HTTP) POST binding and authentication request protocol. Web browser SSO can be initiated by the IDP 208 or by the SP 202 if a user's session has not been established. The assertion is also digitally signed by the IDP 208.).
As per Claim 18, the modified CHENG discloses the method of claim 17, further comprising: redirecting, by the second IDP, the user device to provide the requested second software application using the access token; and launching the requested second software application at the user device (CHENG, Para.34, dentity-as-a-Service (IDaaS): As used herein, the cloud-based IDP that provides a set of identity and access management functions to target SPs is referred to as an “IDaaS”. IDaaS functionality includes identity governance and administration (IGA), which includes the ability to provision identities held by the target SPs. IDaaS also provides user authentication, SSO, and authorization enforcement. Examples of common IDaaS providers today include Okta™, Ping Identity™, Windows Azure Active Directory™, EmpowerID™, OneLogin™, Bitium™ Centrify™, Identacor™, and LastPass™.)
As per Claim 19, the modified CHENG discloses the method of claim 17, wherein the assertion comprises a security assertion markup language (SAML) assertion (CHENG, Para.59, The SP 202 is the system that trusts the identity provider's user information, and uses this information to provide access to the SaaS application. The transaction from the IDP 208 to the SP 202 is called a SAML assertion. The structure of the SAML assertion is defined by an XML schema that is specified by the Organization for the Advancement of Structured Information Standards (OASIS) SAML standard.).
As per Claim 20, the modified CHENG discloses the method of claim 16, further comprising redirecting, by the first IDP, the user device to display a login graphical user interface to receive login credentials from the user responsive to receiving the request from the user to access the second software application (CHENG, Para.223, User interface input devices 1422 can include a keyboard; pointing devices such as a mouse, trackball, touchpad, or graphics tablet; a scanner; a touch screen incorporated into the display; audio input devices such as voice recognition systems and microphones; and other types of input devices. In general, use of the term “input device” is intended to include all possible types of devices and ways to input information into computer system 1410, Para.62, the user 326 can use to access the SaaS applications, for example the one hosted by the SP 202. The user 326 can present the assertion to the service provider (e.g., the SP 202) in place of performing another type of authentication (e.g., username/password login).).
Claims 9 rejected under 35 U.S.C. 103 as being unpatentable over CHENG et al., “hereinafter CHENG” (U.S. Patent Application: 20210336946) in view of Borneman et al., “hereinafter Borneman” (U.S. Patent Application: 20060129817) in view of Zigman et al., “hereinafter Zigman” (U.S. Patent: 10965674) and further in view of Lingampally et al., “hereinafter Lingampally” (U.S. Patent: 10630673).
As per Claim 9, the modified CHENG discloses the first software domain of claim 1,
However the modified CHENG does not disclose the IDP is communicatively coupled with only a subset of other IDPs of the IDP mesh network.
Lingampally discloses the IDP is communicatively coupled with only a subset of other IDPs (Lingampally, Col.2, Line:10-15, a subset of the plurality of identity providers, the user identity information and selects a subset of the received user identity information to be used in verifying an identity of a user based, at least in part, on a reputation score associated with each identity provider in the subset of identity providers.).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in the modified CHENG with the teachings as in Lingampally. The motivation for doing so would have been for e provides a method for generating composite identities in a distributed network. The method generally includes transmitting, to a plurality of identity providers, a request for user identity information. A service provider receives, from a subset of the plurality of identity providers, the user identity information and selects a subset of the received user identity information to be used in verifying an identity of a user based, at least in part, on a reputation score associated with each identity provider in the subset of identity providers. The service provider generates a composite user identity based on the selected subset of the received user identity information. The service provider takes one or more actions to enable use of a service based on the generated composite user identity. (Lingampally, Col.2, Line:5-17).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NORMIN ABEDIN whose telephone number is (571)270-5970. The examiner can normally be reached Monday to Friday from 10 am to 6 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Vivek Srivastava can be reached at 5712727304. 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.
/NORMIN ABEDIN/Primary Examiner, Art Unit 2449