DETAILED ACTION
This office action is in reply to applicant communication filed on February 02, 2026.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on February 02, 2026.
Claims 1-20 have been amended.
Claims 1-20 are pending.
Response to Argument
Applicant’s arguments filed on February 02, 2026 with respect to the 35 U.S.C. 102/103 rejections have been fully considered but are moot in view of new ground(s) of rejection.
Applicant’s arguments filed on February 02, 2026 with respect to the 35 U.S.C. 101 rejections have been fully considered and withdrawn in view of applicant argument and amendment.
Applicant’s argues that the prior arts on record fails to teach the amended limitation of independent claims. However, upon further consideration, a new ground(s) of rejection is made using the newly find prior arts to Goyal (US Pub. No. 2020/0364361).
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 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 of this title, 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.
.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-8 and 10-20 are rejected under 35 U.S.C. 103 as being unpatentable over Saxena (US Pub. No. 2019/0327271) in view of Goyal (US Pub. No. 2020/0364361) and further in view of Dhokia (US Pub. No. 2022/0247790).
As per claim 1 Saxena discloses:
A system, comprising: a processor configured to: receive configuration information associated with a production network environment, including at least one existing policy; (paragraph 52 of Saxena, 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) and (paragraph 53 of Saxena, an access control policy may include a set of one or more rules that apply to a system or subsystem. The access control policy may be viewed as reflecting an intent of the organization with regard to access to a system, a subsystem, or a portion thereof) and (paragraph 60 of Saxena, network access control policies may be present in network services and components, and may be managed using tools provided by such services and components).
In response to receiving a request for policy analysisUse the model to analyze the existing policy for the production network environment, including by identifying at least one existing policy intent problem; (paragraph 145 of Saxena, to determine (e.g. in response to a user query or request for policy verification) whether a specific object may be accessed by an actor under some specified set of policies, a model access control graph may be created where the attributes and/or connections associated with one or more nodes in the model access control graph may reflect the specified set of policies)).
Provide a result of the policy analysis as output; (paragraph 289 of Saxena, one or more access control policies corresponding to one or more first entities may be determined and output. The determination in block 1110 may be based on an input representing proposed changes to a stored normalized access control policy representation for an information technology (IT) infrastructure comprising a plurality of subsystems).
A memory coupled to the processor and configured to provide the processor with instructions. (Paragraph 7 of Saxena, a computing system may comprise: a memory, and a processor coupled to the memory, wherein the processor is configured to: obtain one or more normalized access control policies associated with one or more first entities based on a stored access control policy representation governing access to a set of resources in an information technology (IT) infrastructure comprising a plurality of subsystems).
Saxena teaches the method of building a model of security policy prior to deployment across exemplary security infrastructure (see paragraph 141 of Saxena) but fails to disclose:
Use the configuration information to build a predicate model, including by normalizing the at least one existing policy as a set of propositions.
However, in the same field of endeavor, Goyal teaches this limitation as, (paragraph 50 of Goyal, a set of documents having assigned security policies are referenced. At block 204, the set of documents are analyzed to identify content features associated with the documents. Content features can be, for instance, textual features and sensitivity features. Various types of technology can be implemented to identify or extract content features. At block 206, the content features and assigned security policies are used to generate a security policy prediction model. Thereafter, at block 208, content features associated with a document are identified. For instance, textual features and sensitivity features can be identified in association with the content of the document. At block 210, the content features associated with the document and the security policy prediction model are used to identify one or more policy labels relevant to the document. In some cases, the policy labels, or a portion thereof, can be provided to a user as policy label suggestions. A user can then select specific policy label suggestions to be included in a security policy for the document). Goyal defines content feature as, (paragraph 26 of Goyal, the content features identifier 110 is generally configured to identify content features associated with a document. Content features refer to any feature or attribute that indicates an aspect of content associated with a document. Such content features might be a word or phrase that describes, characterizes, or indicates an aspect of document content. Content features may include, for example, a document author, textual features, sensitivity features, or the like. A document author refers to an author or user that created or assisted in creating the document. A textual feature can be a textual description (e.g., word or keyword) used to represent or indicate a document or topic of the document. A sensitivity feature refers to a feature (e.g., text) that is indicative of personal or sensitive information in a document. Sensitivity features may include, without limitation, names of individuals and/or organizations, location, dates, currency or money references, phone numbers, addresses, social security numbers, email addresses, health or medical information, etc. The sensitive feature can refer to a category of sensitive information. For example, dimensions may be “name of organization,” “name of individual,” “social security number,” “credit card number,” etc. The dimensions may be incremented, for instance, each instance they appear in the document).
Therefore, 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 teaching of Saxena to include the above limitation using the teaching of Goyal in order to identifying a security policy(s) applicable to a particular document/configuration and provide a security policy suggestion to a user (see paragraph 15 of Goyal).
The combination of Saxena and Goyal teaches the method of building a model of security policy prior to deployment across exemplary security infrastructure (see paragraph 141 of Saxena) but fails to disclose:
Wherein the result includes an identification of the at least one existing policy intent problem and suggested recommendation for resolving the existing policy intent problem.
However, in the same field of endeavor, Dhokia teaches this limitation as, (paragraph 23 of Dhokia, the present disclosure thus solves the technical problem of security gaps in access control policies that may allow attackers access to computerized resources through the technical solution of performing an automated analysis of access control policies. In some examples, the technical solution also includes automatically suggesting and/or implementing these policies. In some examples, the automated analysis is performed on request from an administrator or other user through a GUI or an Application Programming Interface (API). In other examples, the automated analysis may be done periodically, after occurrence of an event (e.g., a modification, addition, deletion, or other operation performed on one of the access control policies), or the like) and (paragraph 16 of Dhokia, an administrator of the computing resource may be alerted to these vulnerabilities to allow the administrator to craft a policy, or modify an existing policy, to close these security gaps. In other examples, the system may automatically suggest and/or apply a modification to an existing policy or a new access control policy that closes the security gaps. The vulnerabilities may be determined based upon a comparison of the access control policy criteria in the previously set access control policies and a set of possible values of access control signals to determine access scenarios that are not covered by the access control policies).
Therefore, 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 teaching of Saxena and Goyal to include the above limitation using the teaching of Dhokia in order to enhance the security of the network by detecting and preventing potential access control gap (see paragraph 1 of Dhokia).
Claims 19 and 20 are rejected under the same reason set forth in rejection of claim 1.
As per claim 2 Saxena in view of Goyal and further in view of Dhokia discloses:
The system of claim 1, wherein the processor is configured to receive the request in response to a periodically schedule job. (Paragraph 99 of Saxena, 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. For example, changes in policies or attributes associated with entities and/or the addition of a new subsystem may trigger method 360 for policy and attribute determination).
As per claim 3 Saxena in view of Goyal and further in view of Dhokia discloses:
The system of claim 2, wherein the existing policy intent problem is an identified redundant policy and wherein the recommendation includes a recommendation to delete at list one policy. (Paragraph 111 of Saxena, if the entity is not new (“N” in block 373) then, in block 375, 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). In some embodiments, access logs and/other system information may be used to determine attributes and metadata for each access policy and edge, which may be used to populate tables 380 and/or 390 (e.g. in block 374 and/or 375)).
As per claim 4 Saxena in view of Goyal and further in view of Dhokia discloses:
The system of claim 1, wherein the recommendation includes a recommendation to merge two policies. (Paragraph 53 of Saxena, when policies are hierarchical, the policies may be applied down the hierarchy so that a top level policy (e.g. system wide) may be applied to lower level nodes (e.g. each subsystem). Higher level policies can be merged or fused into policies specified for lower nodes. However, in many systems, because of implementation errors, unforeseen consequences, or changes over time, access control policies, as implemented, at a given point in time, may not reflect stated access control polices (as desired)).
As per claim 5 Saxena in view of Goyal and further in view of Dhokia discloses:
The system of claim 1, wherein the recommendation includes a recommendation to change a rule priority. (Paragraph 61 of Saxena, security administrators typically focus on manual verification and management of a subset of access control policies related to a subset of objects and services (e.g. those prioritized as or deemed to be “critical”), which may leave access control policies related to a large number of objects and services unverified).
As per claim 6 Saxena in view of Goyal and further in view of Dhokia discloses:
The system of claim 1, wherein providing the result includes visually indicating a type of policy intent problem. (Paragraph 63 of Saxena, conventional access control systems lack automated techniques for: (a) tying a policy framework to access control policies as implemented; and/or (b) inferring or deriving a policy framework from expressed or implemented access control policies and/or (c) verifying that access control policies, as implemented, correspond to a policy framework (stated or derived). For example, access to a new network may be provided to developers and an access control policy may be added for a user who is a developer. In the example above, the changes to the access control rule (to add the developer) may be in conflict with a stated access control policy for the organization, but such conflicts may be is very difficult to determine in conventional systems thereby potentially compromising security).
As per claim 7 Saxena in view of Goyal and further in view of Dhokia discloses:
The system of claim 1, wherein providing the result includes identifying a missing enforcement component. (Paragraph 74 of Saxena, such access control changes that cause deviations from intended access control policies at a point in time are referred as access control policy drift or policy drift. In some embodiments, automatic policy determination may be used to automatically identify policy drift).
As per claim 8 Saxena in view of Goyal and further in view of Dhokia discloses:
The system of claim 1, wherein using the model to perform the policy analysis includes determining a hit count. (Paragraph 109 of Saxena, table 380 may include one or more of: (a) information pertaining to the current/first entity such as Entity ID 381; (b) one or more second entities accessible by the current/first entity such as shown in “Has Access To” field 382; (c) access paths 383 available to the first entity to access a second entity; (d) roles 384 associated with each access path to the second entity; (e) permissions associated with an access path to the second entity and/or role 385; (f) a time when the access policy to the second entity was first created 386; (g) a time that the access path or edge to the second entity was first exercised 387; (i) a time when the access path/edge to the second entity was last exercised 388; (h) a use count 389 indicating the number of times the access path/edge to the second entity was exercised).
As per claim 10 Saxena in view of Goyal and further in view of Dhokia discloses:
The system of claim 1, wherein the configuration information comprises live state information extracted from an executing firewall. (Paragraph 52 of Saxena, 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)
As per claim 11 Saxena in view of Goyal and further in view of Dhokia discloses:
The system of claim 1, wherein the configuration information is received in response to an on-demand request for policy analysis. (Paragraph 99 of Saxena, 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. For example, changes in policies or attributes associated with entities and/or the addition of a new subsystem may trigger method 360 for policy and attribute determination).
As per claim 12 Saxena in view of Goyal and further in view of Dhokia discloses:
The system of claim 1, wherein the configuration information is received periodically. (Paragraph 99 of Saxena, 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. For example, changes in policies or attributes associated with entities and/or the addition of a new subsystem may trigger method 360 for policy and attribute determination).
As per claim 13 Saxena in view of Goyal and further in view of Dhokia discloses:
The system of claim 1, wherein building the model includes using a solver. (Paragraph 257 of Saxena, Neural networks may be implemented on a computer (e.g. as in FIG. 7 described below) using a combination of hardware and software. For example, a computer may comprise one or more neural network processor(s), and/or distributed processors capable of being configured as a neural network, and/or software to model and/or simulate neural networks).
As per claim 14 Saxena in view of Goyal and further in view of Dhokia discloses:
The system of claim 1, wherein using the model to perform the analysis includes checking one or more invariants. (Paragraph146 of Saxena, if it is to be determined whether a specific user will have access to an AWS S3 bucket, then a model graph may be created based on the specified set of policies and the model graph may be traversed starting at the user (specified actor) to determine if at least one path exists to the S3 node and then to the specific S3 bucket (specified object)).
As per claim 15 Saxena in view of Goyal and further in view of Dhokia discloses:
The system of claim 1, wherein building the model includes performing a group- user mapping. (Paragraph 145 of Saxena, to determine (e.g. in response to a user query or request for policy verification) whether a specific object may be accessed by an actor under some specified set of policies, a model access control graph may be created where the attributes and/or connections associated with one or more nodes in the model access control graph may reflect the specified set of policies).
As per claim 16 Saxena in view of Goyal and further in view of Dhokia discloses:
The system of claim 1, wherein using the model to perform analysis includes determining a conflict between two rules included in the policy. (Paragraph 63 of Saxena, the changes to the access control rule (to add the developer) may be in conflict with a stated access control policy for the organization, but such conflicts may be is very difficult to determine in conventional systems thereby potentially compromising security).
As per clam 17 Saxena in view of Goyal and further in view of Dhokia discloses:
The system of claim 1, wherein the processor is configured to build the model in response to receiving a query. (Paragraph 145 of Saxena, in some embodiments, SV 330 may verify and/or ST 340 may facilitate querying in relation to some specified set of policies at a specific point in time by performing a modeling analysis of PR 350 (e.g. via an access control policy graph). For example, to determine (e.g. in response to a user query or request for policy verification) whether a specific object may be accessed by an actor under some specified set of policies, a model access control graph may be created where the attributes and/or connections associated with one or more nodes in the model access control graph may reflect the specified set of policies).
As per claim 18 Saxena in view of Goyal and further in view of Dhokia discloses:
The system of claim 1, wherein analyzing the existing policy includes performing differential analysis between two sets of configuration information. (Paragraph 163 of Saxena, entities may be clustered based on their access graph such that entities with similar access graph are in the same cluster. Differences in access privileges between entities in the same cluster may be indicative of access policy drift. For example, users may be clustered based on similar access privileges to a set of resources. Access privileges to a resource that are unique to an entity in the cluster may signal access policy drift),
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable Saxena (US Pub. No. 2019/0327271) in view of Goyal (US Pub. No. 2020/0364361) and further in view of Dhokia (US Pub. No. 2022/0247790) and Pernicha (US Pub. No. 20160191466).
As per claim 9:
The combination of Saxena, Goyal and Dhokia teaches the method of building a model of security policy prior to deployment across exemplary security infrastructure (see paragraph 141 of Saxena) but fails to disclose:
The system of claim 1, wherein using the model to perform the analysis includes optimizing the policy using contra-shadow analysis
However, in the same field of endeavor, Pernicha teaches this limitation as, (paragraph 64 of Pernicha, network security policy management system 200 can have a front end interface module (not shown) that can be used by user/administrator to create and/or upload one or more new security policy rules. Other modules of the present system can run in the background for validation and optimization of updated policy rules that would identify duplicate entries, merge-able entries, shadowed rules and other usual security rule based errors or non-optimized configurations).
Therefore, 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 teaching of Saxena, Goyal and Dhokiato include the above limitation using the teaching of Pernicha in order to generate an effective and efficient security policy (see paragraph 64 of Pernicha).
Conclusion
The prior art made or record and not relied upon is considered pertinent to applicant’s disclosure is Tautschnig (US 1,652,266). Tautschnig discloses:
This disclosure describes techniques for automating a system-level security review of a network-based service. The techniques may include generating and utilizing a machine-readable threat model to identify system-level security threats to the network-based service. The network-based service may be scanned upon being provisioned in a service-provider network, and the machine-readable threat model may be generated based on results of the scan. The machine-readable threat model may represent components of the network-based service, system-level security constraints configured to identify system-level security threats to the service, and mitigations to remedy violations to the system-level security constraints. The network-based service may be continuously, or periodically, scanned to identify changes in the network-based service. The techniques further include updating the machine-readable threat model to account for the detected changes to the network-based service, and analyzing the updated machine-readable threat model to determine whether the changes to the network-based service violate a system-level security constraint.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TESHOME HAILU whose telephone number is (571)270-3159. The examiner can normally be reached M-F 8 a.m. - 5 p.m..
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-1050. 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.
/TESHOME HAILU/Primary Examiner, Art Unit 2434