Detailed Action
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 1/26/2026 has been entered.
-Claims 1, 18 and 19 have been amended.
-Claim 6 is cancelled.
-Objections to the drawings are withdrawn based on the replacement figures filed on 1/26/2026.
-Rejections under 35 US 101 are withdrawn based on claim amendments.
- Claims 1-5 and 7-19 are pending.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s Remarks filed on 1/26/2026 have been fully considered.
With respect to the 101 rejections, the arguments are persuasive in view of the claim amendments, as such these rejections are withdrawn.
Arguments regarding the amended features are moot in view of newly cited paragraphs of Saxena.
Note that recitations including “usable to….” are interpreted as intended use.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 13 is rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends. Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
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-5 and 7-19 are rejected under 35 U.S.C. 103 as being unpatentable over Saxena et al (US Pub.No. 2019/0327271) in view of Tuggle (US Pub.No. 2019/0147068).
Re Claim 1. Saxena discloses a system, comprising: a processor configured to: receive configuration information [associated with a production network environment], including at least one policy; use the received configuration information to build a model, including by normalizing the policy (i.e. provide the information to PE 360 and/or SPD 312, which may process the information to determine access policies and provide the information to SPN 314 and/or access policy representation block (APR) 316 to normalize and/or update access policy graphs. In some embodiments, various access policy graphs (e.g. associated with individual actors/objects) may be combined to create a master access policy graph where each actor and/or object in the IT infrastructure is uniquely represented as a single node. The master access policy graph represents a collective logical representation of all policy objects expressed across all objects……..AOPC 310 may further include security policy normalization block (SPN) 314, which may receive access control policy information for entities (e.g. actors and/or objects) associated with one or more subsystems from SPD 312, interpret each policy associated with the respective entities, and represent the policies in a normal or standardized form. In some embodiments, the normal or standardized from may be a generalized representation independent of any particular entity (e.g. the normalized representation may be entity/system/sub-system agnostic). For example, SPN 314 may represent security and/or access control policies in a form that is not specific to any particular subsystem or entity and in a manner that facilitates access control description across the various subsystems of an IT infrastructure in a consistent standardized format) [Saxena, para.0103-0104, see also para.0114]; use the model to perform a policy analysis, including by identifying at least one existing policy conflict (i.e. in policy management block 570, provisioned policies or implemented policies that are non-compliant or inconsistent with one or more derived or stated access control policies may be identified, flagged as exceptions, and an administrator may be alerted) [Saxena, para.0216, see also 0133], (i.e. determining actors and/or object that have associated privileges that are inconsistent with one or more access control policies) [Saxena, para.0070], (i.e. notifications (e.g. real time) when one or more access control rules are inconsistent with an access control policy) [Saxena, para.0141], (i.e. Graphs with a similarity score above some threshold may be evaluated and deviations between the graphs may be attributed to access policy drift) [Saxena, 0162] and also including by performing a pre-change analysis associated with a proposed policy change [for the production network environment]; and provide a result of the policy analysis as output (i.e. an IT infrastructure (e.g. system 100) may be monitored (e.g. by SPD 312) when deployed and/or to determine if there are changes to the system (additions, deletions and/or changes related to the security policies/access control policies) so that access policy graphs and/or clusters affected by the changes to the IT infrastructure may be reflected in PR 350. In some embodiments, monitoring of an IT infrastructure for changes (e.g. by SPD 312) may occur continuously, on some predetermined schedule (e.g. set by a system administrator), or periodically. In some embodiments, agents coupled to PE 360 and/or SPD 312 may monitor actors and/or objects in the IT infrastructure to detect changes affecting security policies and/or access control policies and may trigger functionality associated with AOC 310 (e.g. SPN 314 and/or SPR 316) and/or AOA 320 (described below) to update access policy graphs and/or clusters affected by the changes and create, update and/or augment PR 350) [Saxena, para.0120], (i.e. verification that any access control rules (implemented or to be implemented) are consistent with the set of access control policies (derived and/or stated); (g) notifications (e.g. real time) when one or more access control rules are inconsistent with an access control policy) [Saxena, para.0067, Note: analysis of rules “to be implemented” teaches pre-change analysis], wherein the result is usable to identify whether implementing the proposed policy change would result in a resolution of the existing policy conflict (i.e. the impact of any proposed rule changes (e.g. on system entities) may also be presented to the user. In some embodiments, SV 330 and/or ST 340 and/or PE 360 may include functionality to automatically remediate the policy violation by modifying the access control policy such that it is consistent with specified rules) [Saxena, para.0157, see also 0162]; and a memory coupled to the processor and configured to provide the processor with instructions [Saxena, para.268, Fig.7].
Although the above citations of Saxena are not all disclosed in the same embodiment, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to combine the different embodiments, because when describing Fig.7, Saxena suggests such a combination: computer- readable medium 720 and/or removable media 708 may include program code stored thereon may include program code to support methods for access control policy determination, management, provisioning, verification, and testing according to some disclosed embodiments. For example, computer-readable medium 720 and/or removable media 708 may include program code to support techniques disclosed in relation to FIGS. 3-6 [Saxena, para.0274]. In addition, Figs.8-12 are flowcharts described as corresponding to steps in Fig. 3A and Fig.5A [Saxena, para.0276, 0282, 0285, 0288 and 0291]. This motivation applies to the dependent claims.
Saxena does not explicitly disclose whereas Tuggle does: configuration associated with a production network environment and policy change for the production network environment (i.e. utilizes the customizations to determine a plurality of different potential solutions for implementing new functionality or achieving an objective without conflicting with the existing customizations. For example, for an administrator user associated with a particular tenant, the automated development engine 126 may utilize the tenant identifier to identify or obtain information pertaining to any existing custom objects, custom validation rules, custom workflow rules, custom metadata or schema, custom code packages, and/or custom point-and-click configurations …….the testing database is realized as a replication of the up-to-date or real-time data maintained in the production database with at least some customizations associated with the particular user or tenant being modified with respect to the customizations in the production database. In one or more exemplary embodiments described herein, the automated development engine 126 obtains the current customizations from each of the different databases 104 within the database system 100 to determine potential solutions that do not conflict with existing customizations implemented at the production database) [Tuggle, para.0024-0025].
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Saxena with Tuggle because by virtue of the selected solution accounting for existing validation rules, workflows, and other applicable customizations, the modifications for achieving the desired functionality or objective are unlikely to result in errors or conflicts when deploying the modifications in the production database [Tuggle, para.0013].
Re Claim 2. Saxena in view of Tuggle discloses the system of claim 1, wherein the processor is further configured to provide a suggested recommendation associated with the result of the policy analysis (i.e. any exceptions to derived access control policies and/or stated access control policies may be flagged and/or presented to an administrator as an exception and/or for approval) [Saxena, para.0216], (i.e. a proposed access control policy change may be made in a simulation mode in SCT block 346 to determine if any of the invariant checks or best practices checks are violated. The impact of any access control policy changes may also be assessed in terms of whether there is a net increase or decrease in access to one or more entities. One or more of the above factors (consistency with invariant policies and/or best practices or change in access) may be used allow or disallow the proposed changes) [Saxena, para.0141].
Re Claim 3. Saxena in view of Tuggle discloses the system of claim 2, wherein the proposed policy change includes a proposal to add a new rule (i.e. changes to access policies associated with the entity being processed may be determined and edges may be created (to reflect new inbound/outbound policies), deleted (to reflect access revocations), or modified (e.g. to reflect access policy changes)) [Saxena, para.0111], and wherein the suggested recommendation is against adding the new rule (i.e. upon a determination that a desired policy is being violated, one or more specific rules that contribute to the violation may be identified and the information may be provided to a user. For example, as a result of an access policy graph traversal, an access path that is non-compliant with some specified policy may be identified, and rule(s) and/or object attributes that contribute to the violation may be flagged and reported. In some embodiments, the user may be provided with information pertaining to rule changes that may stop the non-compliant behavior…………………….one or more paths in the cluster may be tested and/or validated to determine compliance with policies (e.g. as reflected in PR 350) prior to be added to the path cluster. Paths that violate one or more policies may be flagged, not added to the cluster) [Saxena, para.0227, 0236].
Re Claim 4. Saxena in view of Tuggle discloses the system of claim 2, wherein the proposed policy change includes a proposal to delete an existing rule (i.e. changes to access policies associated with the entity being processed may be determined and edges may be created (to reflect new inbound/outbound policies), deleted (to reflect access revocations), or modified (e.g. to reflect access policy changes)) [Saxena, para.0111], and wherein the suggested recommendation is against deleting the existing rule (i.e. In some embodiments, an administrator may be alerted when access is disabled and provided an opportunity to confirm or override the new policy) [Saxena, para.0190, Note: alerting an admin to override a rule that disables an existing rule that allows access teaches a suggestion against disabling access i.e. against deleting the existing rule that allows access].
Re Claim 5. Saxena in view of Tuggle discloses the system of claim 1, wherein the result includes an indication of a conflict that would be introduced as a result of making the proposed policy change (i.e. the above factors (consistency with invariant policies and/or best practices or change in access) may be used allow or disallow the proposed changes ………………notifications (e.g. real time) when one or more access control rules are inconsistent with an access control policy) [Saxena, para.0141, 0067].
Re Claim 7. Saxena in view of Tuggle discloses the system of claim 1, wherein the configuration information includes live state information extracted from an executing firewall (i.e. agents may also determine and/or select actors, objects, and connections during program run time based on the evaluation of the conditions. For example, agents may monitor actor and/or object instantiations, access requests to objects by actors, network traffic etc., and provide the information to PE 360 and/or SPD 312, which may process the information to determine access policies and provide the information to SPN) [Saxena, para.0103, Note: an agent that monitors network traffic is interpreted as firewall].
Re Claim 8. Saxena in view of Tuggle discloses the system of claim 1, wherein at least some of the configuration information is received in response to an on-demand request for policy analysis (i.e. method 360 may be invoked periodically (e.g. at some specified or predetermined interval), on demand (e.g. by an administrator or another program), or whenever a new subsystem is added or policies and/or attributes are changed) [Saxena, para.0099].
Re Claim 9. Saxena in view of Tuggle discloses the system of claim 1, wherein at least some of the configuration information is received periodically (i.e. automatic policy determination may be used as part of an access control verification process to verify that an implemented rule base reflects stated policies for a system/subsystem or to determine any inconsistencies. For example, derived polices, which may include learned/inferred rules may be compared with a stated access control policy (or rule) to determine potential inconsistencies. In some embodiments, access control verification may be run periodically, and/or whenever access control policies are changed) [Saxena, para.0072].
Re Claim 10. Saxena in view of Tuggle discloses the system of claim 1, wherein at least some of the configuration information comprises metadata (i.e. Rules may specify: (a) conditions under which an actor may access an object; and (b) the type of access permitted to the object for each actor/actor type. The rules may be based on attributes associated with the actor (e.g. actor location/geography, actor IP address, actor type, actor groups, historical behavior, profiles including actor risk profiles, type of access requested, etc.), environmental considerations (time, current threat level, predicted risk, etc.), object attributes (e.g. object location, object type, geography, etc.), and/or metrics determined from some combination of the above (e.g. a predicted risk etc.) and/or tags assigned to and/or metadata associated with objects and/or actors. In some embodiments, the rules may be specified using one or more logical (e.g. Boolean) operators and two or more rules may be combined to obtain to more complex rules. As one example, access may be allowed to a database (object) for an application (actor) only when connecting from a corporate office (actor location) in Europe (actor geography) and the user group associated with the actor (actor group) is developer and the access type is “read only.”) [Saxena, para.0052].
Re Claim 11. Saxena in view of Tuggle discloses the system of claim 10, wherein the metadata comprises at least one of: (1) an address object (i.e. Actor geography may be determined, for example, from IP addresses or location of the user attributed in the HR database or other metadata associated with the object access request) [Saxena, para.0052], (2) a filter, (3) a service group, (4) DNS resolution information, or (5) an application object.
Re Claim 12. Saxena in view of Tuggle discloses the system of claim 1, wherein building the model includes using a solver (i.e. the rules may be specified using one or more logical (e.g. Boolean) operators and two or more rules may be combined to obtain to more complex rules) [Saxena, para.0052], (i.e. specify access control rules in PR 350 (e.g. associated with entities in the IT infrastructure) using logical expressions. The logical expressions above may reflect access control policies associated with one or more physical entities (actors and/or objects) in an IT infrastructure (e.g. system 100/100). A stated policy, which may include rules for one or more entities, may also be specified in PR 350 using logical expressions. In some embodiments, expressions based on first order logic may be used to represent access control policies in PR 350 for implemented policies, stated policies and derived policies) [Saxena, para.0113, also para.0150-0151, Note: based on at least para.0161 of the current specification, a solver has been interpreted as a set of logical expressions].
Re Claim 13. Saxena in view of Tuggle discloses the system of claim 1, wherein using the model to perform analysis includes determining a conflict between two rules included in the policy (i.e. in policy management block 570, provisioned policies or implemented policies that are non-compliant or inconsistent with one or more derived or stated access control policies may be identified, flagged as exceptions, and an administrator may be alerted) [Saxena, para.0216].
Re Claim 14. Saxena in view of Tuggle discloses the system of claim 1, wherein using the model to perform the analysis includes optimizing the policy using contra-shadow analysis (i.e. facilitate determination of a change audit trail that captures all access changes that may have occurred across all entities over a specified time period. Accordingly, entities affected by access policy changes may be determined and unintended effects may be remedied. For example, access to an object O1 may be granted to an entity E4, if an access policy change (inadvertently) affected entity E4's access to object O1 or the access policy change may be modified to remove unintended consequences) [Saxena, para.0156, Note: analyzing entities affected by policy changes to remediate unintended consequences/effects teaches contra-shadow].
Re Claim 15. Saxena in view of Tuggle discloses the system of claim 1, wherein using the model to perform the analysis includes determining an intent conflict (i.e. due to the effect of cumulative policy changes over time, policies (stated or derived) may drift relative to their intent. In some embodiments, by determining the difference between the sets of entities with access to similar objects (e.g. objects within an object cluster), policy drift for stated and/or derived policies may be identified and flagged) [Saxena, para.0196].
Re Claim 16. Saxena in view of Tuggle discloses the system of claim 1, wherein using the model to perform the analysis includes checking one or more invariants (i.e. to determine if any of the invariant checks or best practices checks are violated. The impact of any access control policy changes may also be assessed in terms of whether there is a net increase or decrease in access to one or more entities. One or more of the above factors (consistency with invariant policies and/or best practices or change in access) may be used allow or disallow the proposed changes) [Saxena, para.0141].
Re Claim 17. Saxena in view of Tuggle discloses the system of claim 1, wherein building the model includes performing a group-user mapping (i.e. governed by a respective set of access control policies. Further, users 102-1, 102-2, 102-3 . . . 102-s (collectively referred to as users 102) may also be associated with respective groups each with associated access permissions, and services 202-1, 202-2, 202-3 etc. (collectively referred to as services 202) may also be associated with respective access permissions) [Saxena, para.0086].
Re Claims 18 and 19. These claims recite features similar to those in claim 1, therefore they are rejected in a similar manner.
Conclusion
All claims are identical to or patentably indistinct from, or have unity of invention with claims in the application prior to the entry of the submission under 37 CFR 1.114 and all claims could have been finally rejected on the grounds and art of record in the next Office action if they had been entered in the application prior to entry under 37 CFR 1.114. Accordingly, THIS ACTION IS MADE FINAL even though it is a first action after the filing of a request for continued examination and the submission under 37 CFR 1.114. See MPEP § 706.07(b). 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 NOURA ZOUBAIR whose telephone number is (571)270-7285. The examiner can normally be reached Monday - Friday.
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, ALI SHAYANFAR can be reached at 571-270-2050. 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.
/NOURA ZOUBAIR/Primary Examiner, Art Unit 2434