DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is response to communication: response to amendments/arguments filed on 07/31/2026
Claims 1-23 are currently pending in this application.
No new IDS has been filed for this application.
Response to Arguments
Applicant’s arguments have been fully considered but are not persuasive. As an initial matter, applicants noted that Moyle is omitted from the formal statement of rejection on page 5. Applicant’s assumption that Moyle refers to 2013/0097701 is correct, as it was applied in the parent case. This typographical error has been addressed and updated in the rejection below.
Applicant argues that the combination of references does not teach “identifying, with the one or more processors based on the scanning, the customer users having administrative privileges exceeding a privilege level corresponding to a role of the customer user.” This is not persuasive. As can be seen in paragraph 71 of Hanhirova, the passage describes a system where a user’s permission is updated. For example, an administrator may change a user’s role/permission based on multiple changes, such as moving to another project, joining another workgroup, or leaving to another organization. This is updated in a management framework 130. The system then periodically compares an integrated database 125 with the management framework 130, and updates database 125 with the changes from management framework 130. Take for example a user leaving the organization, as provided by Hanhirova in paragraph 71. This is updated in framework 130, but not yet updated in database 125. After the scan, the system realizes that the user’s permissions in 125 exceeds the user’s actual role (as the user is no longer holding that position). In this scenario, the claim limitation of “identifying … the customer users having administrative privileges exceeding a privilege level corresponding to a role of the customer user” is clearly taught. As Hanhirova, such as in paragraph 71, teaches situations “where a user is removed or added from an integratd workspace”, such limitations are taught, since users that are removed should have no access privileges, and after a poll on the current privileges, such users that are removed would have privileges exceeding to what the current roles should reflect. Thus, Hanhirova clearly teaches the claimed limitations.
Applicants also argue that Moyle does not teach “monitoring activities of the identified customer users based on a security policy. Applicants argue Moyle does not teach this as no policy is explicitly taught. This is not persuasive. As clearly seen in Moyle in paragraph 15, Moyle teaches monitoring activities of a user and determining that such behavior raises a violation. A violation requires some type of rule/policy being broken. Thus, as Moyle teaches monitoring activities and finding violations, Moyle clearly teaches the claimed limitations.
Applicants further argue that the art does not teach “applying updates to the identified customer users, comprising applying the restrictive RBACs to the identified customer uesrs based on the activities of the identified customers.” This is not persuasive. As seen in Hanhirova and described above, the system updates the database to include the roles/permissions of the users (see paragraph 71). The permissions of a user are directly linked to the information stored in such a database, and the updating of such a database updates the permissions of the users.
Applicants’ arguments are thus not found persuasive. See rejection below.
Double Patenting
6. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
7. Claims 1-20 of the instant application are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-23 of U.S. Patent No. 12,158,964 (app 17/497,386). Although the claims at issue are not identical, they are not patentably distinct from each. As per claim 1, as seen below for claim 1 of the instant application, all the limitations of the instant application are found in the parent patent. The dependent claims of the instant application (not shown), are also verbatim of the parent patent. Thus, see
Instant Application
Patent 12,158,964
1. A method of updating access permissions in a distributed computing system, comprising: periodically scanning, with one or more processors, management software for the distributed computing system, wherein the scanning includes periodically monitoring permissions of customer users with respect to a management software hierarchy; identifying, with the one or more processors based on the scanning, the customer users having administrative privileges exceeding a privilege level corresponding to a role of the customer user; and applying, with the one or more processors, restrictive role-based access controls (RBACs) for the identified customer users, wherein the applying restrictive RBACs comprises: monitoring activities of the identified customer based on a security policy; and applying updates to the identified customer users, comprising applying the restrictive RBACs to the identified customer users based on the activity by the identified customer users.
1. A method of preventing unauthorized activity in a distributed computing system, comprising: periodically scanning, with one or more processors, objects in management software for the distributed computing system, wherein the scanning includes periodically monitoring permissions of customer users with respect to particular objects in the management software object hierarchy; identifying, with the one or more processors based on the scanning, the customer users having administrative privileges exceeding a privilege level corresponding to a role of the customer user; and applying, with the one or more processors, restrictive role-based access controls (RBACs) for the identified customer users by restricting accesses by the identified customer users to the particular objects, wherein the applying restrictive RBACs comprises: executing an Unauthorized Activity Blocker (UAB); determining a mode of the UAB based on a security policy; monitoring activities of the identified customer by the UAB based on the determination; and applying UAB updates to the identified customer users, comprising applying the restrictive RBACs to the identified customer users in response to detection of an unauthorized activity by the identified customer users.
.
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-3, 9-14, and 20-23 are rejected under 35 U.S.C. 103 as being unpatentable over Guerra et al. US Patent No. 11,615,170 (Guerra), in view of Hanhirova US Patent Application Publication 2017/0346862 (Hanhirova), and further in view of Moyle et al. US Patent Application Publication 2013/0097701 (Moyle).
As per claim 1, Guerra teaches a method of preventing unauthorized activity in a distributed computing system, comprising: scanning, with one or more processors, management software for the distributed computing system (col. 3 lines 10-45 with monitoring whether access rights are correctly implemented; see col. 4 lines 15-36); identifying, with the one or more processors based on the scanning, the customer users having administrative privileges (col. 4 lines 15-36 with monitoring system monitoring whether correct data access rights are implemented based on user information; see col. 3 lines 55-65 wiherein user information may include employment position, department, work responsibilities, etc); and applying, with the one or more processors, restrictive role-based access controls RBACs for the identified customer users (col. 4 lines 30-36, col. 6 lines 3-30, and throughout with updating access controls based on user information).
Although Guerra teaches monitoring/scanning the system, Guerra does not explicitly teach periodically performing the scan. However, performing scans periodically is notoriously well known in the art. For example, see Hanhirova (paragraph 71 with regularly/periodically polling information and monitoring if adjustments to permissions needed to be changed based on role changes). Hanhirova further teaches wherein the scanning includes periodically monitoring permissions of customer users with respect to a management software hierarchy (paragraph 71 with regularly polling information, including role changes based on job changes, project changes, workgroup changes, or leaving the organization; see paragraph 29 wherein the roles of users in workspace are based on a hierarchy; see paragraph 54 with user roles in workgroups that have different levels of access). Further, identifying whether administrative privileges exceeding a privilege level corresponding to a role of the customer user would have been obvious. Hanhirova teaches in paragraph 71 that scanning for role/permission changes including monitoring situations wherein a user is removed from a workspace based on moving to another project, leaving the organization, etc. It is obvious, if not inherent, that if a user moves to another project, a user’s permissions for the previous workspace has exceeded his current role, and thus, the permissions for that object would be updated accordingly. Thus, Hanhirova further teaches wherein the applying restrictive RBACs comprises applying updates to the identified customer users, comprising applying the restrictive RBACs to the identified customer users. Paragraph 71 further teaches instances of when a user is removed from a workspace or leaves the organization. When a user is removed or leaves the organization, and the system has not updated yet, the user’s current permissions exceed a privilege level of what she has.
At the time the invention was filed, it would have been obvious to one of ordinary skill in the art to combine the teachings of Guerra with Hanhirova. One of ordinary skill in the art would have been motivated to perform such an addition to provide collaborative work space for users such that security of the shared workspace and shared data can be ensured (paragraph 29 of Hanhirova).
Although the Guerra combination teaches identifying privileges exceeding a privilege level corresponding to a role and applying updates to the identified customerr users, the combination does not explicitly teach applying the restrictive RBACs to the identified cusomter users in response to detection of an unauthorized activity by the identified customer users. However, applying changes in response to unauthorized activity is well known in the art. For example, see Moyle (paragraph 42, 44, 56, and throughout with countermeasures of changing access to users based on unauthorized activity). Moyle further teaches monitoring activities of the identified customers based on a security policy (paragraph 15 with monitoring activities of a user to determine whether activities qualify as use violations).
At the time the invention was filed, it would have been obvious to one of ordinary skill in the art to combine the teachings of the Guerra combination with Moyle. One of ordinary skill in the art would have been motivated to perform such an addition to create more security by assessing risks within a system (paragraph 3).
As per claim 2, Guerra as modified teaches wherein the periodic scanning is performed prior to an event of unauthorized activity, such that the applying restrictive RBACs is performed as a preventative measure (obvious over the Guerra combination; see Hanhirova paragraph 71 with monitoring regularly and updating roles/permissions accordingly).
As per claim 3, Guerra as modified teaches wherein the applying restrictive RBACs is performed as a penalizing measure (Moyle paragarphs 22, 44, 56, and throughout with countermeasures of changing access to users).
As per claim 9, the Guerra combination teaches wherein applying updates comprises invoking management application programming interfaces (obvious over Guerra; see col 3 line 49 to col. 4 line 10 wherein an auditor may review and update access rights and permission).
As per claim 10, the Guerra combination teaches wherein identifying customer users with administrative privileges comprises detecting an escalation of a customer’s privileges (Hanhirova paragraph 71 with detecting changes such as user added to an integrated intranet workspace because of changes in job/organization).
As per claim 11, it would have been obvious over the Guerra combination wherein identifying customer users with administrative privileges comprises detecting creation of the customer user with administrative privileges by another customer user (obvious over Hanhirova; see paragraph 71 with the period/regularly monitoring/scanning to detect changed role conditions, which includes an administrator adding a new user to an integrated workspace due to the job/role changes).
Claim 12 is rejected using the same basis of arguments used to reject claim 1 above.
Claim 13 is rejected using the same basis of arguments used to reject claim 2 above.
Claim 14 is rejected using the same basis of arguments used to reject claim 3 above.
Claim 20 is rejected using the same basis of arguments used to reject claim 9 above.
Claim 21 is rejected using the same basis of arguments used to reject claim 10 above.
Claim 22 is rejected using the same basis of arguments used to reject claim 11 above.
Claim(s) 4-8 and 15-19 are rejected under 35 U.S.C. 103 as being unpatentable over the Guerra combination as applied above, and further in view of Giblin et al. US Patent Application Publication 2014/0215604 (Giblin).
As per claim 4, it would have been obvious over the Guerra combination wherein applying the restrictive RBACs comprises: traversing the management software hierarchy; for each object in the hierarchy, classifying the identified customer users’ permissions into one or more buckets; for each object, evaluating the permissions in the buckets, and determining a a disposition (obvious over Hanhirova; see paragraph 71 with regularly checking permissions based on role changes and permissions; see paragraph 29 wherein roels of users can be defined according to hierarchies; see paragraph 71 wherein roles may be updated because of changes in organization/role). However, for a further teaching on classifying users’ permissions, evaluating the permissions, and determining a disposition, see Giblin (Figure 5 and 7 and paragraphs 69-73 with differing permissions based on hierarchy of roles and inherited roles; see Figure 7 throughout with checking permissions and removing selected permissions; also see paragraph 33).
At the time the invention was filed, it would have been obvious to one of ordinary skill in the art to combine the teachings of the Guerra combination with Giblin. One of ordinary skill in the art would have been motivated to perform such an addition to increase security (paragraph 55 of Giblin).
As per claim 5, it would have been obvious over the Guerra combination wherein the one or more buckets comprise at least one of a permissions bucket, a direct user level permissions bucket, an inherited user level permissions bucket, a direct group level permissions bucket, or an inherited group level permissions bucket (see Giblin Figure 7 with specified or abstract roles, or with permissions granted by superior roles, etc; see further paragraph 71-73 with inherited roles and permissions).
As per claim 6, it would have been obvious over the Guerra combination wherein evaluating permissions comprises generating an effective user permissions map for the object (see Giblin Figure 7 with updating permissions for roles; see also paragraphs 79-88 with adjusting roles accordingly to updated permissions; see also Guerra col. 9 lines 2-60).
As per claim 7, the Guerra combination teaches wherein evaluating permissions comprises comparing entries for the identified customer user across the one or more buckets (see Giblin with comparing permissions with roles and exceptions; see also paragraph 79 and 88 with analyzing a permission within the role and iteratively performing it with all permissions).
As per claim 8, the Guerra combination teaches wherein determining the disposition comprises determining whether permissions should be newly applied, retained, or modified based on the evaluating of the permissions (see Giblin Figure 7 and throughout with checking permissions and removing selected permissions).
Claim 15 is rejected using the same basis of arguments used to reject claim 4 above.
Claim 16 is rejected using the same basis of arguments used to reject claim 5 above.
Claim 17 is rejected using the same basis of arguments used to reject claim 6 above.
Claim 18 is rejected using the same basis of arguments used to reject claim 7 above.
Claim 19 is rejected using the same basis of arguments used to reject claim 8 above.
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 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 JASON KAI YIN GEE whose telephone number is (571)272-6431. The examiner can normally be reached on Monda-Friday 8:30-5:00 PST Pacific.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Farid Homayounmehr can be reached on (571) 272-3739. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of 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).
/JASON K GEE/Primary Examiner, Art Unit 2495
Prosecution Insights