DETAILED ACTION
Introduction
Claims 1-20 are pending. Claim 1 is amended. Claims 8-14 and 16-20 are withdrawn. This Office action is further in response to Applicant’s request for reconsideration after non-final rejection filed on 2/2/2026.
Response to Arguments
Examiner discusses the arguments of Applicant’s representative below.
Rejection of claim 1 under 35 U.S.C. 102 as being anticipated by Singh/Gupta.
Applicant’s representative has amended claim 1 to recite that the intended goal of the steps of assigning each user of a tenant group to the same role and permissions is to cause all users in the tenant group to “have the same role and the same permissions,” and now argues that Singh does not teach this feature because Single allows users to belong to different sets of groups and therefore have different sets of permissions. Additionally, Applicant’s representative argues that Gupta does not teach this feature for similar reasons. However, Examiner no longer relies on Singh or Gupta to reject any of the claims. Therefore, this argument is moot.
Claim Rejections: 35 U.S.C. 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 2, and 15 are rejected under 35 U.S.C. 102(a)(1) because they are anticipated by the non-patent literature entitled “Kubernetes v1.16.”
Regarding claim 1, Kubernetes v1.16 teaches a method for organizing users within a network architecture, the method comprising: identifying a tenant group comprising a plurality of users (Kubernetes v1.16: Using RBAC Authorization teaches a group of users, which presupposes a step of identifying the group of users. See pg. 3, ln. 13-16); mapping the tenant group to a tenant (The group is bound to a container comprising a namespace. See pg. 3, ln. 13-18); and adding the tenant to a cluster, wherein the cluster comprises compute resources for executing workloads (The namespace is provided with resources of a Kubernetes cluster for performing workloads, such as through the creation of pods. See pg. 2, ln. 32-37; pg. 25, ln. 14-16); and wherein each of the plurality of users within the tenant group is assigned a same role within the tenant (The group may be assigned to exactly one of a plurality of roles, such as admin, editor, or viewer. See pg. 2, ln. 11-13; pg. 3, ln. 13-18. The roles are hierarchical such that the admin role is a superset of the editor role, and the editor role is a superset of the viewer role. See pg. 7, ln. 35-37); and wherein each of the plurality of users within the tenant group is assigned same permissions within the cluster such that all users in the tenant group, including the plurality of users, have the same role and the same permissions (The role contains a set of permissions granted to users having the role. Therefore, each user of the group is assigned the same set of permissions as each other user in the group by virtue of being assigned to exactly one of the hierarchical roles. See pg. 2, ln. 11-12.; pg. 13, ln. 44-50).
Regarding claim 2, Kubernetes v1.16 teaches teach the method of claim 1, wherein the tenant group is an internal tenant group such that each of the plurality of users is authenticated and managed by the cluster or another compute resource within the network architecture (Kubernetes v1.16: Authenticating teaches performing authentication using an internal authentication mechanism. See pg. 3-5).
Regarding claim 15, Kubernetes v1.16 teaches the method of claim 1, wherein the cluster is a component of a containerized workload management system, and wherein the cluster comprises: a control plane node communicating with a plurality of compute nodes; wherein the plurality of compute nodes comprises a physical machine or virtual machine configured to execute objects associated with the cluster (Kubernetes v1.16: Creating a Single Control-Plane Cluster teaches a cluster comprising a control-plane node that communicates with other nodes where workloads run on containers and pods. See pg. 5-6).
Claim Rejections: 35 U.S.C. 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 3-5 are rejected under 35 U.S.C. 103 because they are unpatentable over Kubernetes v1.16, as applied to claim 1 above, in further view of Yang (US 2021/0112065).
Regarding claim 3, Kubernetes v1.16 does not teach wherein the tenant group is an external tenant group such that each of the plurality of users is authenticated by an external identity provider. However, Yang teaches an authentication system whereby an external identity provider authenticates users of an external group managed by the external identity provider on behalf of the service provider. See par. 6.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Kubernetes v1.16 so that the group is an external user group, such that users of the external group are authenticated by the external identity provider, because doing so allows the system to offload authentication to an external identity provider.
Regarding claim 4, Kubernetes v1.16 and Yang teach the method of claim 3, wherein the external identity provider provides authentication services to the cluster (Yang teaches that an external identity provider provides authentication services to a service provider. See par. 6. Thus, Yang suggests further modifying the system of Kubernetes v1.16 and Yang so that an external identity provider provides authentication services to the cluster, because doing so is beneficial for the reasons provided above with respect to claim 3).
Regarding claim 5, Kubernetes v1.16 and Yang teach the method of claim 4, wherein the external identity provider is responsible for authenticating users within an identity provider user group and managing membership of the identity provider user group (Yang teaches that an external identity provider manages user group information and provides authentication services to a service provider. See par. 7-9. Thus, Yang suggests further modifying the system of Kubernetes v1.16 and Yang so that an external identity provider manages the external user group and provides authentication services to the cluster, because doing so is beneficial for the reasons provided above with respect to claim 3).
Claims 6-7 are rejected under 35 U.S.C. 103 because they are unpatentable over Kubernetes v1.16 and Yang, as applied to claim 5 above, in further view of Gopal (US 2017/0063986), the non-patent literature entitled “Synchronizing Group Membership” (hereinafter, “Cloudera”), or the non-patent literature entitled “Mirantis Kubernetes Engine” (hereinafter, “MKE”).1
Regarding claim 6, Kubernetes v1.16 and Yang do not teach the method of claim 5, wherein identifying the tenant group comprises retrieving a listing of tenant users, and wherein the listing of the tenant users is managed by the cluster. In addition, Kubernetes v1.16 and Yang do not teach wherein the method further comprises synchronizing the listing of the tenant users with the identity provider user group managed by the external identity provider. Nonetheless, Gopal teaches a tenant identity synchronization system whereby tenant identity data stored at a common identity repository is retrieved and synchronized with tenant identity data stored at a server farm. See. par. 15. Gopal further teaches that the tenant identity data relating to users associated with the tenant, such as user account names, authentication and privilege/permission information, etc. See par. 1, 28. Similarly, Cloudera teaches synchronizing group membership retrieved from and managed by an enterprise identity provider with group membership set up in a Cloudera platform. See pg. 1, section entitled “Synch Groups on Login enabled.” Lastly, MKE teaches retrieving a team list managed by a cluster and synchronizing the team list with an LDAP group managed by an external identity provider. See pg. 170-171.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Kubernetes v1.16 and Yang so that the group is retrieved and synchronized with a tenant group managed by the external identity provider, because doing so is beneficial for the reasons set forth in Gopal, Cloudera, and MKE.
Regarding claim 7, Kubernetes v1.16, Yang, and Gopal/Cloudera/MKE teach the method of claim 6, wherein synchronizing the listing of the tenant users within the identity provider user group comprises: cross-checking the listing of the tenant users against the identity provider user group to identify any discrepancies in usernames included in the listing of the tenant users versus usernames included in the identity provider user group (Gopal teaches that the synchronizing comprises updating the tenant identity data at the server farm to incorporate corresponding updates to the tenant identity data at the common identity repository, which presupposes a step of comparing updated tenant identity data obtained from the common identity repository against existing tenant identity data at the server farm to identify changes. See par. 15. Cloudera teaches comparing group membership obtained from the enterprise identity provider against group membership at the Cloudera platform. See pg. 1. MKE teaches that an LDAP group is checked against a team group. See pg. 170-171); in response to identifying a first username included in the listing of the tenant users that is not included in the identity provider user group, removing the first username from the listing of the tenant users (Gopal teaches that users or permissions that are removed at the common identity repository are removed from the server farm. See par. 15. Cloudera teaches that a user is removed from a group at the Cloudera platform if the user is not a member of the same group at the enterprise identity provider. See pg. 1. MKE teaches removing a user from the team group that is not present in the LDAP group. See pg. 170-171); and in response to identifying a second username included in the identity provider user group that is not included in the listing of the tenant users, adding the second username to the listing of the tenant users (Gopal teaches that users or permissions that are added at the common identity repository are added to the server farm. See par. 15. Cloudera teaches that a user is added to a group at the Cloudera platform if the user is a member of the same group at the enterprise identity provider. See pg. 1. MKE teaches adding a user to the team group if the user is present in the LDAP group but not in the team group. See pg. 170-171. Thus, Gopal, Cloudera, and MKE suggest further modifying the system of Kubernetes v1.16, Yang, and Gopal/Cloudera/MKE so that the system performs the synchronizing in the above-described manner because doing so is beneficial for the reasons provided above with respect to claim 6).
Alternatively, claims 3-5 are rejected under 35 U.S.C. 103 because they are unpatentable over Kubernetes v1.16, as applied to claim 1 above, in further view of Timmons (US 2021/0359998).
Regarding claim 3, Kubernetes v1.16 does not teach wherein the tenant group is an external tenant group such that each of the plurality of users is authenticated by an external identity provider. However, nonetheless, Timmons teaches a system whereby an external identity provider authenticates each user in an external group of users before the users are granted access to a service provided by an organization. See par. 4, 56.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Kubernetes v1.16 so that the group is an external group that is authenticated by an external identity provider, because doing so allows the system to offload authentication to an external identity provider.
Regarding claim 4, Kubernetes v1.16 and Timmons teach the method of claim 3, wherein the external identity provider provides authentication services to the cluster (Timmons teaches that an external identity provider provides authentication services to a service provider. See par. 4, 56. Thus, Timmons suggests further modifying the system of Kubernetes v1.16 and Timmons so that an external identity provider provides authenticated access to the Hadoop cluster, because doing so is beneficial for the reasons provided above with respect to claim 3).
Regarding claim 5, Kubernetes v1.16 and Timmons teach the method of claim 4, wherein the external identity provider is responsible for authenticating users within an identity provider user group and managing membership of the identity provider user group (Timmons teaches an external identity provider that authenticates users within an external user group. See par. 4, 56. Timmons further teaches that the external identity provider also manages membership in the external user group. See par. 17, 38. Thus, Timmons suggests further modifying the system of Kubernetes v1.16 and Timmons so that the external identity provider authenticates and manages the external group because doing so is beneficial for the reasons provided above with respect to claim 3).
Alternatively, claims 6-7 are rejected under 35 U.S.C. 103 because they are unpatentable over Kubernetes v1.16 and Timmons, as applied to claim 5 above, in further view of either Gopal or Cloudera.
Regarding claim 6, Kubernetes v1.16 and Timmons do not teach the method of claim 5, wherein identifying the tenant group comprises retrieving a listing of tenant users, and wherein the listing of the tenant users is managed by the cluster. In addition, Kubernetes v1.16 and Timmons do not teach wherein the method further comprises synchronizing the listing of the tenant users with the identity provider user group managed by the external identity provider. Nonetheless, Gopal teaches a tenant identity synchronization system whereby tenant identity data stored at a common identity repository is retrieved and synchronized with tenant identity data stored at a server farm. See. par. 15. Gopal further teaches that the tenant identity data relating to users associated with the tenant, such as user account names, authentication and privilege/permission information, etc. See par. 1, 28. Similarly, Cloudera teaches synchronizing group membership retrieved from and managed by an enterprise identity provider with group membership set up in a Cloudera platform. See pg. 1, section entitled “Synch Groups on Login enabled.” Lastly, MKE teaches retrieving a team list managed by a cluster and synchronizing the team list with an LDAP group managed by an external identity provider. See pg. 170-171.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Kubernetes v1.16 and Timmons so that the group is retrieved and synchronized with a tenant group managed by the external identity provider, because doing so is beneficial for the reasons set forth in Gopal, Cloudera, and MKE.
Regarding claim 7, Kubernetes v1.16, Timmons, and Gopal/Cloudera/MKE teach the method of claim 6, wherein synchronizing the listing of the tenant users within the identity provider user group comprises: cross-checking the listing of the tenant users against the identity provider user group to identify any discrepancies in usernames included in the listing of the tenant users versus usernames included in the identity provider user group (Gopal teaches that the synchronizing comprises updating the tenant identity data at the server farm to incorporate corresponding updates to the tenant identity data at the common identity repository, which presupposes a step of comparing updated tenant identity data obtained from the common identity repository against existing tenant identity data at the server farm to identify changes. See par. 15. Cloudera teaches comparing group membership obtained from the enterprise identity provider against group membership at the Cloudera platform. See pg. 1. MKE teaches that an LDAP group is checked against a team group. See pg. 170-171); in response to identifying a first username included in the listing of the tenant users that is not included in the identity provider user group, removing the first username from the listing of the tenant users (Gopal teaches that users or permissions that are removed at the common identity repository are removed from the server farm. See par. 15. Cloudera teaches that a user is removed from a group at the Cloudera platform if the user is not a member of the same group at the enterprise identity provider. See pg. 1. MKE teaches removing a user from the team group that is not present in the LDAP group. See pg. 170-171); and in response to identifying a second username included in the identity provider user group that is not included in the listing of the tenant users, adding the second username to the listing of the tenant users (Gopal teaches that users or permissions that are added at the common identity repository are added to the server farm. See par. 15. Cloudera teaches that a user is added to a group at the Cloudera platform if the user is a member of the same group at the enterprise identity provider. See pg. 1. MKE teaches adding a user to the team group if the user is present in the LDAP group but not in the team group. See pg. 170-171. Thus, Gopal, Cloudera, and MKE suggest further modifying the system of Kubernetes v1.16, Timmons, and Gopal/Cloudera/MKE so that the system performs the synchronizing in the above-described manner because doing so is beneficial for the reasons provided above with respect to claim 6).
Conclusion
Applicant’s amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Andrew Georgandellis whose telephone number is 571-270-3991. The examiner can normally be reached on Monday through Friday, 7:30-5:00 PM EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Tonia Dollinger, can be reached on 571-272-4170. 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 the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ANDREW C GEORGANDELLIS/Primary Examiner, Art Unit 2459
1 The Cloudera reference was found in the file history of Application 17/667,292.