DETAILED ACTION
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 .
Claims 1, 3-11 and 13-20 are pending in this application.
Claims 1, 3-4, 11, 13-14 and 19 are currently amended.
Claims 2 and 12 are pending in this application.
No new IDS was submitted by the Applicant.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 09/04/2025 has been entered.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 3, 6, 8-11, 13, 15 and 17-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Appiah et al. (US 2020/0007541 A1).
As to claim 1, A method comprising:
generating an integrated identity and access management (IAM) system in a first cloud environment from a first IAM system and a second IAM system that is different than the first IAM system (“… cloud-based identity provider 114a checks partition table 110a (which has been synched with partition table 110b) to determine if the domain has already been registered with cloud services network 102.” -e.g., see, [0034]; see also, Fig. 1; herein, “an integrated IAM system” is “the synched cloud-based identity provider 114a”; “a first cloud environment” is “the cloud services network 102”; “a first IAM system” is the system of cloud-based identity provider 114a before synchronization”; “a second IAM system” is the system of cloud-based identity provider 114b; -e.g., see Fig. 1; herein, the second IAM system (i.e., the system of cloud-based identity provider 114b) resides in “the cloud service network 104” which is different than the first IAM system; Appiah teaches generating integrated identity provider by syncing identities from partition table 110b of a second IAM system (i.e., from 11b) to identities of partition table 110a of first IAM system (i.e., to 114a); Thus, synched identity provider 114a becomes an integrated IAM system; see also, [0005], [0026]) by: (i) creating, in a customer tenancy of the first cloud environment, a plurality of identity domains, each identity domain being created in a unique compartment of the customer tenancy (“a customer tenancy” is the information shown in fig. 3; i.e., customer tenancy is created for plurality of identity domains; see also: “…enable selecting one of multiple cloud-based identity providers to process a request to authenticate a user associated with a domain that is registered in more than one cloud services network and generating an authentication response in accordance with the selection.” -e.g., see, [0005]; herein, enable selecting (i.e. creating) one of multiple cloud-based identity providers to process a request to authenticate a user associated with a domain (i.e., each customer tenancy of a plurality of customer tenancies associated with the first IAM system); see also: “FIG. 1 is a block diagram of an example system 100 that enables the registration of a domain in more than one sovereign cloud services network. As shown in FIG. 1, example system 100 includes a cloud services network 102, a cloud services network 104, a cloud services network 106, an enterprise network 108, and a synchronization service hub 118.” -e.g., see, [0024]), and (ii) embedding, in each identity domain an identity provider of the second IAM system (“Partition table synchronization service 112a may be configured to synchronize partition table 110a stored in data store 110a with other partition tables (e.g., 112b and 112c) maintained by other cloud services networks (e.g., 104 and 106) and synchronization service hub 118. For example, using a hub-spoke synchronization topology, partition table synchronization services 112a, 112b, and 112c (i.e., the spokes of the topology) each synchronize their respective partition tables with a partition table (not shown in FIG. 1) of synchronization service hub 118 and synchronization service hub 118 (i.e., the hub of the topology) synchronizes its partition table with all partition tables of synchronization services 112a, 112b, and 112c.” -e.g., see, [0028]; herein, each cloud-based Identity provider is associated (i.e. embedded) through synchronization services; also, see: “Cloud-based identity provider 114a may be configured to register a domain in a sovereign cloud services network that is also concurrently registered in another sovereign cloud services network.” -e.g., see, [0029]; herein, a domain is registered with a first and a second could-based Identity provider is equivalent to embedding, in each identity domain created in each customer tenancy, an identity provider of the second IAM system), wherein users associated with a first domain have different access rights as compared to users associated with a second domain with respect to resources in the customer tenancy (“FIG. 3, cloud-based identity provider 114a would authenticate the user associated with the resource request and send an authentication response to resource endpoint 116a. Such authentication response may include, for example, an access token that can then be used by resource endpoint 116a to determine if the user should be provided with access to the resource.” -e.g., see, [0054]; herein, each user with an access token determines if the user has access rights to a resource; thus, reads on users associated with a first domain have different access rights as compared to users associated with a second domain with respect to resources in the customer tenancy; see also, [0055], [0058]; herein, cloud-based identity provider 114a receives the second authentication request from identity provider 114b and generates a third authentication request using the user credentials included in the second authentication request. The third authentication request may include an access token that can then be used by resource endpoint 116a to determine if the user should be provided with access to the resource.);
receiving, by the integrated IAM system, a request from a user to perform an operation with respect to a resource associated with the second IAM system (“As shown in FIG. 4, the method of flowchart 400 begins at step 402. In step 402, a resource request associated with a user is received. The resource request requests access to a resource of a first cloud services network. For example, resource endpoint 116a may receive a resource request via network(s) 126. The resource request may request access to a resource of cloud services network 102 on behalf of a user. In some scenarios, the resource request may originate from a user's web browser, although this is only an example.” -e.g., see, [0049]), and
executing the request in response to the user being successfully authenticated by the integrated IAM system (“In this example, cloud-based identity provider 114a would determine that it should process the authentication request itself because the metadata associated with Initech.com indicates that the data associated with enterprise Initech is locally available in the CloudOne cloud services network. Note that if a cloud services network receives an authentication request associated with a domain and data associated with the domain is locally available in the cloud services network, the cloud services network will process the authentication request even if another cloud services network is indicated as a primary cloud services network for the domain.” -e.g., see, [0053], see also, [0058]: “The third authentication request may include an access token that can then be used by resource endpoint 116a to determine if the user should be provided with access to the resource.”).
As to claims 11 and 19, these are rejected using the similar rationale as for the rejection of claim 1.
As to claim 3, Appiah discloses the method of claim 2, Appiah further discloses wherein the compartment is associated with a policy corresponding to one or more rules governing access to resources by the user (“For example, a user may request access to a resource within cloud services network 102, connecting through an address (e.g., Uniform Resource Locator (URL)) to resource endpoint 116a. Resource endpoint 116a may then request an access token for the resource from cloud-based identity provider 114a. Based on the domain associated with the user, cloud-based identity provider 114a may determine that user authentication should be federated to enterprise identity provider 122 of enterprise network 108 and request enterprise identity provider 122 to authenticate the user. Enterprise identity provider 122 may authenticate the user using credential information (e.g., user name and password) stored at data store 124 and provide a federated token to cloud-based identity provider 114a.” -e.g., see, [0068]; See also, [0005], [0067]).
As to claim 13, it is rejected using the similar rationale as for the rejection of claim 3.
As to claim 6, Appiah discloses the method of claim 1, Appiah further discloses wherein a control plane of the integrated IAM system comprises: (i) a first end-point configured to receive requests pertaining to creation of new domains (“Cloud services networks 102, 104, and 106 each include a data store (e.g., 110a, 110b, 110c), storing a partition table, a partition table synchronization service (e.g., 112a, 112b, 112c), a cloud-based identity provider (e.g., 114a, 114b, 114c), and a resource endpoint (e.g., 116a, 116b, 116c). Enterprise network 108 may include a domain registration user interface (UI) 120, an enterprise identity provider 122, a data store 124 that stores user credentials (e.g., usernames and passwords), and enterprise computing device(s) 128. Although system 100 of FIG. 1 is shown to include three cloud services networks, it is to be understood that the techniques described herein may apply to systems that include more than three cloud services networks.” -e.g., see, Appiah: [0024]; herein, a resource endpoint (e.g., 116a, 116b, 116c) and enterprise computing device 128 are equivalent to end-points which is configured to receive request for domain registration (herein, domain registration is equivalent to domain creation); see also: “…a request to register a domain with a first cloud services network and a first verification code is received via a user interface. For example, and with continued reference to FIG. 1, cloud-based identity provider 114a may receive a request from a user of enterprise network 108 (e.g., an administrator of a tenant on cloud services network 102) to register a domain with cloud services network 102 through domain registration UI 120. “-e.g., see, Appiah: [0036], see also, [0005]), and (ii) a plurality of second end-points, each of which corresponds to a previously created domain and configured to receive pertaining to operations to be performed in the domain (“As shown in FIG. 4, the method of flowchart 400 begins at step 402. In step 402, a resource request associated with a user is received. The resource request requests access to a resource of a first cloud services network. For example, resource endpoint 116a may receive a resource request via network(s) 126. The resource request may request access to a resource of cloud services network 102 on behalf of a user.” -e.g., see, Appiah: [0049]; see also, [0005], Fig. 1, request for resources can be received by resource endpoint 116a, 116b or 116c).
As to claim 15, it is rejected using the similar rationale as for the rejection of claim 6.
As to claim 8, Appiah discloses the method of claim 1, Appiah further discloses comprising: provisioning a default identity domain in the customer tenancy, the default identity domain including a first user that created the customer tenancy, the default identity domain being associated with a default policy that provides access within the customer tenancy to the first user (“When a domain is registered for the first time, the domain is entered in the partition table for the cloud services network with which it is being registered. If there is no other entry in the partition table for this domain, an entry is added to the partition table including the name of the domain and the Partition ID associated with the domain. The new entry may also indicate whether the cloud services network is the “primary” or default cloud services network for the domain. In embodiments, the first cloud services network a domain is registered with may be marked as the domain's primary cloud services network and only one cloud services network in a partition table may be marked as primary for any domain.” -e.g., see, Appiah: [0043], see also, [0005]).
As to claim 9, Appiah discloses the method of claim 1, Appiah further discloses wherein the request is processed by a network source determiner (NSD) disposed in the customer tenancy (“At step 408 in flowchart 400, a data structure that is stored by the first cloud services network is accessed. The data structure identifies a plurality of cloud services networks with which the domain is associated. The data structure also stores metadata associated with the domain for each cloud services network in the plurality of cloud services networks. For example, cloud-based identity provider 114a may access the partition table stored in data store 110a to retrieve metadata associated with the domain that was identified in step 406.” -e.g., see, Appiah: [0052]; herein, identity provider 114a works as network source determiner which access the partition table and retrieves metadata associated with a domain (e.g., source); see also, Appiah: [0051]), the NSD being configured to determine a source of the request and wherein the method further comprises executing the request responsive to a successful identification of the source of the request (“At step 410 in flowchart 400, it is determined based on the metadata whether the authentication request should be processed by the first identity provider or by a second identity provider within a second cloud services network in the plurality of cloud services networks. With continued reference to FIG. 1 and FIG. 3, assume for the sake of illustration that cloud services network 102 is the CloudOne cloud services network referenced in FIG. 3, cloud services network 104 is the CloudThree cloud services network referenced in FIG. 3, and the domain is Initech.com. Cloud-based identity provider 114a (of CloudOne cloud services network) may determine whether it or cloud-based identity provider 114b (of CloudThree cloud services network) should process the authentication request based on the metadata stored in association with the Initech.com in the CloudOne cloud services network partition table. In this example, cloud-based identity provider 114a would determine that it should process the authentication request itself because the metadata associated with Initech.com indicates that the data associated with enterprise Initech is locally available in the CloudOne cloud services network. Note that if a cloud services network receives an authentication request associated with a domain and data associated with the domain is locally available in the cloud services network, the cloud services network will process the authentication request even if another cloud services network is indicated as a primary cloud services network for the domain.”: -e.g., see, Appiah: [0053]; herein, source is successfully authenticated; Moreover: “… an access token that can then be used by resource endpoint 116a to determine if the user should be provided with access to the resource.” -e.g., see, Appiah: [0054]; see also, [0005]).
As to claim 17, it is rejected using the similar rationale as for the rejection of claim 9.
As to claim 10, Appiah discloses the method of claim 1, Appiah further discloses wherein the request is executed without federating the first IAM system with the second IAM system (“Note that if a cloud services network receives an authentication request associated with a domain and data associated with the domain is locally available in the cloud services network, the cloud services network will process the authentication request even if another cloud services network is indicated as a primary cloud services network for the domain.” -e.g., see, Appiah: [0053]; herein, request is authenticated by the first service even when it’s not indicated as primary which implies request is executed without federating the first IAM system with the second IAM system since it’s done locally without communicating with the second system; see also, Appiah: [0005], [0054], [0055]).
As to claims 18 and 20, these are rejected using the similar rationale as for the rejection of claim 10.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 4-5, 7, 14 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Appiah as applied to claims 1, 11 and 19 above, and further in view of Caponi (US 2023/0083547 A1).
As to claim 4, Appiah discloses the method of claim 1, Appiah doesn’t explicitly disclose comprising: creating a plurality of identity domains in the customer tenancy, each of which corresponds to a stripe of the second IAM system, wherein the stripe corresponds to a container including one or more users.
However, in an analogous art, Caponi discloses creating a plurality of identity domains in the customer tenancy (“Resource Conversion Engine 530 will use one or more HTTP GET commands to access a list of resources for a tenant from a source IAM system 502 via an API for IAM system 502. In step 604, Resource Conversion Engine 530 parses the list of resources obtained in step 602. In step 606, after parsing the list of resources, Resource Conversion Engine 530 generates a temporary data structure (e.g., in memory), including creating a record for at least a subset of the resources in the obtained list, populating each record with a header identifying a respective resource and leaving the data portion of each record empty of data for the respective resource. Examples of resources for a IAM system include (but are not limited to) applications, users, groups, roles, policies, authorized servers, virtual servers, and privileges. In one embodiment, the syntax of the temporary data structure is in HCL.” -e.g., see, Caponi: [0045], also Fig. 6; herein, it should be noted that specification (para. 34) of instant application mentioned that “the resource is referred to herein as a domain”; thus, Caponi teaches creating a plurality of domains; Caponi teaches “creating a record for at least a subset of the resources in the obtained list” which is equivalent to creating a plurality of domains in the customer tenancy. Customer tenancy is equivalent to an organization, Caponi teaches creating a record for resources for an organization to migrate from one IAM system 502 to another IAM system 504; e.g., see, Caponi: [0043]), each of which corresponds to a stripe of the second IAM system (“an organization using IAM system 502 (i.e., the organization owning the data is referred to as the tenant) may wish to migrate from IAM system 502 to IAM system 504 because they are dissatisfied with IAM system 504. The organization (tenant) may wish to use IAM system 502 in parallel with IAM system 504 for fault tolerance purposes or to hedge against an outage of one system.” -e.g., see, Caponi: [0043]; herein, Customer tenancy is equivalent to an organization, Caponi teaches creating a record for resources for an organization to migrate from one IAM system 502 to another IAM system 504; thus, IAM system 504 is equivalent to the second IAM system; see also, [0045] which teaches creation of plurality of resources (e.g., domains)), wherein the stripe corresponds to a container including one or more users (“Examples of resources for a IAM system include (but are not limited to) applications, users, groups, roles, policies, authorized servers, virtual servers, and privileges. In one embodiment, the syntax of the temporary data structure is in HCL.” -e.g., see, Caponi: [0045]).
Therefore, it would have been obvious to one of ordinary skilled in the art before the effective filling date of the claimed invention was to modify the teaching of Appiah as taught by Caponi in order to enhances security, centralizes control and ensures that access permissions are appropriately managed across various systems and users.
As to claim 14, it is rejected using the similar rationale as for the rejection of claim 4.
As to claim 5, Appiah in view of Caponi discloses the method of claim 4, Caponi further discloses where each of the plurality of identity domains is associated with a corresponding policy (“an organization using IAM system 502 (i.e., the organization owning the data is referred to as the tenant) may wish to migrate from IAM system 502 to IAM system 504 because they are dissatisfied with IAM system 504. The organization (tenant) may wish to use IAM system 502 in parallel with IAM system 504 for fault tolerance purposes or to hedge against an outage of one system.” -e.g., see, Caponi: [0043]; herein, plurality of resources (e.g., domains) are associated with a migration policy).
Therefore, it would have been obvious to one of ordinary skilled in the art before the effective filling date of the claimed invention was to modify the teaching of Appiah as taught by Caponi in order to enhances security, centralizes control and ensures that access permissions are appropriately managed across various systems and users.
As to claim 7, Appiah discloses the method of claim 1, Appiah doesn’t explicitly disclose comprising: registering an application to the identity domain; creating a dynamic group of one or more resource principals; and allocating the dynamic group of one or more resource principals to the application.
However, in an analogous art, Caponi discloses registering an application to the domain; creating a dynamic group of one or more resource principals; and allocating the dynamic group of one or more resource principals to the application (“FIG. 5 also depicts Generic Resource Manager 520, which is used to provision resources in IAM systems 502, 504, and 506. Generic Resource Manager 520 is referred to as “generic” because it can provision resources in many different types of IAM systems. To work with and communicate with different types of IAM systems, Generic Resource Manager 520 makes use of plug-ins. For example, plug-in 522 defines how Generic Resource Manager 520 will work and communicate with IAM system 502, plug-in 524 defines how Generic Resource Manager 520 will work and communicate with IAM system 504, and plug-in 526 defines how Generic Resource Manager 520 will work and communicate with IAM system 506. Each plug-in also defines data sources and resource types for its respective IAM system. Examples of resources include applications, users, groups, roles, policies, authorized servers, virtual servers, and privileges.” -e.g., see, Caponi: [0039]; herein, “plug-in” defines resources including applications that are associated with IAM systems which is equivalent to registering an application to a domain; “Generic Resource Manager 520” is equivalent to a resource principal since it’s used to provision resources in multiple IAM systems; see also, Caponi: [0040]).
Therefore, it would have been obvious to one of ordinary skilled in the art before the effective filling date of the claimed invention was to modify the teaching of Appiah as taught by Caponi in order to enhances security, centralizes control and ensures that access permissions are appropriately managed across various systems and users.
As to claim 16, it is rejected using the similar rationale as for the rejection of claim 7.
Response to Arguments
Applicant has amended the independent claims which necessitated new ground of rejection, see rejection above. Applicant's arguments filed on 09/04/2025 have been fully considered but they are not persuasive.
Applicant argued on page 7-8 that: “Applicant submit that Appiah describes a framework of registering a domain with one or more cloud services network. Appiah describes (see paragraph [0029]) that the term 'domain' corresponds to a unique name that appears after an '@' sign in an email address, and/or after 'www.' in web addresses. A domain name may take the form of a name of an organization and a standard Internet suffix (e.g., yourbusiness.com). In contrast, in the claimed invention the term 'identity domain' corresponds to identity information of users of the cloud service provider.”
Examiner respectfully disagrees with the Applicant’s arguments and would like to point out that even though Applicant is arguing that ‘domain’ of Appiah corresponds to a web address or an email address, Appiah referring to creating an identity domain wherein Appiah teaches enable selecting (i.e. creating) one of multiple cloud-based identity providers to process a request to authenticate a user associated with a domain (i.e., each customer tenancy of a plurality of customer tenancies associated with the first IAM system) (e.g., see, [0005]; see also, Fig. 3, herein, “a customer tenancy” is the information shown in fig. 3; i.e., customer tenancy is created for plurality of identity domains). It also should be noted that Applicant didn’t clearly articulate “an identity domain” in claim language such a way to make any clear distinction from Appiah’s teaching. Appiah’s enabling of each identity provider which stores customer/user information reads on claimed creation of an identity domain in each customer tenancy of a plurality of customer tenancies associated with the first IAM system. Further to clarify, based on the amendment, teaching of the limitations is reallocated to show how Appiah teaches the claimed limitations. Appiah teaches “an integrated IAM system” is “the synched cloud-based identity provider 114a”; “a first cloud environment” is “the cloud services network 102”; “a first IAM system” is the system of cloud-based identity provider 114a before synchronization”; “a second IAM system” is the system of cloud-based identity provider 114b; -e.g., see Fig. 1; herein, the second IAM system (i.e., the system of cloud-based identity provider 114b) resides in “the cloud service network 104” which is different than the first IAM system; Appiah teaches generating integrated identity provider by syncing identities from partition table 110b of a second IAM system (i.e., from 11b) to identities of partition table 110a of first IAM system (i.e., to 114a); Thus, synched identity provider 114a becomes an integrated IAM system.
Applicant argued on page 8 of the remark that: “Further, the Office Action appears to assert that the claimed customer tenancy corresponds to a cloud service provider. Applicant respectfully traverse this assertion. For instance, Claim 1 has been amended to recite :"creating, in a customer tenancy of the first cloud environment, a plurality of identity domains, each identity domain being created in a unique compartment of the customer tenancy, and (ii) embedding, in each identity domain an identity provider of the second IAM system, wherein users associated with a first domain have different access rights as compared to users associated with a second domain with respect to resources in the customer tenancy;"
Examiner would like to point out that customer tenancy is nothing more than showing how each customer or users are assigned with each resource in different domains of the IAM system or each isolated partitions within the cloud infrastructure. In Fig. 3, herein teaches, “a customer tenancy” is the information, i.e., customer tenancy is created for plurality of identity domains; also shows plurality of users are associated with different access rights with different domains associated with access tokens. Further to clarify, each user with an access token determines if the user has access rights to a resource; thus, reads on users associated with a first domain have different access rights as compared to users associated with a second domain with respect to resources in the customer tenancy (see para. [0054]: “FIG. 3, cloud-based identity provider 114a would authenticate the user associated with the resource request and send an authentication response to resource endpoint 116a. Such authentication response may include, for example, an access token that can then be used by resource endpoint 116a to determine if the user should be provided with access to the resource.”; herein,; see also, [0055], [0058]);
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SUMAN DEBNATH whose telephone number is (571)270-1256. The examiner can normally be reached Mon-Fri; 9:00am-5:00pm.
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, Farid Homayounmehr can be reached at 571-272-3739. 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.
SUMAN DEBNATH
Patent Examiner
Art Unit 2495
/S.D/Examiner, Art Unit 2495
/FARID HOMAYOUNMEHR/Supervisory Patent Examiner, Art Unit 2495