DETAILED ACTION
This Action is in response to Application Number 18/238119 received on 8/25/2023.
Claims 1-10 are presented for examination.
This application claims foreign priority to 2023-006837, filed 1/19/2023.
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 .
Claim Interpretation
Before a detailed mapping, the following is to assist Applicant in making any future amendments to the claims.
MPEP 2111.04 Section II recites, “The broadest reasonable interpretation of a method (or process) claim having contingent limitations requires only those steps that must be performed and does not include steps that are not required to be performed because the condition(s) precedent are not met. For example, assume a method claim requires step A if a first condition happens and step B if a second condition happens. If the claimed invention may be practiced without either the first or second condition happening, then neither step A or B is required by the broadest reasonable interpretation of the claim. If the claimed invention requires the first condition to occur, then the broadest reasonable interpretation of the claim requires step A. If the claimed invention requires both the first and second conditions to occur, then the broadest reasonable interpretation of the claim requires both steps A and B.”
Claim 10 recites a method claim with two contingent limitations, each beginning with “upon determining a result of the authorization determination is positive…”. While these limitations have been mapped in the following rejection(s), it should be noted that claim 10, under the broadest reasonable interpretation of the claim, does not require the authentication determination to be positive. Therefore, under the broadest reasonable interpretation of claim 10, the two contingent limitations are not accorded patentable weight. Examiner suggests adding a preceding step of “determining that a result of the authorization determination is positive” thereby requiring the condition to occur, requiring that the contingent limitations be accorded patentable weight.
Claim Rejections - 35 USC § 103
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 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.
Claim(s) 1-10 are rejected under 35 U.S.C. 103 as being unpatentable over Ahmed et al. (US 8291490) in view of Buchmann et al. (US 20240143808).
Regarding claim 1, Ahmed disclosed a multitenant management system (Ahmed, col. 5, lines 5-9, “The services hosting platform includes a services hosting framework which may be shared by multiple tenants”; col. 5, lines 45-47, “multi-tenant service delivery”) comprising:
an interface device configured to receive, from a user terminal, user information of a user, tenant information of a tenant, and a resource access request that designates a resource of an access destination among a plurality of resources (col. 11, lines 4-18, client issues a request that includes token to access a service/program; col. 11, lines 19-30, “Role Based Access Control (RBAC). Role based access control ensures that only those users at the tenants having desired access attributes may utilize the program. To perform RBAC, certain authorization checks of the user should be performed. Token expiration time, a tenant ID, a user ID, and group IDs information in the token may be used to determine whether a user at a tenant is permitted to access the particular service. An API may be included as part of the Services hosting platform to check user Roles and Capabilities.”);
a storage device configured to store user management information including information regarding the user associated with the tenant corresponding to a tenant ID for a plurality of tenant IDs (Ahmed, Fig. 4, Service Tier 250 including plurality of databases 275, which include User and & Tenant DB, for example; col. 2, lines 16-48, Ahmed disclosed managing user access to application-specific capabilities, involving “maintaining data correlating user identifiers with roles, maintaining data correlating user roles with application-specific capabilities, and managing the data using a security module that accesses the data correlating application-specific capabilities, data correlating user identifiers, and the data correlating user roles. The system may have a plurality of tenants and wherein each of the tenants subscribes to one or more of the applications. Each of the users may correspond to a particular one of the tenants. Each tenant may subscribe to a particular set of applications/features… Managing user access to application-specific capabilities of a system may also include providing a token that correlates user identifiers with user roles.”; As noted above with respect to col. 11, lines 4-18, “Token expiration time, a tenant ID, a user ID, and group IDs information in the token may be used to determine whether a user at a tenant is permitted to access the particular service”; The system of Ahmed includes a storage of tenant information of a plurality of tenants, in which each tenant has clients/users subscribed, and managing authorization by utilizing tenant ID, user ID, and group ID, for example); and
a processor connected to the interface device and the storage device (col. 28, lines 46-67),
wherein in each tenant ID, the user management information includes information indicating a tenant scope that is a label of a resource access range for each of one or two or more tenants (Ahmed, col. 11, lines 4-18, Each tenant is represented by a tenant ID; col. 2, lines 16-48, Each tenant is subscribed to a particular set of applications/features… Managing user access to application-specific capabilities of a system may also include providing a token that correlates user identifiers with user roles.”; As noted above with respect to col. 11, lines 4-18, “Token expiration time, a tenant ID, a user ID, and group IDs information in the token may be used to determine whether a user at a tenant is permitted to access the particular service”; col. 24, lines 26-65, Ahmed disclosed tenant and subtenant setup, providing limitations, restrictions, rights, roles, quotas to tenants/subtenants/users; col. 25, lines 15-23, Ahmed disclosed limiting user access to applications/feature sets “which have not been provided to the corresponding tenant”, and also provides a “quota” for the tenant for a particular application/feature set which may not exceed a sum of quotes of the tenant’s users for the particular application feature set),
wherein the storage device stores entire scope management information indicating a resource access range corresponding to the tenant scope for each tenant scope (Ahmed, col. 11, lines 4-18, Each tenant is represented by a tenant ID; col. 2, lines 16-48, Each tenant is subscribed to a particular set of applications/features… Managing user access to application-specific capabilities of a system may also include providing a token that correlates user identifiers with user roles.”; As noted above with respect to col. 11, lines 4-30, “Token expiration time, a tenant ID, a user ID, and group IDs information in the token may be used to determine whether a user at a tenant is permitted to access the particular service”; col. 24, lines 26-65, Ahmed disclosed tenant and subtenant setup, providing limitations, restrictions, rights, roles, quotas to tenants/subtenants/users; col. 25, lines 15-23, Ahmed disclosed limiting user access to applications/feature sets “which have not been provided to the corresponding tenant”, and also provides a “quota” for the tenant for a particular application/feature set which may not exceed a sum of quotes of the tenant’s users for the particular application feature set; See also col. 25, lines 22-30, in which application-specific roles/capabilities/quotas may be managed on a per tenant basis),
wherein the processor is programmed to:
select a tenant ID corresponding to a tenant indicated by the received tenant information (Ahmed, col. 25, lines 36-45, “the security API 711 may return values indicating the roles and possible level(s) of access for a particular user/tenant to a calling program that conditionally executes certain code to enable or disable the features for the user/tenant”; determining the particular level of access for the tenant involves using the tenant ID received with the request/token indicated above),
execute authentication determination to determine whether the received user information is appropriate for information included in the user management information of the selected tenant ID (Ahmed, col. 25, lines 36-45, “the security API 711 may return values indicating the roles and possible level(s) of access for a particular user/tenant to a calling program that conditionally executes certain code to enable or disable the features for the user/tenant”; col. 26, lines 5-46, Ahmed disclosed authorization for application-specific capabilities maintained in order to check proper user/tenant roles and determine proper access; See also col. 26, lines 48-67),
upon determining a result of the authentication determination is positive, executes authorization determination to determine whether a resource of an access destination conforming to the received resource access request falls within a resource access range specified from the entire scope management information to correspond to one tenant scope indicated by the user management information of the selected tenant ID (Ahmed, col. 26, line 48 through col. 27, line 30, Ahmed disclosed authorization of the user and a determination at what level the user has access to, and provides an example as to which level of application falls within the range of the user’s access; As noted above, such involves utilization of tenant information/ tenant ID to determine access), and
upon determining a result of the authorization determination is positive, execute the received resource access request (Ahmed, col. 26, line 48 through col. 27, line 30, Ahmed disclosed authorization of the user and a determination at what level the user has access to, and provides an example as to which level of application falls within the range of the user’s access; Once authorization is determined and the correct application version is determined, the application invokes that particular level; col. 27, lines 30-45, Ahmed disclosed granting access either via token or dynamically “up-to-date” to which, at col. 27, line 60 through col. 28, line 3, an allowed indicator is returned or not).
While Ahmed relies on the utilization of tenant ID’s, Ahmed did not explicitly disclose a “name space”, as claimed.
However, the name spaces in the claim are merely used as identifiers of each tenant, utilized to determine proper access to resources, as claimed. Since Ahmed’s utilization of tenant ID is used for the same purpose as explained above, it would have been within the level of one of ordinary skill in the art that Ahmed’s tenant IDs reasonably amount to the claimed namespaces, as they are used for the same purpose.
Therefore it would have been obvious to one of ordinary skill in the art at the time the invention was filed to interpret Ahmed’s tenant IDs within the teachings of Ahmed as the claimed namespaces, as doing so has no bearing on the claimed functionality, since they are functionally utilized in the same manner, thereby obtaining predictable results of controlling resource access in the same manner.
Regardless, in an analogous art, Buchmann disclosed the utilization of “namespaces” associated with tenants for the purpose of access control (Buchmann, [0101], [0113]).
One of ordinary skill in the art would have been motivated to combine the teachings of Ahmed and Buchmann as they both relate to tenant namespace management, and as such they are within similar environments.
Therefore it would have been obvious to one of ordinary skill in the art at the time the invention was filed to incorporate the namespace management techniques of Buchmann within the teachings of Ahmed in order to prevent and correct collisions, thereby obtaining the desirability of having unique namespaces (Buchmann, [0114]), in order to maintain integrity of particular sets of content (Buchmann, [0005]), thereby making the system more desirable to use by its customers.
Claim 10 recites a method with step limitations that are substantially similar to the functionality implemented in the limitations above with respect to claim 1. Claim 10 is therefore rejected under the same rationale applied above with respect to claim 1.
Regarding claim 2, Ahmed and Buchmann disclosed the multitenant management system according to claim 1, wherein the plurality of name spaces include a name space for system management serving as a name space corresponding to an unspecified tenant, and wherein one or two or more tenant scopes associated with the name space for the system management include a system scope associated with a range of all resources (Ahmed, col. 24, lines 26-50, Ahmed disclosed wherein each tenant may have a root role that describes the available capabilities of the tenant, where the root role is created and managed by a parent tenant. The root tenant may handle issuing capabilities to all other users and/or subtenants of the system. Col. 2, lines 60-67, Each tenant may subscribe to one or more applications/features, and therefore the root tenant may have rights to all services that the tenant is subscribed, which may include all services/applications/features provided). See motivation above.
Regarding claim 3, Ahmed and Buchmann disclosed the multitenant management system according to claim 2, wherein the user management information of the name space for the system management indicates a tenant scope for the tenant corresponding to a name space different from the name space for the system management (Ahmed, col. 24, lines 26-50, Ahmed disclosed “The tenant 2001 may be referred to as the "root tenant" or a "supertenant" and may handle issuing capabilities to all other users and/or subtenants of the system. Each time the tenant 2001 (or any other tenant/subtenant) creates a new subtenant, the tenant 2001 may impose limitations of the capabilities of the subtenant, such as restrictions on the ability to create further subtenants, limitations on users, access to services, disk usage, other quotas, etc. In an embodiment herein, a tenant/subtenant may not grant to a further subtenant more rights than the tenant/subtenant possesses. Thus, for example, if the subtenant 2011 has been granted rights to use services A, B, C, and D, only, then the subtenant 2011 may not grant rights to use other services (e.g., service E) to any of the further subtenants 2021-2023”; That is, there are different subtenant namespaces that may have either the same or less access ranges and therefore different scope than the parent tenant), and
wherein upon the name space for the system management is selected from the received tenant information and a result of the authentication determination is positive using the user management information of the name space for the system management, the processor is programmed to specify the tenant scope for the tenant corresponding to the different name space and associated with the name space for the system management based on the resource access request in the authorization determination and specifies a resource access range corresponding to the tenant scope from the entire scope management information (Ahmed, col. 26, line 48 through col. 27, line 30, Ahmed disclosed authorization of the user and a determination at what level the user has access to, and provides an example as to which level of application falls within the range of the user’s access; Once authorization is determined and the correct application version is determined, the application invokes that particular level; col. 27, lines 30-45, Ahmed disclosed granting access either via token or dynamically “up-to-date” to which, at col. 27, line 60 through col. 28, line 3, an allowed indicator is returned or not; As noted in the above mappings, such authorization is also based on tenant ID). See motivation above.
Regarding claim 4, Ahmed and Buchmann disclosed the multitenant management system according to claim 1, wherein, in each name space, the user management information includes information indicating one or two or more tenant scopes associated with a group for each group of users (Ahmed, col. 24, lines 26-50, The user/tenant roles specify scopes associated with a group for each group of users). See motivation above.
Regarding claim 5, Ahmed and Buchmann disclosed the multitenant management system according to claim 1, wherein the plurality of resources are resources of a storage system (Ahmed, col. 7, line 65 through col. 8, line 16, col. 8, lines 26-50). See motivation above.
Regarding claim 6 Ahmed and Buchmann disclosed the multitenant management system according to claim 1, wherein when information regarding a first user of a first tenant and information regarding a second user of a second tenant are included in user management information of a single name space, and wherein the processor is programmed to: create a name space corresponding to the second tenant, and transfer the information regarding the second user of the second tenant to the user management information of the created name space (Buchmann, [0025] and [0028], With respect to tenants associated with users and access, [0114], Buchmann disclosed tenant namespace registry and detecting namespace collisions for same identifier for different namespaces, “If a collision is detected, the system can optionally not register the namespace and return an error in response to the request, or can assign a different name (such as adding “_1,” “_2” to a name), or add a higher-level, “root” namespace, to either an existing namespace or a namespace being added.”). See motivation above.
Regarding claim 7, Ahmed and Buchmann disclosed the multitenant management system according to claim 1, wherein user management information of a certain name space among the plurality of name spaces includes information regarding one or more users registered in user management information of one or more name spaces different from the certain name space (Ahmed, col. 24, lines 24-25, “it is possible in other embodiments to have a user associated with more than one tenant”).
Regarding claim 8, Ahmed and Buchmann disclosed the multitenant management system according to claim 7, wherein the user management information of the certain namespace includes information indicating a name space where the information regarding the user is registered with regard to each of the one or more users, and wherein the processor is programmed to specify a name space corresponding to a user indicated by the user information from the user management information of the certain name space, and execute the authentication determination based on the user management information of the specified name space and the user information (Ahmed, Fig. 18, Ahmed disclosed the registration process for tenants; As noted above each tenant has a respective tenant ID namespace; col. 11, lines 19-30, Ahmed disclosed checking user access by ensuring that only those users at the tenants (e.g. proper user ID and Tenant ID) having desired access attributes are permitted to access the particular service; It is evident that such involves authorizing against the stored user/tenant information, which requires specifying/accessing it in order to authorize).
Regarding claim 9, Ahmed and Buchmann disclosed the multitenant management system according to claim 1, wherein the storage device stores user affiliation information that is information indicating a name space where a user is registered for each user, and the processor is programmed to specify a name space corresponding to the user indicated by the user information, and execute the authentication determination based on the user management information of the specified name space and the user information (Buchmann, [0028], Buchmann disclosed users having different levels of access within tenant, [0035] determine if a user making a request associated for an object associated with a namespace, is permitted to do so in the namespace; See also [0099], [0102], and [0111], in which Buchmann disclosed maintaining namespace information including user making a request, and using namespace registry for access control).
Response to Arguments
Applicant's arguments filed 9/08/2025 have been fully considered but they are not persuasive.
Applicant asserts, Ahmed and Buchman did not disclose “wherein the storage device stores entire scope management information indicating a resource access range corresponding to the tenant scope for each tenant scope, [and] upon determining a result of the authentication determination is positive, execute authorization determination to determine whether a resource of an access destination conforming to the received resource access request falls within a resource access range specified from the entire scope management information to correspond to one tenant scope indicated by the user management information of the selected name space”, as set forth in claim 1. That is, Ahmed does not disclose the claimed configuration which enables managing of the users independently with respect to each tenant and allowing a user who belongs to a certain tenant to access resources of another tenant to which the above-mentioned user does not belong, as in the presently claimed invention." [Response, p13, and p14].
Examiner respectfully disagrees.
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies, explained below, are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Specifically, claim 1 does not require, by any means, a user who belongs to a certain tenant to access resources of another tenant to which the above-mentioned user does not belong".
The initial limitation merely requires the storage of scope information indicating a resource access range corresponding to a tenant scope for each tenant scope. Such does not require any particular type of resource access, nor does such define any particular access range, let alone a range that spans across tenants, as Applicant appears to intend.
Ahmed disclosed wherein the storage device stores entire scope management information indicating a resource access range corresponding to the tenant scope for each tenant scope (Ahmed, col. 11, lines 4-18, Each tenant is represented by a tenant ID; col. 2, lines 16-48, Each tenant is subscribed to a particular set of applications/features… Managing user access to application-specific capabilities of a system may also include providing a token that correlates user identifiers with user roles.”; As noted above with respect to col. 11, lines 4-30, “Token expiration time, a tenant ID, a user ID, and group IDs information in the token may be used to determine whether a user at a tenant is permitted to access the particular service”; col. 24, lines 26-65, Ahmed disclosed tenant and subtenant setup, providing limitations, restrictions, rights, roles, quotas to tenants/subtenants/users; col. 25, lines 15-23, Ahmed disclosed limiting user access to applications/feature sets “which have not been provided to the corresponding tenant”, and also provides a “quota” for the tenant for a particular application/feature set which may not exceed a sum of quotes of the tenant’s users for the particular application feature set; See also col. 25, lines 22-30, in which application-specific roles/capabilities/quotas may be managed on a per tenant basis).
The authentication limitation merely requires determining whether a resource of an access destination conforming to the request falls within a stored resource access range to correspond to one tenant scope indicated by the user management information of the selected name space". Such also does not require any particular type of resource access, nor does such define any particular access range, let alone a range that spans across tenants, as Applicant appears to intend.
Ahmed disclosed determining whether a resource of an access destination conforming to the received resource access request falls within a resource access range specified from the entire scope management information to correspond to one tenant scope indicated by the user management information of the selected tenant ID (Ahmed, col. 26, line 48 through col. 27, line 30, Ahmed disclosed authorization of the user and a determination at what level the user has access to, and provides an example as to which level of application falls within the range of the user’s access; As noted above, such involves utilization of tenant information/tenant ID to determine access)
Applicant additionally asserts, “Even further, Ahmed is different from the presently claimed invention in that Ahmed cannot ensure the independence of the user management between the tenants because it performs unified management of the users of all the tenants. The tenant IDs defined in Ahmed are IDs used to designate accessible tenants for users managed by the entire system. On the other hand, the name space(s) of the presently claimed invention is a management unit for independently managing tenant information including a user account with respect to each tenant and is different from the tenant ID because the user is included in management objects of the name space.”
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “ensure the independence of the user management between the tenants” and “the name space(s) of the presently claimed invention is a management unit for independently managing tenant information including a user account with respect to each tenant and is different from the tenant ID because the user is included in management objects of the name space”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
As claimed, the recited “name spaces” are merely utilized as identifiers of each tenant, utilized to determine proper access to resources, as claimed. Since Ahmed’s utilization of tenant ID is used for the same purpose as explained above, it would have been within the level of one of ordinary skill in the art that Ahmed’s tenant IDs reasonably amount to the claimed namespaces, as they are used for the same purpose.
Further, as noted in the rejection Buchmann disclosed the utilization of “namespaces” associated with tenants for the purpose of access control (Buchmann, [0101], [0113]), and therefore one of ordinary skill in the art would have been motivated to combine the teachings of Ahmed and Buchmann as they both relate to tenant namespace management, and as such they are within similar environments.
For these reasons, the rejections are respectfully maintained.
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 JERRY B DENNISON whose telephone number is (571)272-3910. The examiner can normally be reached M-F 8:30-5:50.
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, Hadi Armouche can be reached at 571-270-3618. 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.
/JERRY B DENNISON/Primary Examiner, Art Unit 2409