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
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 07/10/2026 has been entered.
This Office Action is in response to the communication and claim Amendment
filed on 07/10/2026; claims 1-2, 12-13, and 1-2, 12-13, 17-18 have been amended; claims 1, 12, and 17 are independent claims. Claims 1-20 have been examined and are pending. This Action is made Non-FINAL.
Response to Arguments
Applicants’ arguments with respect to amended limitations “not assigned to the tenant by the parent tenant”, “in an application context associated with the tenant “, and “displaying the user profiles for selection for assignment to the first subtenant comprises excluding user profiles from … not assigned to the tenant by the parent tenant …” have been considered but are moot in view of the new ground(s) of rejection.
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, 4-5, 12, 15-16, 17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Shelton et al. (“Shelton,” US 20200089897) in view of Grebenik et al. (“Grebenik,” US 2010/0306817).
Regarding claim 1, Shelton teaches a method for data management comprising:
(a) receiving, at a data management system that is operable to provide protection for data sources associated with one or more tenants of the data management system (Shelton: fig. 5, par. 0042, "community tables stored in the tenant database within the NAS", “tenant includes three community structures 510, 520, 530"; par. 0045, System 100... application server unit 125... tenant database), an indication to create a set of subtenants of a tenant (Shelton: par. 0045, The application server unit 125 may provide the appropriate user interface to the tenant administrator 180 and process the commands/input provided by the tenant administrator 180 to manage (create, edit) the appropriate community structure. Once a tenant administrator 180 may login to the system and utilize a user interface to create the communities), a first set of user profiles being associated with the tenant (Shelton: par. 0046, "Various user types may be defined in the system"; par. 0047: "One or more users may be designated as a community administrator for a specific community") and a second set of user profiles being associated with a parent tenant of the tenant (Shelton: par. 0042, System has "tenant 500" at top level) in accordance with metadata corresponding to the first set of user profiles and the second set of user profiles ((Shelton: par. 0042: "community tables stored in the tenant database"; par. 0045: "data may be added to the database and be accessed therefrom"; pars. 0048-0049: "default parameters may be changed...defined, for example, in a field in the community table"; par. 0053: "captured in a network table in the tenant database" );
(b) assigning, in response to receiving the indication, a first subset of the first set of user profiles to a first subtenant of the set of subtenants (Shelton:; par. 0047, "community administrator may control access to the community (determine who the members are); par. 0048, Individual users can be members of one or multiple communities"; fig. 8A; par. 0062, The administrator selects a valid form for the community 815 and then manually enters data into the form for an individual 820. The information that is being entered may have been provided to the administrator []. After the information is entered and the form is submitted, the information is stored for the individual in appropriate columns of a people table in the appropriate (tenant/sub-tenant) database 825. fig. 3, par. 0033),
(d) assigning, in response to receiving the indication, a second subset of the first set of user profiles to a second subtenant of the set of subtenants ((Shelton: pars. 0042, 0043, The second community structure 520 is a multilevel community structure having a top level community 522 and a sub-community 524; par. 048, Individual users can be members of one or multiple communities. Individual users may have different privileges for different communities; par. 0062, An administrator ( or authorized user) selects manual entry on the user interface 805 and then selects the community that they want to enter information for 810 . The administrator selects a valid form for the community 815 and then manually enters data into the form for an individual 820. The information that is being entered may have been provided to the administrator []. After the information is entered and the form is submitted, the information is stored for the individual in appropriate columns of a people table in the appropriate (tenant/sub-tenant) database 825); fig. 3, par. 0033),
(f) updating, in response to assigning the first subset and the second subset, the metadata corresponding to the first set of user profiles and the second set of user profiles such that the first subset has access to the first subtenant for data management of a first data source associated with the first subtenant (Shelton: Fig. 8A; par. 0062, After the information is entered and the form is submitted, the information is stored for the individual in appropriate columns of a people table in the appropriate (tenant/sub-tenant) database 825"; See also Fig. 8C; par. 0064, If the imported file includes a unique identification for the individual (e.g., email address, phone number) that is already in the people table, but the unique identification is not system generated (e.g., badge identification), the information may be utilized to either update the existing record for the individual or to add a new record therefore."; par. 0066: See also,. par. 0042: "community tables stored in the tenant database"; par. 0045: "data may be added to the database and be accessed therefrom"; pars. 0048-0049: "default parameters may be changed...defined, for example, in a field in the community table"; par. 0053: "captured in a network table in the tenant database") such that the first subset has access to the first subtenant for data management of a first data source associated with the first subtenant ((Shelton: par. 0047, A community administrator may control access to the community (determine who the members are) and may manage all users and registrants who are members of their community; par. 0045, adding /writing/accessing data, amending structures; par. 0062, entering data; par. 64, importing data.; par. 0062, the community's database; par. 0045, data at that community's level, par. 0042, 0066; community-specific tables; par. 0042-0043, and data contained within the community) and the second subset has access to the second subtenant for data management of a second data source associated with the second subtenant (Shelton teaches this through the same structure applied to multiple communities: pars. 0042-0043, Multiple communities exist: "the tenant includes three community structures 510, 520, 530" including "sub-community 524"; par. 0047, Members gain access to their community; pars. 0045, 0062, 0064, Users perform data management activities; pars. 0043, 0045, 0062, 0066; Each community has associated data sources).
Shelton discloses (b) assigning, in response to receiving the indication, a first subset of the first set of user profiles to a first subtenant of the set of subtenants, (d) assigning, in response to receiving the indication, a second subset of the first set of user profiles to a second subtenant of the set of subtenants but does not explicitly disclose
wherein assigning the first subset of the first set of user profiles to the first subtenant comprises: (c) excluding, from the first subset, user profiles from the second set of user profiles that are not assigned to the tenant by the parent tenant; and
wherein assigning the second subset of the first set of user profiles to the second subtenant comprises: (e) excluding, from the second subset, user profiles from the second set of user profiles that are not assigned to the tenant by the parent tenant.
However, in an analogous art, Grebenik discloses
(c) excluding, from the first subset, user profiles from the second set of user profiles that are not assigned to the tenant by the parent tenant (Grebenik: par. [0023]; if User A has a delegating role assignment for a "Recipient Management" role in a "Users" OU (organizational unit), then User A can only grant that role within that scope. When User A assigns this role to User B, User B is automatically restricted to management of that OU. User A can reduce the scope of User B's assignment, but User A can never expand User B's scope beyond User A's scope (e.g., "Users" OU); par. [0022], Similar logic applies to scopes, where scopes can be compared. In this case, if a user is a delegatee (a user receiving delegated permissions from a delegator) on a role in a particular scope, the delegatee can only further grant the role within that same scope or smaller scope. The ability to modify roles is allowed according to an "organization-wide" scope, that is, the user can only modify a role if the user has no restrictions in delegation);
(e) excluding, from the second subset, user profiles from the second set of user profiles that are not assigned to the tenant by the parent tenant (Grebenik: pars. 0022, 0023).
Therefore, it would have been obvious to one of ordinary skill in the art to combine the teachings of Grebenik with the method and system of Shelton to include (c) excluding, from the first subset, user profiles from the second set of user profiles that are not assigned to the tenant by the parent tenant; (e) excluding, from the second subset, user profiles from the second set of user profiles that are not assigned to the tenant by the parent tenant. One would have been motivated to do so to keep a tenant's sub-delegation within what the tenant was itself granted, for the reason Grebenik gives — to relieve administrative load through delegation (Grebenik: par. 0002) without allowing a delegate to exceed what it received (Grebenik: par. 0004). The modification is the application of a known technique to a known system ready for improvement, yielding the predictable result that a subtenant receives only profiles the tenant was given.
Regarding claim 4, the combination of Shelton and Grebenik teaches the method of claim 1. The combination of Shelton and Grebenik further teaches wherein the first set of user profiles comprises a subset of the second set of user profiles, the subset of the second set of user profiles being assigned to the tenant by an administrator of the parent tenant (Shelton: pars. 0045, pars. 0047-0048, 0062. Shelton further discloses hierarchical administrative control over tenant configurations, wherein higher-level administrators manage which user profiles are provisioned to lower-level organizational units: Grebenik: pars. 0022, 0023).
Regarding claim 5, the combination of Shelton and Grebenik teaches the method of claim 1. The combination of Shelton and Grebenik further teaches, wherein assigning the first subset and the second subset comprises: assigning a first user profile to both the first subtenant and the second subtenant (Shelton: par. 0048 Individual users can be members of one or multiple communities; fig. 8A, par. 0062, pars. 0042, 0053).
Regarding claim 12, claim 12 directed an apparatus comprising: a processor (Shelton: par. 0032); memory (Shelton: par. 0032) coupled with the processor; and instructions stored in the memory and executable by the processor to cause the apparatus associated with the method claimed in claim 1; claim 12 is similar in scope to claim 1, and is therefore rejected under similar rationale.
Regarding claim 15, claim 15 is similar in scope to claim 4, and is therefore rejected under similar rationale.
Regarding claim 16, claim 16 is similar in scope to claim 5, and is therefore rejected under similar rationale.
Regarding claim 17, claim 17 is directed to a non-transitory computer-readable medium storing code ((Shelton: par. 0032), the code comprising instructions executable by a processor (Shelton: par. 0032) associated with the method claimed in claim 1; claim 17 is similar in scope to claim 1, and is therefore rejected under similar rationale.
Regarding claim 20, claim 20 is similar in scope to claim 4, and is therefore rejected under similar rationale.
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Shelton et al. (“Shelton,” US 20200089897) in view of Grebenik et al. (“Grebenik,” US 2010/0306817). further in view of Popov (“Popov, “US 2024/0231849).
Regarding claim 2, the combination of Shelton and Grebenik teaches the method of claim 1. The combination of Shelton and Grebenik further teaches comprising:
(a) receiving, via a user interface in an application context associated with the tenant of the data management system, the indication to create the set of subtenants of the tenant (Shelton: par. 0038, "the application server unit provides instructions utilized to generate a user interface for the tenant administrator and the tenant administrator selects to an add a community and then selects a name for the new community 420. The application server unit processes the selection and input provided by the tenant administrator on the user interface);
(b) displaying, via the user interface, user profiles for selection for assignment to the first subtenant, wherein the user profiles comprise at least the first set of user profiles (Popov: par. 0048, in combination with Shelton: pars. 0035, 0066 and Grebenik: pars. 0023, 0022; Popov: par. 0048. "the admin plug-in GUI can include an assignment page that allows admin users to assign groups to the cluster." "The admin user can select an option for adding a user group, which can cause the admin plug-in GUI to display a window for assigning a new user group." "In one example, a multi-selectable list of user groups can be displayed that allows the admin user to select one or multiple user groups."; Shelton: par. 0035. "Communities are a user hierarchy that replicates an organizational structure... Communities are a way to configure a database structure for managing people as a nested or linear grouping. The community structure, whether simple or complex, may automatically compartmentalize people (records) in groups.": Shelton: par. 0066 "the information provided within the user interfaces may be based on information stored in various tables in the database on the NAS 150 for the particular tenant and selections made on the user interfaces. For example, the communities available may be based on information previously stored in the community table.": Grebenik: pars. 0022, 0023, "When User A assigns this role to User B, User B is automatically restricted to management of that OU." ; par. 0023: "User A can reduce the scope of User B's assignment, but User A can never expand User B's scope beyond User A's scope (e.g., 'Users' OU)."; par. 0022: "the delegatee can only further grant the role within that same scope or smaller scope.").
The combination of Shelton and Grebenik does not explicitly disclose (c) “receiving, via the user interface, user input comprising a first selection of the first subset of the first set of user profiles, wherein the assigning the first subset to the first subtenant is in response to the first selection;”(d) receiving, via the user interface, user input comprising a second selection of the second subset of the first set of user profiles, wherein the assigning the second subset to the second subtenant is in response to the second selection.
However, in an analogous art, Popov discloses
(c) receiving, via the user interface, user input comprising a first selection of the first subset of the first set of user profiles, wherein the assigning the first subset to the first subtenant is in response to the first selection (Popov: par. 0048, in combination with Shelton : pars 0033, 0035; Popov: par. 0048. "The admin user can select one or more user groups to assign to the cluster." "In one example, a multi-selectable list of user groups can be displayed that allows the admin user to select one or multiple user groups."; Popov: par. 0048. "the admin plug-in GUI can include an assignment page that allows admin users to assign groups to the cluster." "The admin user can select one or more user groups to assign to the cluster.")
(d) receiving, via the user interface, user input comprising a second selection of the second subset of the first set of user profiles, wherein the assigning the second subset to the second subtenant is in response to the second selection ((Popov: par. 0048, in combination with Shelton: pars. 0033, 0035; Popov: par. 0048. "In one example, a multi-selectable list of user groups can be displayed that allows the admin user to select one or multiple user groups." "The admin user can also search for user groups using a search feature."; Popov: par. 0048. "the admin plug-in GUI can include an assignment page that allows admin users to assign groups to the cluster." "The admin user can select one or more user groups to assign to the cluster."
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Popov with the method of Shelton and Grebenik to include limitations (b), (c), and (d). One would have been motivated to do so because Popov identifies the need for "providing workflow authorizations and restrictions over workflows for users logged into" a managed application (Popov: par. 0004),and meets that need with an assignment page and a multi-selectable list from which an administrator selects user groups to assign (Popov: par. 0048). Applying that displayed, selectable assignment page to the tenant administrator interface of Shelton (Shelton: par. 0038) is the application of a known technique to a known system ready for improvement, with the predictable result that an administrator selects user profiles from a displayed list to assign them to a subtenant.
Regarding claim 13, claim 13 is similar in scope to claim 2, and is therefore rejected under similar rationale.
Regarding claim 18, claim 18 is similar in scope to claim 2, and is therefore rejected under similar rationale.
Claims 3, 14, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Shelton et al. (“Shelton,” US 20200089897) in view of Grebenik et al. (“Grebenik,” US 2010/0306817), further in view of Loiseau et al. (“Loiseau,” US 2020/0274903).
Regarding claim 3, the combination of Shelton and Grebenik teaches the method of claim 1. Shelton teaches a multi-tenant system where tenant administrators manage (Shelton: par. 0047, "an entire database for the tenant... including all communities"), users have (Shelton: par. 0046, "login privileges to the system"), and user information is stored in databases (Shelton: pars. 0047-0048, 0062). Shelton teaches the multi-tenant structure, parent tenant administrators, and user management, but does not explicitly describe using an SSO directory service.
Loiseau teaches that "The authentication service 170 may comprise a lightweight directory access protocol (LDAP) service, a single sign-on (SSO) service such as VMware's vCenter SSO, an active directory (AD) service, or any other suitable authentication module." (Loiseau: par. 0038). LDAP and Active Directory are directory services that store user accounts and credentials - this is their fundamental purpose. These directory services provide single sign-on capability where users authenticate once to access multiple systems.
It would have been obvious to one of ordinary skill in the art to implement Shelton's user authentication and management using an SSO directory service such as LDAP, Active Directory, or an SSO service as taught by Loiseau. The motivation includes centralized user management, single sign-on convenience (users log in once to access multiple tenants/communities), improved security, and simplified administration - all well-known benefits of directory-based authentication in enterprise systems.
In such an obvious combination, Shelton's tenant administrators par. 0047 (who operate at the parent tenant level and manage the entire tenant database) would configure the LDAP/Active Directory/SSO service for their specific tenant, as it would be obvious that IT administrators configure directory services for organizational units. LDAP and Active Directory inherently support multi-tenant configurations through organizational units, domains, and other well-known directory features, making it a predictable use of these directory services according to their established functions to configure them for specific tenants. User profiles would be stored in and associated with the directory service, as that is the fundamental purpose of LDAP and Active Directory systems. (Shelton: par. 0045-0048, 0062; Loiseau: par. 0038)).
Regarding claim 14, claim 14 is similar in scope to claim 3, and is therefore rejected under similar rationale.
Regarding claim 19, claim 19 is similar in scope to claim 3, and is therefore rejected under similar rationale.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Shelton et al. (“Shelton,” US 20200089897) in view of Grebenik et al. (“Grebenik,” US 2010/0306817), and Da Silva Baptista Russo et al. (“Baptista ,” US 12,190,047), further in view of Qu (“Qu,” US 2017/0103243).
Regarding claim 6, the combination of Shelton and Grebenik teaches the method of claim 5. Shelton teaches a multi-tenant system with communities (subtenants) (Shelton: pars. 0042-0043) where users login to the system (Shelton: pars. 0045-0046, 0048). Shelton teaches individual users can be members of multiple communities. Shelton does not disclose receiving, at the first subtenant of the data management system, a login request for the first user profile;
However, in an analogous art, Baptista teaches tenant-specific access where “the tenant variable may be determined in several ways”, including “iii. for the case of web applications, implied by the sub-domain of the entry point URL (e.g. my-corp.my-cloud.com)” (Baptista: Col. 16, lines 16-24). Baptista further teaches that “3. If the end user is successfully authenticated against the determined tenant, he continues to the initial access point.” (Baptista: Col. 16, lines 12-24).
Baptista’s teaching that tenant is “implied by the sub-domain of the entry point URL” teaches that users access tenant-specific subdomains as their entry point. When a user accesses my-corp.my-cloud.com), this subdomain is the “entry point URL” for the my-corp tenant. The login request is received at this tenant-specific entry point, which constitute receiving the login request “at” the tenant (subtenant).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Baptista with the method and system of Shelton to include “receiving, at the first subtenant of the data management system, a login request for the first user profile;” One would have been motivated to provide the systems and methos for efficiently and reliably making a variety of document ele-ments available to a variety of document applications of a system, while further preferably offering a common expe-rience, style and business logic, preferably for specific (Baptista: Col. 2, lines 4046).
Shelton and Baptista do not explicitly discloses determining, in response to the login request and based at least in part on metadata associated with the first user profile, that the first user profile is assigned to both the first subtenant and the second subtenant; and enforcing, based at least in part on determining that the first user profile is assigned to both the first subtenant and the second subtenant, a login procedure associated with a higher security setting between a first login procedure associated with the first subtenant and a second login procedure associated with the second subtenant.
However, in an analogous art, Qu teaches that “a user may be assigned to multiple roles” (Qu: par. 0101; In that situation, the security level of the user is assigned to the highest security level of the all the roles to which user is assigned.). Qu further teaches the system determines multi-role (multi-tenant) assignment (Qu: par. 0119: a single user who have been assigned to multiple roles and an appropriate highest security level among the multiple roles).
Qu teaches the security level of the user is assigned to the highest security level of the all the roles which user is assigned (Qu: par. 0101, “In that situation …highest security level among the multiple roles”; par. 0119).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Qu with the method and system of Shelton, Grebenik, and Baptista to include determining, in response to the login request and based at least in part on metadata associated with the first user profile, that the first user profile is assigned to both the first subtenant and the second subtenant; and enforcing, based at least in part on determining that the first user profile is assigned to both the first subtenant and the second subtenant, a login procedure associated with a higher security setting between a first login procedure associated with the first subtenant and a second login procedure associated with the second subtenant . One would have been motivated to define roles and security levels relating to a service for users, and thus reduces the costs of building application servers by service providers (Qu: pars. 0026, 0101).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Shelton et al. (“Shelton,” US 20200089897) in view of Grebenik et al. (“Grebenik,” US 2010/0306817), and Da Silva Baptista Russo et al. (“Baptista ,” US 12.190,047), and Qu (“Qu,” US 2017/0103243), and further in view of Ping et al. (“Ping,” US 2022/0239700).
Regarding claim 7, the combination of Shelton, Grebenik, Baptista, and Qu teaches the method of claim 6. The combination of Shelton. Grebenik, Baptista, and Qu teaches the higher security setting to roles which user is assigned but does not explicitly “wherein the higher security setting is associated with a password length, a password character requirement, a two-factor authentication requirement, a password change periodicity requirement, or a combination thereof.”
However, in an analogous art, Ping teaches: "the security level can be represented by the length of the password" using "16-bit, 32-bit, and 64-bit passwords" where "64-bit password... has the highest security level." (Ping: par. 0055: the security degree may be represented by the security level of the security requirement. For example, three security requirements indicate using 16-bit, 32-bit, and 64-bit passwords respectively. In this case, the security level can be represented by the length of the password. Then the security requirement indicating 64-bit password used has the highest security level, and thus the security requirement indicating using the 64-bit password is selected as the combined security requirement).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Ping with the method and system of Shelton, Grebenik, Baptista, and Qu to include “wherein the higher security setting is associated with a password length, a password character requirement, a two-factor authentication requirement, a password change periodicity requirement, or a combination thereof.” One would have been motivated to implement Qu's highest-security-level enforcement using password length as the security parameter (Ping: par. 0055, Qu: pars. 0101, 0119).
Claims 8-9 are rejected under 35 U.S.C. 103 as being unpatentable over Shelton et al. (“Shelton,” US 20200089897) in view of Grebenik et al. (“Grebenik,” US 2010/0306817), further in view of Prasad et al. (“Prasad,” US 2014/0215595).
Regarding claim 8, the combination of Shelton, Grebenik teaches the method of claim 5. The combination of Shelton and Grebenik further teaches users who can be member of multiple communities (Shelton: par. 0048). Shelton and Grebenik do not teach explicitly disclose receiving, at a first user interface associated with the first subtenant and from the first user profile, a request to switch to the second subtenant; determining, in response to receiving the request to switch and based at least in part on metadata associated with the first user profile, that the first user profile is assigned to both the first subtenant and the second subtenant; and activating, based at least in part on determining that the first user profile is assigned to both the first subtenant and the second subtenant, a second user interface associated with the second subtenant.
However, in an analogous art, Prasad discloses switching request: "The user may switch the context from one user account to another user account by using a drop-down menu provided on a graphical user interface." (Prasad: 0050, The user may switch the context from one user account to another user account by using a drop-down menu provided on a graphical user interface of the multi-tenanted application. The drop-down menu lists the plurality of user accounts which is available for the user to access).
determination multi-assignment: “the association module identifies the user accounts associated with the security token... access to all three user accounts" (Prasad: par. 0048, if the association module 114 identifies that there are three user accounts associated with the security token, the association module 114 may provide the user with the access to all three user accounts in the multi-tenanted application; par. 0050, "drop-down menu lists the plurality of user accounts").
activating second interface: "switch to the context from the default user account to any of his other user accounts" (Prasad: 0048, part. 0050, "switch the context from one user account to another").
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Prasad with the method and system of Shelton and Grebenik to include receiving, at a first user interface associated with the first subtenant and from the first user profile, a request to switch to the second subtenant; determining, in response to receiving the request to switch and based at least in part on metadata associated with the first user profile, that the first user profile is assigned to both the first subtenant and the second subtenant; and activating, based at least in part on determining that the first user profile is assigned to both the first subtenant and the second subtenant, a second user interface associated with the second subtenant. One would have been motivated to implement Prasad's switching mechanism in Shelton's multi-community system for seamless navigation without logout/login (Shelton: par. 0048: Prad: pars. 0017, 0048, 0050).
Regarding claim 9, the combination of Shelton, Grebenik, and Prasad teaches the method of claim 8. The combination of Shelton, Grebenik, and Prasad further teaches, wherein the second user interface is activated without requiring a new login procedure for the first user profile (Prasad: par. 0017, the user is provided with access to all his user accounts in the multi-tenanted application without requiring any further login and logout; par. 0048).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Shelton et al. (“Shelton,” US 20200089897) in view of Grebenik et al. (“Grebenik,” US 2010/0306817), further in view of Gordon et al. (“Gordon,” US 2021/0136083,).
Regarding claim 10, the combination of Shelton and Grebenik discloses the method of claim 5. The combination of Shelton and Grebenik teaches that users can be members multiple communities (Shelton: par. 0048). Shelton and Grebenik do not explicitly disclose: receiving, at a first user interface associated with the first subtenant and from the first user profile, a request to reset authentication parameters associated with the first user profile; determining, in response to receiving the request to reset authentication parameters, that the first user profile is assigned to both the first subtenant and the second subtenant; denying, at the first subtenant and based at least in part on determining that the first user profile is assigned to both the first subtenant and the second subtenant, the request to reset the authentication parameters.
However, in an analogous art, Gordon teaches
submitting requests to access management service involving authorization credentials and user information (Gordon: par. 0045, The application may submit a request to the access management service 135 via the API that includes information that identifies the application and the user requesting access to the application. The information identifying the application may include a unique identifier for the application and may also include an identifier of the tenant with which the application is associated. The user information may include a username, user identifier, authorization credentials, and/or other information related to the user).
determining multi-tenant assignment (Gordon: par. 0045, the access management service 135 may be configured to look up the user account in the tenant associated with the request and determine whether the user account is associated with a software license … user may have multiple user accounts across multiple tenant …checks the access privileges associated with the user account in a particular tenant.).
denying access at tenant level for users with multiple accounts across tenants (Gordon: par. 0045, "if the user account in that tenant does not have a valid software license or other access privilege indicating that the user may access the software, the user will be denied access to the software.. "a user may have multiple user accounts across multiple tenants, and one of those user accounts may have a valid license or other access privilege that indicates that the user is permitted to access the software. However, because the conventional access privilege check only checks the access privileges associated with the user account in a particular tenant, the user will still be denied access to the software application.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Gordon with the method and system of Shelton and Grebenik to include receiving, at a first user interface associated with the first subtenant and from the first user profile, a request to reset authentication parameters associated with the first user profile; determining, in response to receiving the request to reset authentication parameters, that the first user profile is assigned to both the first subtenant and the second subtenant; denying, at the first subtenant and based at least in part on determining that the first user profile is assigned to both the first subtenant and the second subtenant, the request to reset the authentication parameters; and . One would have been motivated to apply Gordon's teachings of access management and denial of actions at the tenant level for users with presence in multiple tenants to Shelton's multi-community system where users can be members of multiple communities.
Gordon does not explicitly teach transmitting an indication to the user after denying the request. However, it would have been obvious to one of ordinary skill in the art to provide such an indication directing the user to submit the request via the parent tenant interface.
Gordon teaches a hierarchical multi-tenant system where requests are denied at the individual tenant level for users with accounts across multiple tenants (Gordon: par. 0045). Given this teaching, one of ordinary skill in the art would recognize that when a request is denied at the subtenant level, the user must perform the action at a higher organizational level-the parent tenant. It would have been obvious to inform the user of this requirement through a notification, message, or indication displayed via the user interface. This represents the application of common sense and basic user interface design principles: when a system denies a user's requested action, the system should inform the user why the action was denied and provide guidance on how to accomplish the task through an alternative means. The motivation to provide such an indication is multifold:
First, it improves user experience by guiding the user to the correct location for performing the action, rather than leaving the user frustrated with a mere denial and no guidance.
Second, it reduces support burden by enabling users to self-serve and find the correct interface without needing to contact IT support or help desk.
Third, it provides a complete and logical user workflow consistent with Gordon's hierarchical tenant structure. Gordon's teaching that actions are restricted at the individual tenant level for multi-tenant users inherently implies that such actions must be performed at a higher level. One of ordinary skill would recognize that the logical higher level in a hierarchical multi-tenant system is the parent tenant and would find it obvious to direct users there through an interface notification.
This represents a predictable use of prior art elements (Gordon's tenant-level denial mechanism) combined with known user interface practices (providing user guidance after denial) to yield a predictable result (users successfully directed to the appropriate parent tenant interface).
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Shelton et al. (“Shelton,” US 20200089897), in view of Grebenik et al. (“Grebenik,” US 2010/0306817), further in view of Gandhi (“Gandhi,” US 2023/0396620).
Regarding claim 11, the combination of Shelton and Grebenik teaches the method of claim 1. The combination of Shelton and Grebenik further teaches, further comprising:
receiving, at a user interface associated with the first subtenant (Shelton: Fig. 8A, par. 0062, An administrator "selects manual entry on the user interface 805 and then selects the community that they want to enter information for 810" and "selects a valid form for the community 815."; par. 0066, The application server "may provide the information needed to generate the appropriate user interfaces.").
Shelton does not explicitly disclose “an indication of a first set of internet protocol (IP) addresses that are to be whitelisted for accessing the first subtenant, wherein the first set of IP addresses are different from a second set of IP addresses that are whitelisted for accessing the second subtenant.”
However, in an analogous art, Gandhi discloses an indication of a first set of internet protocol (IP) addresses that are to be whitelisted for accessing the first subtenant (Gandi: par. 0027, receiving an indication of a set of IP addresses which describe "three ACL allow rules for IP addresses" including "Rule 1 'allow 10.0.0.0,' Rule 2 'allow 10.0.0.1,' and Rule 3 'allow 10.0.0.3.'"; par. 0034, The ACL rules 10 include one or more allow rules 12. The allow rules 12 specify the allowed IP addresses that have permission to access applications, services, and/or machines provided by a service provider." The allow rules can "specify one or more IP addresses allowed access within one or more organizations; Shelton: pars. 0047, 0052).
Regarding to "wherein the first set of IP addresses are different from a second set of IP addresses that are whitelisted for accessing the second subtenant."
Shelton teaches multiple subtenants (communities) with independent configurations. Shelton describes "the tenant includes three community structures 510, 520, 530" (Shelton: par. 0042), explicitly teaching a first community and a second community. Each community can have different parameters, as "a community administrator may be able to amend the community structure, or the parameters associated therewith" (Shelton: par. 0045) on a per-community basis.
Gandhi teaches that different organizations have different sets of IP addresses. Gandhi states: "Each organization is assigned a range of IP addresses." (Gandhi: par. 0034). This teaching that "each organization" has its own "range of IP addresses" inherently means different organizations have different IP address ranges - otherwise there would be no reason to state "each organization" separately.
Gandhi also distinguishes between "IP addresses within a same organization" (Gandhi: par. 0027) versus different organizations and describes ensuring "the additional IP addresses are assigned to the same organization assigned to the IP addressed in the allow rules" versus "a different organization" (Gandhi: par. 0042). This explicit distinction between "same organization" and "different organization" with respect to IP addresses teaches that different organizations have different sets of IP addresses.
In combination, it would have been obvious to configure different IP whitelists for Shelton's different communities (subtenants) following Gandhi's teaching that each organization has its own assigned IP address range. The first community (first subtenant) would have a first set of allowed IP addresses, and the second community (second subtenant) would have a different second set of allowed IP addresses, applying Gandhi's per-organization IP ranges par. 0023 to Shelton's multi-community structure pars. 0042-0043.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Gandhi with the method and system of Shelton and Grebenik to include “wherein the first set of IP addresses are different from a second set of IP addresses that are whitelisted for accessing the second subtenant.” One would have been motivated to enable receiving multiple ACL rules with multiple rules with allowed IP addresses to calculate minimum number of bit changes to transform the IP address of the allowed IP addresses to another IP address, thus reducing the number of ACL rules in an efficient manner (Gandhi: par. 0003).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CANH LE whose telephone number is (571)270-1380. The examiner can normally be reached on Monday to Friday 6:00AM to 3:30PM other Friday off.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Luu Pham, can be reached at telephone number 571-270-5002. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR for authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/Canh Le/
Examiner, Art Unit 2439
August 20th, 2026
/LUU T PHAM/Supervisory Patent Examiner, Art Unit 2439
Prosecution Insights