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 .
Response to Amendment
This action is responsive to an amendment filed on 02/02/2026. Claims 1, 5-6, 12, 15-16, 18 and 20 have been amended. Claims 1-20 are pending for examination.
Response to Arguments
Applicant’s arguments, see Applicant Arguments/Remarks, filed on 02/02/2026, with respect to the rejection of the pending claims under 35 U.S.C. §102 have been fully considered but they are not persuasive.
Applicant argues that Dasari merely describes an IdP service that verifies identities and issues tokens, but does not include two tenants that have separate identity providers - rather, in Dasari, the external entity itself creates the group of users from within its own domain, and the IdP service only verifies identities after access is requested. (Arg./Rem. page 8)
Examiner respectfully disagrees. Dasari expressly discloses multiple tenants/domains, each associated with its own directory and identity system. For example, Dasari teaches “A tenant is a representation of an organization in a cloud or identity platform… each tenant is distinct and separate from other tenants and has its own representation of identities and application registrations.” [¶ 0049]. Dasari further teaches “a remote principal is any principal, including users,… coming from any identity provider (IdP), tenant, or domain…” [¶ 0034] and “users of user(s) device(s) having credentials for tenant A… Likewise, users… having credentials for tenant B/partner…” [¶ 0050]. Thus, contrary to Applicant’s assertion, Dasari expressly contemplates at least two separate tenants/domains, each having its own identities, credentials, and associated identity provider functionality. The fact that Dasari additionally discloses an IdP/token service that verifies identities and issues tokens does not negate the disclosure of separate tenants having their own respective identity systems. Under BRI, the claimed “first identity provider” and “second identity provider” reasonably read on the separate tenant/domain authentication systems disclosed in Dasari.
Applicant further argues that Dasari does not teach “receiving, by an access broker, data indicative of multiple first users associated with a first tenant.” (Arg./Rem. page 8). However, Dasari expressly teaches creation and management of groups of users within a tenant/domain. For example Dasari teaches “An external entity creates a group of users from within its domain…” [¶ 0004], and “access controller 212 creates a group… which defines the set of users, or members, who have access to the task.” [¶ 0079]. Dasari additionally teaches that the ELM/access controller receives membership requests and manages group membership: “ELM 214 receives a request… for the user, i.e., as a remote principal with respect to the data resource, to be granted membership to the group associated with the task.” [¶ 0082]. Accordingly, Dasari teaches an access-management component receiving information indicative of multiple users associated with a tenant and determining/managing a group of such users.
Applicant additionally argues that Dasari fails to teach “exposing… the first group of users to a second tenant.” (Arg./Rem. page 8). This argument is likewise unpersuasive. Dasari expressly teaches that a remote principal object (“RPO”) in one domain points to a group maintained in another domain: “RPO 308 in first domain 302 points to group 318 stored in second domain 304.” [¶ 0069]. Dasari further explains that the RPO enables cross-domain access and authorization of members of the remote group. Thus, Dasari teaches exposing a group from one tenant/domain for use by another tenant/domain through the RPO/access-control framework.
Applicant’s argument regarding “selection of particular users from the first group” is also not persuasive because it improperly requires explicit manual user-by-user selection, which is not recited in the claim. The claim broadly recites “receiving… a selection of particular users from the first group,” and under BRI this encompasses selecting or determining which members of the group are granted access. Dasari teaches precisely such selective membership/access determinations. For example: “Group controller 210 is configured to determine whether a principal is allowed membership in a group…” [¶ 0062], “ELM 214 then adds the user/remote principal to the group…Verification of group membership allows flow diagram 400 to proceed…” [¶ 0082]. These disclosures demonstrate that Dasari evaluates and controls which individual remote principals are members of the authorized group and therefore which users ultimately receive access to the secure resources. The fact that approval may occur in the context of a task or access package does not preclude selective determination of individual users within the group. Moreover, Dasari expressly teaches that access is controlled based on both: (1) group membership, and (2) approval/access policy conditions: “there are at least two conditions that control the access to data resources: the remote principal is the member of a group… and a remote principal object exists…” [¶ 0033]. Accordingly, Dasari teaches managing access of selected users based on group configuration and access policies, as claimed.
Therefore, the Examiner is not persuaded and maintains that the applied reference Dasari teaches all of the limitations of the applicant’s claim.
Claim Rejections - 35 USC § 102
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.
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-7, 12-17 and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US 2021/0377276 (Dasari et al).
Regarding Claim 1, Dasari teaches a method, comprising: receiving, by an access broker, data indicative of multiple first users associated with a first tenant, the first tenant being associated with a first identity provider to authenticate the multiple first users ([¶ 0004] An external entity creates a group of users from within its domain. [¶ 0049] A tenant is a representation of an organization in a cloud or identity platform. …each tenant is distinct and separate from other tenants and has its own representation of identities. [¶ 0034], A remote principal is any principal, including users, …coming from any identity provider (IdP), tenant, or domain. [Fig. 2, ¶ 0062], Dasari discloses an access controller 212, an entitlements lifecycle manager (ELM) 214 and a secure token service (STS) 232. The ELM 214 is configured to govern grants of entitlements and lifecycles thereof including interfacing with group membership requests for group controller 210 and permissions approval requests. ELM 214 and access controller 212 comprise portions of a single service or application, e.g., access controller 212 comprises a portion of ELM 214. STS 232 is configured to issue tokens with permissions for data resources. Note: A functional claim element is anticipated when the prior art discloses any structure or combination of structures performing the same function. Thus, the combination of ELM 214, Access Controller 212, and STS 232 constitutes the claimed “access broker”);
determining, by the access broker and from among the multiple first users, a first group of users of the first tenant within a computer network ([¶ 0004], An external entity creates a group of users from within its domain. [¶ 0031], A domain, as used herein, generally refers to a physical and/or logical boundary under the control of an entity within which data resources are securely stored and access thereto requires domain-specific credentials. …domains include, tenancies of hosted cloud platforms, and/or any other type of network or system requiring domain-specific credentials for authentication and access thereto. A tenant is particular type of domain that is a representation of an organization in a cloud or identity platform. …a remote principal is a person, a group of people, etc., or any combination thereof, which belongs to a remote or external domain. [¶ 0079], access controller 212 creates a group, e.g., group 318 in system 300 (Fig. 3),… that corresponds to the task and which defines the set of users, or members, who have access to the task. [¶ 0069] group 318 includes one or more members of second domain 304);
exposing, by the access broker, the first group of users to a second tenant within the computer network, the second tenant being associated with a second identity provider to authenticate multiple second users associated with the second tenant ([¶ 0069], remote principal object (RPO) 308 in first domain 302 points to group 318 stored in second domain 304. [¶ 0034], A remote principal is any principal, including users, …coming from any identity provider (IdP), tenant, or domain, that is trusted by a current IdP such as of a home tenant/domain/host. The remote principal object points to the authorization claim that is verified through incoming tokens from the remote IdP. [¶ 0050], users of user(s) device(s) having credentials for tenant A… Likewise, users… having credentials for tenant B/partner. Thus, Dasari teaches exposing a group from one tenant/domain to another tenant/domain via the RPO framework and separate IdPs);
receiving, by the access broker, a selection of particular users from the first group of users for which the second tenant has granted remote access to one or more networked devices controlled the second tenant ([¶ 0062], Group controller is configured to determine whether a principal is allowed membership in a group, or is in fact a member of the group, for access to a data resource in performance of a task. [¶ 0082], ELM 214 receives a request from tenant B/P 228 for the user of tenant B/P device 472, i.e., as a remote principal with respect to the data resource, to be granted membership to the group associated with the task. Group controller 210 is configured to verify group membership is present or allowed, and to return a result of the verification to ELM 214. ELM 214 then adds the user/remote principal to the group and notifies tenant B/P 228. Verification of group membership allows flow diagram 400 to proceed. [¶ 0052], A cloud platform includes a networked set of computing resources, including servers, routers, etc., that are configurable, shareable, provide data security, and are accessible over a network such as the Internet, according to embodiments. Cloud applications/services are configured to run on these computing resources, often atop operating systems that run on the resources, for entities that access the applications/services, locally and/or over the network. A cloud platform such as cloud platform 118 is configured to support multi-tenancy as noted above, where cloud platform-based software services multiple tenants, with each tenant including one or more users who share common access to certain software services and applications of cloud platform 118, as noted herein. Thus, the access to the secure data resources, applications, portals, and directories hosted in the tenant domain are reasonably correspond to the access to one or more networked assets of devices controlled by the tenant); and
managing, by the access broker, access of the particular users of the first tenant to the one or more networked devices based on a group configuration for the first group of users by the first tenant and the selection of the particular users by the second tenant ([¶ 0044], Data resource(s) and directory are not accessible via authentication to the first domain of first domain host using credentials of the second domain of second domain host. …directory stores generated remote principal objects (RPOs) via which users with second domain credentials are granted access to data resource(s) and/or directory of first domain, e.g., using the IdP. [¶ 0079] tenant B provides a notification for creation of the task to access controller which will generate a task group and ELM packages that define group membership and define permissions required for data resources associated with the task to be accessed by members of the group. … Once this group is created, an ELM group package is created, by access controller, which governs the group membership assignments. … access controller retrieves the stored permissions template from tenant B and checks in directory A of tenant A for presence of the latest access packages created there that corresponds to the task. The access packages include the specific entitlements that are to be assigned to a remote principal, i.e., a group member, for access to data resources associated with the task. …access controller creates and assigns an access policy(ies) for the access packages. An access policy represents a set of constraints that are placed on permissions/entitlement grants, e.g., expired in a specified time (number of minutes, hours, days, etc.), manual approval required, approved when incoming principal belongs to a certain group, and/or the like. [¶ 0133], RPOs, permissions, and group memberships include lifecycle limitations, this lifecycle is strictly governed by the access policy for the permissions generated by ELM 214. ELM 214 determines the lifecycle of the RPO and its permissions as a temporal validity period based on the access policy created).
Regarding Claim 2, Dasari teaches the method of claim 1, wherein the first group of users are identified as individual users ([¶ 0043], services platform host includes an IdP service that is configured to verify identities of users of user(s) device(s) associated with a second domain of second domain host and to issue tokens or the like for access to secure resources such as a data resource(s) and/or a directory of a first domain of first domain host using remote principal objects. [¶ 0062], Group controller is configured to determine whether a principal is allowed membership in a group, or is in fact a member of the group, for access to a data resource in performance of a task, and access controller is configured to generate the group, permission associated with the data resource, and access policies for the permissions).
Regarding Claim 3, Dasari teaches the method of claim 1, wherein: the first group of users is identified by a group name; and individual users within the first group of users are obfuscated ([¶ 0086], a request is provided on behalf of the user/remote principal from tenant B to ELM for data resource access approval. ELM then provides a request for access package/permissions approval to lockbox associated with tenant A. Lockbox is a secure application by which a user of tenant A is notified via a UI at tenant A device of the request, and is enabled to accept or reject this request. The notification identifies the task, the permissions, the access policy, and/or the group. However, the notification does not identify specific remote principals, i.e., individual members [i.e., users are obfuscated], of the group, thus protecting their identities).
Regarding Claim 4, Dasari teaches the method of claim 1, wherein the selection of the particular users is selected from a group consisting of: an entirety of the first group of users; one or more subgroups of the first group of users; and a subset of individual users from the first group of users ([¶ 0029] In order to perform a task involving a secure data resource in a domain remote to their own, a user or principal needs access to the domain of the secure data resource. For instance, in order to offer support for certain applications and services, a provider may employ hundreds or thousands of engineers across the platform applications and services in various teams or groups spread across multiple geographical locations, including vendors. Additionally, it is possible that for each task several support engineers, technical advisors, and/or product group engineers are assigned to and/or take part in performance thereof. [¶ 0031], a remote principal is a person, a group of people, or any combination thereof, which belongs to a remote or external domain, that is intending to access secure data resources in the domains of their owners for performing tasks. [¶ 0033], the remote principal is the member of a group corresponding to the task that was created in the domain of the data resource owner).
Regarding Claim 5, Dasari teaches the method of claim 1, further comprising: receiving secure equipment access permissions for the particular users based on managing access of the particular users of the first tenant to the one or more networked devices ([¶ 0004], An external entity creates a group of users from within its domain and defines entitlements to a secure resource, of an owner entity of a different domain, as a set of permissions for the group. An access template with the permissions and an access policy for the secure resource are provided to the owning entity for approval. On approval for the access by the owning entity, a remote principal object is created in the owner directory according to the permissions and access policy. A remote principal that is a member of the group requests access via a user interface to the owner domain using external domain credentials. The claim of the remote principal is verified against the remote principal object by a token service. Verification of resource access permissions for the remote principal causes the generation and issuance of a token, with the enumerated entitlements, to the user interface of the remote principal to affect a redirect of the user interface for access to the secure resource).
Regarding Claim 6, Dasari teaches the method of claim 1, further comprising: receiving access revocation of one or more of the particular users by the second tenant; and revoking access of one or more of the particular users from the one or more networked devices in response to the access revocation ([¶ 0119], removal of the remote principal object, the set of permissions, and/or the access policy at the domain host for the first domain is caused based on at least one of receiving an access permission revocation from the first domain, completion of a task associated with the remote principal object, or an expiration of a temporal validity period for the remote principal object).
Regarding Claim 7, Dasari teaches the method of claim 6, wherein access revocation of one or more of the particular users comprises removing an individual user from one or more of the particular users or removing a subset of users from one or more of the particular users ([¶ 0033], When the access policy expires the entitlement, the remote principal(s) are removed from this group. This ensures that the remote principal(s) will not get access to the data resources outside of the specified policy. In the same manner, the remote principal object creation and deletion in the domain of the secure data resource owner is governed by an entitlements lifecycle manager (ELM) service. [¶ 0119], removal of the remote principal object, the set of permissions, and/or the access policy at the domain host for the first domain is caused based on at least one of receiving an access permission revocation from the first domain, completion of a task associated with the remote principal object, or an expiration of a temporal validity period for the remote principal object).
Regarding Claim 12, Dasari teaches an apparatus (Fig. 13, computing device 1300), comprising: one or more network interfaces to communicate with a network (Fig. 13, network interface 1350, network 1348); a processor coupled to the one or more network interfaces (Fig. 13, one or more processors, referred to as processor circuit 1302); and a memory configured to store instructions that are executable by the processor to cause the processor to perform operation (Fig. 13, system memory 1304, one or more application programs 1332, other programs 1334, and program data 1336. Application programs 1332 or other programs 1334 may include, for example, computer program logic (e.g., computer program code or instructions)).
The rest of the claim limitations of Claim 12 are identical and/or equivalent in scope to claim 1, therefore, Claim 12 is rejected under the same rationale as claim 1.
Regarding Claims 13-17, the claim limitations of are identical and/or equivalent in scope to claims 2-3 and 5-7, respectively, therefore, Claim 13-17 are rejected under the same rationale as claims 2-3 and 5-7.
Regarding Claim 20, Dasari teaches a tangible, non-transitory, computer-readable medium storing program instructions that cause a device to execute a process ([Fig. 13, ¶ 0148], Computing device 1300 includes one or more processors, referred to as processor circuit 1302. Processor circuit 1302 may execute program code stored in a computer readable medium, such as program code of operating system 1330, application programs 1332, other programs 1334, etc. ).
The rest of the claim limitations of Claim 20 are identical and/or equivalent in scope to claim 1, therefore, Claim 20 is rejected under the same rationale as claim 1.
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 8-11 and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Dasari in view of US 2023/0120512 (Bisla et al.).
Regarding Claim 8, Dasari does not explicitly teach, however, Bisla teaches the method of claim 1, further comprising: receiving an update to the first group of users from the first tenant; and updating the access according to the update ([¶ 0020], allows individuals or collaboration teams in an organization (also referred to as a tenant) to create a collaborative enterprise environment on a collaborative platform with other individuals or collaboration teams with other individuals or collaboration teams that belong to a different organization. Each collaboration team includes a group of team members. [¶¶ 0032-0033], a member of a collaboration team in an organization may collaborate with another member outside of the collaboration team in different organization. …an authorization manager may manage and authorize authorization requests from users to perform user operations on one or more resources. …the authorization manager is configured to evaluate an authorization request from a user to perform a user operation on a resource associated with a shared collaborative channel. For example, the user operation may include adding or removing a member or viewing or uploading content to the resource. Upon receiving the authorization request, the authorization manager is configured to authenticate the user based on identity information included in the authorization request. …the authorization manager is configured to verify that the user is in compliance with cross-tenant access policies defined by a home tenant of the user and a resource tenant. For example, the cross-tenant access policy on the home tenant may indicate whether the home tenant allows its members to access resources on another tenant. Whereas, the cross-tenant access policy on the resource tenant may indicate whether the resource tenant allows external members to access resources on the resource tenant. [¶ 0035], if the user operation that is being requested to be authorized is adding a member to the shared collaborative channel, the authorization manager may call a specific API for updating group members and check for permission for adding member for the authenticated user).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Bisla's teaching of adding a member to a group to access resources on the resource tenant to the teachings of Dasari, because such incorporation would have simplified expansion, as an organization grows and adds new teams or departments, group-based management allows to scale its processes without losing efficiency, new employees can be added to existing groups without disrupting workflows.
Regarding Claim 9, Dasari does not explicitly teach, however, Bisla teaches the method of claim 8, wherein the update comprises adding users and, if all users of the second tenant are selected, adding access to new users in the second tenant ([¶ 0033], Upon receiving the authorization request, the authorization manager is configured to authenticate the user based on identity information included in the authorization request. …the authorization manager is configured to verify that the user is in compliance with cross-tenant access policies defined by a home tenant of the user and a resource tenant. [¶ 0035], if the user operation that is being requested to be authorized is adding a member to the shared collaborative channel, the authorization manager may call a specific API for updating group members and check for permission for adding member for the authenticated user).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Bisla's teaching of adding a member to a group to access resources on the resource tenant to the teachings of Dasari, because such incorporation would have simplified expansion, as an organization grows and adds new teams or departments, group-based management allows to scale its processes without losing efficiency, new employees can be added to existing groups without disrupting workflows.
Regarding Claim 10, Dasari does not explicitly teach, however, Bisla teaches the method of claim 8, wherein the update comprises adding users, and if individual users of second tenant group are selected, exposing new users but only allowing access if the second tenant grants access to added users ([¶ 0033] Upon receiving the authorization request, the authorization manager is configured to authenticate the user based on identity information included in the authorization request. …the authorization manager is configured to verify that the user is in compliance with cross-tenant access policies defined by a home tenant of the user and a resource tenant. For example, the cross-tenant access policy on the home tenant may indicate whether the home tenant allows its members to access resources on another tenant. Whereas, the cross-tenant access policy on the resource tenant may indicate whether the resource tenant allows external members to access resources on the resource tenant. [¶ 0035], if the user operation that is being requested to be authorized is adding a member to the shared collaborative channel, the authorization manager may call a specific API for updating group members and check for permission for adding member for the authenticated user).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Bisla's teaching of cross-tenant access policy that indicate whether the resource tenant allows external members to access resources on the resource tenant, to the teachings of Dasari, because such incorporation would have improved access control, by centralizing access rules, group management improves security by preventing unauthorized access.
Regarding Claim 11, Dasari teaches the method of claim 8, wherein the update comprises removing users and auto-removing access of the users from second tenant ([¶ 0119], removal of the remote principal object, the set of permissions, and/or the access policy at the domain host for the first domain is caused based on at least one of receiving an access permission revocation from the first domain, completion of a task associated with the remote principal object, or an expiration of a temporal validity period for the remote principal object).
Regarding Claims 18 and 19, the claim limitations of are identical and/or equivalent in scope to claims 8 and 11, respectively, therefore, Claims 18 and 19 are rejected under the same rationale as claims 8 and 11.
Conclusion
THIS ACTION IS MADE FINAL. 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 MOHAMMAD YOUSUF A MIAN whose telephone number is (571)272-9206. The examiner can normally be reached Monday-Friday 9am-5:30pm.
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, ARIO ETIENNE can be reached at 571-272-4001. 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.
/MOHAMMAD YOUSUF A. MIAN/ Examiner, Art Unit 2457
/ARIO ETIENNE/ Supervisory Patent Examiner, Art Unit 2457
Prosecution Insights