DETAILED ACTION
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 24, 2026, has been entered.
Claims 1, 8, and 15 are amended.
Claims 1-5, 8-12, and 15-18 are pending.
Response to Remarks/Amendments
35 USC §101 Rejections
The Applicant traverses the rejection of the claims as being directed to an ineligible abstract idea; contending that the present claims recite a solution to a problem that is rooted in computer technology. See Remarks pp. 10-11. The Examiner respectfully disagrees. At best, the present claims merely contain the idea of a solution – unifying entirely different security models. This idea is embodied in the claim language – “identifying enterprise-wide Segregation of Duties (SoD) risks across disparate enterprise-class systems . . . “ See exemplary independent claim 1. Merely defining security permissions across multiple systems does not provide a solution that is rooted in computer technology. The Examiner notes that there is significant ambiguity in what constitutes a “system” or “different business application.”
The rejection for lack of subject matter eligibility is maintained.
35 USC §103 Rejections
Amendments to the claims changed the scope of the claims, necessitating further search and consideration of the prior art. A new search returned the Grack reference, which is cited in the prior art rejection of independent claims 1, 8, and 15, below. The Applicant’s arguments with respect to Saxena and Raphael are moot in light of the newly cited reference.
The rejection of the dependent claims stands or falls with the rejection of the independent claims.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
The Manual of Patent Examining Procedure (MPEP) provides detailed rules for determining subject matter eligibility for claims in §2106. Those rules provide a basis for the analysis and finding of ineligibility that follows.
Claims 1-5, 8-12, and 15-18 are rejected under 35 U.S.C. 101. The claimed invention is directed to non-statutory subject matter because the claimed invention recites a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Although claims(s) 1-5, 8-12, and 15-18 are all directed to one of the four statutory categories of invention, the claims are directed to determining user permissions (as evidenced by exemplary independent claim 1; “determining . . . hits that satisfy the set of permissions and the logical operator”), an abstract idea. Certain methods of organizing human activity are ineligible abstract ideas, including managing personal behavior or relationships or interactions between people. See MPEP §2106.04(a). The limitations of exemplary claim 1 include: “generating . . . a security extract metadata file . . . describing security principals and associated permissions;” “storing the security extract metadata file;” “storing first stub data;” “generating . . . a permissions metadata file . . . describing the [ ] rule and [a] plurality of business functions;” “storing the permissions metadata file;” “storing . . . second stub data;” “analyzing . . . the plurality of business functions;” “determining . . . hits that satisfy the set of permissions and [a] logical operator;” “storing . . . the hits in a database;” and “query[ing] the database for permissions.” The steps are all steps for managing personal behavior related to the abstract idea of determining user permissions that, when considered alone and in combination, are part of the abstract idea of determining user permissions. The dependent claims further recite steps for managing personal behavior that are part of the abstract idea of determining user permissions. These claim elements, when considered alone and in combination, are considered to be abstract ideas because they are directed to a method of organizing human activity which includes defining security principals and permissions for users and user groups based on their roles.
Under step 2A of the subject matter eligibility analysis, a claim that recites a judicial exception must be evaluated to determine whether the claim provides a practical application of the judicial exception. Additional elements of the independent claims amount to generic computer hardware that does not provide a practical application (an analytics engine in independent claim 1; a processor and computer readable medium in independent claim 8; and a computer-readable medium in independent claim 15). See MPEP §2106.04(d)[I]. The claims do not recite an improvement to another technology or technical field, nor do they recite an improvement to the functioning of the computer itself. See MPEP §2106.05(a). The newly recited language recites a format standardization step, but that step is a well-known step that is tangential to the inventive concept of determining user permissions. Moreover, the step is necessary for disparate systems operating on different programming languages or formats to communicate. Therefore, the step amounts to insignificant extra-solution activity that does not provide a practical application of the abstract idea. See MPEP §2106.05(g). The claims require no more than a generic computer (an analytics engine in independent claim 1; a processor and computer readable medium in independent claim 8; and a computer-readable medium in independent claim 15) to implement the abstract idea, which does not amount to significantly more than an abstract idea. See MPEP §2106.05(f). Because the claims only recite use of a generic computer, they do not apply the judicial exception with a particular machine. See MPEP §2106.05(b). For these reasons, the claims do not provide a practical application of the abstract idea, nor do they amount to significantly more than an abstract idea under step 2B of the subject matter eligibility analysis. Using a generic computer to implement an abstract idea does not provide an inventive concept. Therefore, the claims recite ineligible subject matter under 35 USC §101.
Furthermore: an element that is found to amount to insignificant extra-solution activity in step 2A of the subject matter eligibility analysis must be evaluated in step 2B to determine whether the step amounts to more than what is well-understood, routine, and conventional. Converting formats into a standard format is well-understood, routine, and conventional, as evidenced by at least ¶[0091] and [0104] of US 20190327271 A1 to Saxena et al. That passage discussed the use of standardized formats for storing access control policies. The present claims are directed to an abstract idea without significantly more. Therefore, the claims are not subject matter eligible under 35 USC §101.
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.
Claim(s) 1-5, 8-12, and 15-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20190327271 A1 to Saxena et al. (hereinafter ‘SAXENA’) in view of US 20210173952 A1 to Raphael et al. (hereinafter ‘RAPHAEL’) and US 9104884 B2 to Grack (hereinafter ‘GRACK’).
Claim 1 (Currently Amended)
SAXENA discloses a method, for identifying enterprise-wide Segregation of Duties (SoD) risks (see ¶[0137]; a best practices testing block that measures how closely policies track best practices in security. Separation of duty guidelines. See also ¶[0021]-[0022]; the prediction may be used to identify risk) across disparate enterprise-class systems (see ¶[0005]; an IT infrastructure with disparate subsystems) in an enterprise computing environment (see ¶[0064]; audit and compliance teams in enterprises), the method comprising: generating, by an analytics engine embodied on a computer operating in the enterprise computing environment (see ¶[0064], [0075]-[0077], [0093], and [0255]; audit and compliance teams in enterprises. Private clouds hosted at the enterprise), a security extract metadata file from a system-specific security extract (see ¶[0002]-[0003], [0052], [0069] and [0174]; cyber security access rules with metadata associated with an object access request. Conditions associated with queries may involve attributes associated with any entity and/or objects. A cluster may be determined based on metadata), the analytics engine having a system-specific component and an enterprise-wide component (see ¶[0077]; a private cloud within an enterprise’s data center and/or a hybrid cloud), wherein the system-specific component comprises an extract processor (see ¶[0006]; a processor-implemented method) operable to transform the system-specific security extract into a system-agnostic standardized format (see ¶[0091] and [0104]; store the access control policies in a standardized format such as policy representation [PR]) and generate the security extract metadata file (see ¶[0052], [0069], and [0174]; metrics are determined from metadata associated with objects and/or actors. Determine actor geography from metadata associated with the object access request. Query a system to determine entities that have access to an object. Conditions associated with queries may involve metadata associated with objects), and wherein the enterprise-wide component comprises a rulebook compiler operable to compile a rulebook per a system type (see ¶[0003] & [0052]-[0053] and Figs. 4H-I; ensure what resources – e.g., computers data repositories, network resources are accessed by authorized entities. Rules may specify object attributes, including object location, object type, and geography. An access control policy may include a set of one or more rules that apply to a system or subsystem), the system-specific security extract specific to one of a plurality of enterprise-class systems in the enterprise computing environment (see ¶[0064]; certify access to various actors and class classed of actors in an enterprise), the security extract metadata file containing metadata describing security principals and associated permissions (see ¶[0086]-[0087], [0105] and [0204]; users may be associated with groups that are associated with access permissions and services. Conditions may be specified using access policy parameters. A connection of edge may represent permissions or privileges. Edges may include metadata or labels); and
storing the security extract metadata file in a cloud storage (see ¶[0052] and [0105]; determine actor geography based on metadata in a [human resources] database. Information pertaining to the access policy graph may be stored in a graph database).
SAXENA does not specifically disclose, but RAPHAEL discloses, storing first stub data corresponding to the metadata describing the security principals and the associated permissions in a database (see abstract and ¶[0059] and Fig. 3; catalog lists virtual information assets. Catalog contains metadata storing information asset instances. A virtual information asset is a stub structure that contains metadata. The access management server 302 contains catalog, enforcement knowledge graph, and policy database containing rules and policies).
SAXENA further discloses, wherein the database is accessible by the analytics engine (see ¶[0003] and [0058]-[0059]; a cloud infrastructure. Network databases and cloud services).
SAXENA does not specifically disclose, but RAPHAEL discloses, and wherein the first stub data is configured for establishing links between the security principals and permissions across the plurality of enterprise-class systems (see abstract and ¶[0059] and Fig. 3; catalog lists virtual information assets. Catalog contains metadata storing information asset instances. A virtual information asset is a stub structure that contains metadata. The access management server 302 contains catalog, enforcement knowledge graph, and policy database containing rules and policies. See also ¶[0001]-[0002] and [0024]; the disclosure relates to data security. Server provides data corresponding to an enterprise).
SAXENA further discloses generating, by the analytics engine, a permissions metadata file from a system-type-specific rulebook (see ¶[0052]-[0054]; rules based on attributes. An access control policy may include a set of one or more rules. The set of access control rules for a subsystem may reflect an access control policy for the subsystem as implemented), the system-type-specific rulebook and containing an SoD rule (see again ¶[0054]; access control rules for a subsystem may reflect an access control policy for the subsystem as implemented See again ¶[0137]; separation of duty guidelines) and a plurality of business functions governed by the SoD rule (see ¶[0091], [0120] and [0146]-[0149]; policy engine may provide functionality to specify control policies for actors and object in various subsystems. The rule or policy may be invalidated if paths from other actors exist. Include functionality to determine whether a solution exists to satisfy a problem), each of the plurality of business functions having a set of permissions (see ¶[0086]-[0087]; users may be associated with respective groups each associated with access permissions) and a logical operator (see ¶[0052], [0094], [0113], and [0148]-[0153]; specify access control rules using logical expressions. Examiner Note: logical expressions with Boolean operators are displayed), the permissions metadata file containing metadata describing the SoD rule and the plurality of business functions (see ¶[0086]-[0087]; user groups associated with permissions and access privileges. Each subsystem is governed by control policies. See again ¶[0052] and [0069]; rules may be based on attributes, tags, and/or metadata associated with objects or actors. See also ¶[0109]-[0110] and Figs. 3C-E; a Table with fields and metadata associated with entities and an access path);
storing the permissions metadata file in a cloud storage (see ¶[0052] and [0105]; determine actor geography based on metadata in a [human resources] database. Information pertaining to the access policy graph may be stored in a graph database).
SAXENA does not specifically disclose, but RAPHAEL discloses, storing second stub data corresponding to the metadata describing the rule and the plurality of business functions in the database (see abstract and ¶[0005] & [0059] and Fig. 3; catalog lists virtual information assets. Catalog contains metadata storing information asset instances. A virtual information asset is a stub structure that contains metadata. The access management server 302 contains catalog, enforcement knowledge graph, and policy database containing rules and policies. Terms are found in a business glossary),
wherein the second stub data is configured for establishing links between the SoD rule and the plurality of business functions in the database for multi-system analysis (see Fig. 3 and claim 1; catalog 312 is a business glossary that lists virtual information referencing real tabular data. Apply access enforcement policy rules to the virtual information asset to determine an enforcement decision).
SAXENA further discloses, analyzing, by the analytics engine, the plurality of business functions as governed by the SoD rule against the security principals and the associated permissions (see ¶[0003]-[0004] and [0078]; analyze access control policies. IT security policy analysis is sporadic. Ensure that resources are access by authorized entities. Provide software applications for customer use. Cloud providers supply compute, network and storage but cloud customers run, manage, and configure their own VMs);
determining, by the analytics engine, hits that satisfy the set of permissions and the logical operator (see ¶[0013]-[0015] and Figs. 4B-F & 10; in response to a query, display a graphical representation of control policies responsive to the query. See also ¶[0118] and [0152]-[153]; a real time query with logical statements. Use a NOT logical operation); and
storing, by the analytics engine, the hits in a database (see ¶[0118] and [0142]-[0143]; analysis and querying of the access policy graph may be facilitated using saved queries. In some embodiments, the database may support queries pertaining to entities affected by a change in access control policy. See also ¶[0215]-[0219]; process user queries and generate reports related to saved queries.), wherein the analytics engine is operable to receive a request for a multi-system analysis (see ¶[0063]; multiple disparate access control policies applied at different objects and services may be used to implement the access control policy) and, responsive to the request, query the database for complete permissions on a per user basis across the plurality of enterprise-class systems (see ¶[0086]-[0087], [0096], and [0105]; users by be associated with respective groups associated with access permissions. Users 102-1, 102-2, 102-3, 102-s may be associated with respective groups).
SAXENA does not explicitly disclose, but GRACK discloses, by performing crossover checks linking user groups from a first system of the plurality of enterprise-class systems utilizing a group-based security model to user roles from a second system of the plurality of enterprise-class systems utilizing a role-based security model for detecting SoD risks across the plurality of enterprise-class systems (see claim 1; implementing role based security in an enterprise content management system [using] a role object and . . . using a security proxy property link to role object; adding . . . a security proxy property link to the security adapter object; mapping, using the processor, one or more complex permissions from the role object to one or more primitive permissions).
SAXENA discloses automated access control management for computing systems in a cloud computing environment, where access is defined by policies and rules (see abstract and ¶[0052]) that may include virtual machines (see ¶[0051] and [0076]). RAPHAEL discloses enforcement of data protections policies with policy rules applied to virtual information assets as a stub structure (see abstract and ¶[0059]). It would have been obvious to include the stub structure as taught by RAPHAEL in the system executing the method of SAXENA with the motivation to reference real data sets using virtual information (see RAPHAEL ¶[0059]).
SAXENA discloses automated access control management for computing systems in a cloud computing environment, where access is defined by policies and rules (see abstract and ¶[0052]) across disparate systems (see ¶[0005]. GRACK discloses role based security in an enterprise content management system that includes linking roles to role objects to determine permissions in an enterprise content management system. It would have been obvious to include linking of role objects to roles to determine permissions as taught by GRACK in the system executing the method of SAXENA with the motivation to determine access in an enterprise computing environment.
Claim 2 (Original)
The combination of SAXENA, RAPHAEL, and GRACK discloses the method according to claim 1.
SAXENA further discloses wherein the hits comprise at least a user-to- permission hit, a group-to-permission hit (see ¶[0086], [0105], [0109], and [0155] & Fig. 3D; users are associated with groups that are associated with access permissions. A connection or edge between a pair of nodes represents permissions or privileges. Run a query to determine whether an entity has access to an entity with a set of permissions under a set of conditions), or a role-to-permission hit (see ¶[0069]; use a query to review attributes associated with entities (e.g., roles). Determine whether access to objects are possible for an entity with a role R).
Claim 3 (Original)
The combination of SAXENA, RAPHAEL, and GRACK discloses the method according to claim 1.
SAXENA further discloses wherein the security principals comprise users, roles, groups, or profiles (see ¶[0069]; rules, roles, groups, etc. See also ¶[0052] and [0096]; rules may be based on attributes associated with actors, and profiles including actor risk profiles.).
Claim 4 (Original)
The combination of SAXENA, RAPHAEL, and GRACK discloses the method according to claim 1.
SAXENA additionally discloses further comprising: determining, from the database, a list of permissions on a per user basis across the plurality of enterprise-class systems in the enterprise computing environment, wherein the determining comprises linking a user to a profile or a group, linking the profile or the group to a role, and linking the user to permissions assigned to the role through the profile or the group (see ¶[0118]; nodes may be linked in the access policy graph. See also ¶[0020] and [0069]-[0071]; attributes are associated with entities (e.g., objects services, users roles groups). Determine whether an entity that has an attribute and a role R and objects have classification C may access objects O. Determine objects that actors in classes are able to access based on control policies).
Claim 5 (Original)
The combination of SAXENA, RAPHAEL, and GRACK discloses the method according to claim 4.
SAXENA further discloses wherein the determining further comprises: linking the user to the role, linking the role to the profile or the group, and linking the user to permissions assigned to the profile or the group through the role (see ¶[0069]-[0071] and [0118]; allow data in the store to be linked. Review attributes associated with entities (e.g. users, roles, groups). Determine whether a set of objects may be accessed by an entity. “Developer” role may not access data tagged as “sensitive.” See also ¶[0053]-[0055]; lower level policies may inherit rules associated with higher level policies. Policies are hierarchical).
Claim 8 (Currently Amended)
SAXENA discloses a system for identifying enterprise-wide Segregation of Duties (SoD) risks (see ¶[0137]; a best practices testing block that measures how closely policies track best practices in security. Separation of duty guidelines. See also ¶[0021]-[0022]; the prediction may be used to identify risk) across disparate enterprise-class systems (see ¶[0005]; an IT infrastructure with disparate subsystems) in an enterprise computing environment (see ¶[0064]; audit and compliance teams in enterprises), the system, comprising: a processor (see ¶[0006]; a processor-implemented method); a non-transitory computer-readable medium (see ¶[0008]; a computer readable medium); and instructions stored on the non-transitory computer-readable medium and translatable by the processor (see again ¶[0008]; instructions to configure a processor) for: generating a security extract metadata file from a system-specific security extract (see ¶[0002]-[0003], [0052], [0069] and [0174]; cyber security access rules with metadata associated with an object access request. Conditions associated with queries may involve attributes associated with any entity and/or objects. A cluster may be determined based on metadata) the analytics engine having a system-specific component and an enterprise-wide component (see ¶[0077]; a private cloud within an enterprise’s data center and/or a hybrid cloud), wherein the system-specific component comprises an extract processor (see ¶[0006]; a processor-implemented method) operable to transform the system-specific security extract into a system-agnostic standardized format (see ¶[0091] and [0104]; store the access control policies in a standardized format such as policy representation [PR]) and generate the security extract metadata file (see ¶[0052], [0069], and [0174]; metrics are determined from metadata associated with objects and/or actors. Determine actor geography from metadata associated with the object access request. Query a system to determine entities that have access to an object. Conditions associated with queries may involve metadata associated with objects), and wherein the enterprise-wide component comprises a rulebook compiler operable to compile a rulebook per a system type (see ¶[0003] & [0052]-[0053] and Figs. 4H-I; ensure what resources – e.g., computers data repositories, network resources are accessed by authorized entities. Rules may specify object attributes, including object location, object type, and geography. An access control policy may include a set of one or more rules that apply to a system or subsystem), the system-specific security extract specific to one of a plurality of enterprise- class systems in an enterprise computing environment (see ¶[0064]; certify access to various actors and class classed of actors in an enterprise), the security extract metadata file containing metadata describing security principals and associated permissions (see ¶[0086]-[0087], [0105] and [0204]; users may be associated with groups that are associated with access permissions and services. Conditions may be specified using access policy parameters. A connection of edge may represent permissions or privileges. Edges may include metadata or labels); and
storing the security extract metadata file in a cloud storage (see ¶[0052] and [0105]; determine actor geography based on metadata in a [human resources] database. Information pertaining to the access policy graph may be stored in a graph database).
SAXENA does not specifically disclose, but RAPHAEL discloses, storing first stub data corresponding to the metadata describing the security principals and the associated permissions in a database (see abstract and ¶[0059] and Fig. 3; catalog lists virtual information assets. Catalog contains metadata storing information asset instances. A virtual information asset is a stub structure that contains metadata. The access management server 302 contains catalog, enforcement knowledge graph, and policy database containing rules and policies).
SAXENA further discloses, wherein the database is accessible by the analytics engine (see ¶[0003] and [0058]-[0059]; a cloud infrastructure. Network databases and cloud services).
SAXENA does not specifically disclose, but RAPHAEL discloses, and wherein the first stub data is configured for establishing links between the security principals and permissions across the plurality of enterprise-class systems (see abstract and ¶[0059] and Fig. 3; catalog lists virtual information assets. Catalog contains metadata storing information asset instances. A virtual information asset is a stub structure that contains metadata. The access management server 302 contains catalog, enforcement knowledge graph, and policy database containing rules and policies. See also ¶[0001]-[0002] and [0024]; the disclosure relates to data security. Server provides data corresponding to an enterprise).
SAXENA further discloses generating a permissions metadata file from a system-type-specific rulebook (see ¶[0052]-[0054]; rules based on attributes. An access control policy may include a set of one or more rules. The set of access control rules for a subsystem may reflect an access control policy for the subsystem as implemented), the system-type-specific rulebook specific to a system type and containing an SoD rule (see again ¶[0054]; access control rules for a subsystem may reflect an access control policy for the subsystem as implemented) and a plurality of business functions governed by the SoD rule (see ¶[0091], [0120] and [0146]-[0149]; policy engine may provide functionality to specify control policies for actors and object in various subsystems. The rule or policy may be invalidated if paths from other actors exist. Include functionality to determine whether a solution exists to satisfy a problem), each of the plurality of business functions having a set of permissions (see ¶[0086]-[0087]; users may be associated with respective groups each associated with access permissions) and a logical operator (see ¶[0052], [0094], [0113], and [0148]-[0153]; specify access control rules using logical expressions. Examiner Note: logical expressions with Boolean operators are displayed), the permissions metadata file containing metadata describing the SoD rule and the plurality of business functions (see ¶[0086]-[0087]; user groups associated with permissions and access privileges. Each subsystem is governed by control policies. See again ¶[0052] and [0069]; rules may be based on attributes, tags, and/or metadata associated with objects or actors. See also ¶[0109]-[0110] and Figs. 3C-E; a Table with fields and metadata associated with entities and an access path); and
storing the permissions metadata file in a cloud storage (see ¶[0052] and [0105]; determine actor geography based on metadata in a [human resources] database. Information pertaining to the access policy graph may be stored in a graph database).
SAXENA does not specifically disclose, but RAPHAEL discloses, storing second stub data corresponding to the metadata describing the rule and the plurality of business functions in the database (see abstract and ¶[0005] & [0059] and Fig. 3; catalog lists virtual information assets. Catalog contains metadata storing information asset instances. A virtual information asset is a stub structure that contains metadata. The access management server 302 contains catalog, enforcement knowledge graph, and policy database containing rules and policies. Terms are found in a business glossary).
wherein the second stub data is configured for establishing links between the SoD rule and the plurality of business functions in the database for multi-system analysis (see Fig. 3 and claim 1; catalog 312 is a business glossary that lists virtual information referencing real tabular data. Apply access enforcement policy rules to the virtual information asset to determine an enforcement decision).
SAXENA further discloses analyzing the plurality of business functions as governed by the SoD rule against the security principals and the associated permissions (see ¶[0003]-[0004] and [0078]; analyze access control policies. IT security policy analysis is sporadic. Ensure that resources are access by authorized entities. Provide software applications for customer use. Cloud providers supply compute, network and storage but cloud customers run, manage, and configure their own VMs);
determining hits that satisfy the set of permissions and the logical operator (see ¶[0013]-[0015] and Figs. 4B-F & 10; in response to a query, display a graphical representation of control policies responsive to the query. See also ¶[0118] and [0152]-[153]; a real time query with logical statements. Use a NOT logical operation); and
storing the hits in a database (see ¶[0118] and [0142]-[0143]; analysis and querying of the access policy graph may be facilitated using saved queries. In some embodiments, the database may support queries pertaining to entities affected by a change in access control policy. See also ¶[0215]-[0219]; process user queries and generate reports related to saved queries.), wherein the analytics engine is operable to receive a request for a multi-system analysis (see ¶[0063]; multiple disparate access control policies applied at different objects and services may be used to implement the access control policy) and, responsive to the request, query the database for complete permissions on a per user basis across the plurality of enterprise-class systems (see ¶[0086]-[0087], [0096], and [0105]; users by be associated with respective groups associated with access permissions. Users 102-1, 102-2, 102-3, 102-s may be associated with respective groups).
SAXENA does not explicitly disclose, but GRACK discloses, by performing crossover checks linking user groups from a first system of the plurality of enterprise-class systems utilizing a group-based security model to user roles from a second system of the plurality of enterprise-class systems utilizing a role-based security model for detecting SoD risks across the plurality of enterprise-class systems (see claim 1; implementing role based security in an enterprise content management system [using] a role object and . . . using a security proxy property link to role object; adding . . . a security proxy property link to the security adapter object; mapping, using the processor, one or more complex permissions from the role object to one or more primitive permissions).
SAXENA discloses automated access control management for computing systems in a cloud computing environment, where access is defined by policies and rules (see abstract and ¶[0052]) that may include virtual machines (see ¶[0051] and [0076]). RAPHAEL discloses enforcement of data protections policies with policy rules applied to virtual information assets as a stub structure (see abstract and ¶[0059]). It would have been obvious to include the stub structure as taught by RAPHAEL in the system executing the method of SAXENA with the motivation to reference real data sets using virtual information (see RAPHAEL ¶[0059]).
SAXENA discloses automated access control management for computing systems in a cloud computing environment, where access is defined by policies and rules (see abstract and ¶[0052]) across disparate systems (see ¶[0005]. GRACK discloses role based security in an enterprise content management system that includes linking roles to role objects to determine permissions in an enterprise content management system. It would have been obvious to include linking of role objects to roles to determine permissions as taught by GRACK in the system executing the method of SAXENA with the motivation to determine access in an enterprise computing environment.
Claim 9 (Original)
The combination of SAXENA, RAPHAEL, and GRACK discloses the system as set forth in claim 8.
SAXENA further discloses wherein the hits comprise at least a user-to-permission hit, a group-to-permission hit (see ¶[0086], [0105], [0109], and [0155] & Fig. 3D; users are associated with groups that are associated with access permissions. A connection or edge between a pair of nodes represents permissions or privileges. Run a query to determine whether an entity has access to an entity with a set of permissions under a set of conditions), or a role-to-permission hit (see ¶[0069]; use a query to review attributes associated with entities (e.g., roles). Determine whether access to objects are possible for an entity with a role R).
Claim 10 (Original)
The combination of SAXENA, RAPHAEL, and GRACK discloses the system as set forth in claim 8.
SAXENA further discloses wherein the security principals comprise users, roles, groups, or profiles (see ¶[0069]; rules, roles, groups, etc. See also ¶[0052] and [0096]; rules may be based on attributes associated with actors, and profiles including actor risk profiles.).
Claim 11 (Original)
The combination of SAXENA, RAPHAEL, and GRACK discloses the system as set forth in claim 8.
SAXENA additionally discloses wherein the instructions are further translatable by the processor for: determining, from the database, a list of permissions on a per user basis across the plurality of enterprise-class systems in the enterprise computing environment, wherein the determining comprises linking a user to a profile or a group, linking the profile or the group to a role, and linking the user to permissions assigned to the role through the profile or the group (see ¶[0118]; nodes may be linked in the access policy graph. See also ¶[0020] and [0069]-[0071]; attributes are associated with entities (e.g., objects services, users roles groups). Determine whether an entity that has an attribute and a role R and objects have classification C may access objects O. Determine objects that actors in classes are able to access based on control policies).
Claim 12 (Original)
The combination of SAXENA, RAPHAEL, and GRACK discloses the system as set forth in claim 11.
SAXENA further discloses wherein the determining further comprises: linking the user to the role, linking the role to the profile or the group, and linking the user to permissions assigned to the profile or the group through the role (see ¶[0069]-[0071] and [0118]; allow data in the store to be linked. Review attributes associated with entities (e.g. users, roles, groups). Determine whether a set of objects may be accessed by an entity. “Developer” role may not access data tagged as “sensitive.” See also ¶[0053]-[0055]; lower level policies may inherit rules associated with higher level policies. Policies are hierarchical).
Claim 15 (Currently Amended)
SAXENA discloses a computer program product for identifying enterprise-wide Segregation of Duties (SoD) risks (see ¶[0137]; a best practices testing block that measures how closely policies track best practices in security. Separation of duty guidelines. See also ¶[0021]-[0022]; the prediction may be used to identify risk) across disparate enterprise-class systems (see ¶[0005]; an IT infrastructure with disparate subsystems) in an enterprise computing environment (see ¶[0064]; audit and compliance teams in enterprises), the computer program product comprising a non-transitory computer-readable medium (see ¶[0008]; a computer readable medium) storing instructions translatable by a processor (see again ¶[0008]; instructions to configure a processor) for implementing an analytics engine having a system-specific component and an enterprise-wide component (see ¶[0077]; a private cloud within an enterprise’s data center and/or a hybrid cloud), wherein the system-specific component comprises an extract processor (see ¶[0006]; a processor-implemented method) operable to transform the system-specific security extract into a system-agnostic standardized format (see ¶[0091] and [0104]; store the access control policies in a standardized format such as policy representation [PR]) and generate the security extract metadata file (see ¶[0052], [0069], and [0174]; metrics are determined from metadata associated with objects and/or actors. Determine actor geography from metadata associated with the object access request. Query a system to determine entities that have access to an object. Conditions associated with queries may involve metadata associated with objects), and wherein the enterprise-wide component comprises a rulebook compiler operable to compile a rulebook per a system type (see ¶[0003] & [0052]-[0053] and Figs. 4H-I; ensure what resources – e.g., computers data repositories, network resources are accessed by authorized entities. Rules may specify object attributes, including object location, object type, and geography. An access control policy may include a set of one or more rules that apply to a system or subsystem), the instructions when translated by the processor further perform: generating a security extract metadata file from the system-specific security extract (see ¶[0002]-[0003], [0052], [0069] and [0174]; cyber security access rules with metadata associated with an object access request. Conditions associated with queries may involve attributes associated with any entity and/or objects. A cluster may be determined based on metadata), the system-specific security extract specific to one of a plurality of enterprise-class systems in an enterprise computing environment (see ¶[0064]; certify access to various actors and class classed of actors in an enterprise), the security extract metadata file containing metadata describing security principals and associated permissions (see ¶[0086]-[0087], [0105] and [0204]; users may be associated with groups that are associated with access permissions and services. Conditions may be specified using access policy parameters. A connection of edge may represent permissions or privileges. Edges may include metadata or labels);
storing the security extract metadata file in a cloud storage (see ¶[0052] and [0105]; determine actor geography based on metadata in a [human resources] database. Information pertaining to the access policy graph may be stored in a graph database).
SAXENA does not specifically disclose, but RAPHAEL discloses, storing first stub data corresponding to the metadata describing the security principals and the associated permissions in a database (see abstract and ¶[0059] and Fig. 3; catalog lists virtual information assets. Catalog contains metadata storing information asset instances. A virtual information asset is a stub structure that contains metadata. The access management server 302 contains catalog, enforcement knowledge graph, and policy database containing rules and policies).
SAXENA further discloses, wherein the database is accessible by the analytics engine (see ¶[0003] and [0058]-[0059]; a cloud infrastructure. Network databases and cloud services).
SAXENA does not specifically disclose, but RAPHAEL discloses, and wherein the first stub data is configured for establishing links between the security principals and permissions across the plurality of enterprise-class systems (see abstract and ¶[0059] and Fig. 3; catalog lists virtual information assets. Catalog contains metadata storing information asset instances. A virtual information asset is a stub structure that contains metadata. The access management server 302 contains catalog, enforcement knowledge graph, and policy database containing rules and policies. See also ¶[0001]-[0002] and [0024]; the disclosure relates to data security. Server provides data corresponding to an enterprise).
SAXENA further discloses, generating a permissions metadata file from a system-type-specific rulebook (see ¶[0052]-[0054]; rules based on attributes. An access control policy may include a set of one or more rules. The set of access control rules for a subsystem may reflect an access control policy for the subsystem as implemented), the system-type-specific rulebook containing an SoD rule (see again ¶[0054]; access control rules for a subsystem may reflect an access control policy for the subsystem as implemented See again ¶[0137]; separation of duty guidelines) and a plurality of business functions governed by the SoD rule (see ¶[0091], [0120] and [0146]-[0149]; policy engine may provide functionality to specify control policies for actors and object in various subsystems. The rule or policy may be invalidated if paths from other actors exist. Include functionality to determine whether a solution exists to satisfy a problem), each of the plurality of business functions having a set of permissions (see ¶[0086]-[0087]; users may be associated with respective groups each associated with access permissions) and a logical operator (see ¶[0052], [0094], [0113], and [0148]-[0153]; specify access control rules using logical expressions. Examiner Note: logical expressions with Boolean operators are displayed), the permissions metadata file containing metadata describing the SoD rule and the plurality of business functions (see ¶[0086]-[0087]; user groups associated with permissions and access privileges. Each subsystem is governed by control policies. See again ¶[0052] and [0069]; rules may be based on attributes, tags, and/or metadata associated with objects or actors. See also ¶[0109]-[0110] and Figs. 3C-E; a Table with fields and metadata associated with entities and an access path); and
storing the permissions metadata file in a cloud storage (see ¶[0052] and [0105]; determine actor geography based on metadata in a [human resources] database. Information pertaining to the access policy graph may be stored in a graph database).
SAXENA does not specifically disclose, but RAPHAEL discloses, storing second stub data corresponding to the metadata describing the rule and the plurality of business functions in the database (see abstract and ¶[0005] & [0059] and Fig. 3; catalog lists virtual information assets. Catalog contains metadata storing information asset instances. A virtual information asset is a stub structure that contains metadata. The access management server 302 contains catalog, enforcement knowledge graph, and policy database containing rules and policies. Terms are found in a business glossary).
wherein the second stub data is configured for establishing links between the SoD rule and the plurality of business functions in the database for multi-system analysis (see Fig. 3 and claim 1; catalog 312 is a business glossary that lists virtual information referencing real tabular data. Apply access enforcement policy rules to the virtual information asset to determine an enforcement decision).
SAXENA further discloses, analyzing the plurality of business functions as governed by the SoD rule against the security principals and the associated permissions (see ¶[0003]-[0004] and [0078]; analyze access control policies. IT security policy analysis is sporadic. Ensure that resources are access by authorized entities. Provide software applications for customer use. Cloud providers supply compute, network and storage but cloud customers run, manage, and configure their own VMs);
determining hits that satisfy the set of permissions and the logical operator (see ¶[0013]-[0015] and Figs. 4B-F & 10; in response to a query, display a graphical representation of control policies responsive to the query. See also ¶[0118] and [0152]-[153]; a real time query with logical statements. Use a NOT logical operation); and
storing the hits in a database (see ¶[0118] and [0142]-[0143]; analysis and querying of the access policy graph may be facilitated using saved queries. In some embodiments, the database may support queries pertaining to entities affected by a change in access control policy. See also ¶[0215]-[0219]; process user queries and generate reports related to saved queries.) .), wherein the analytics engine is operable to receive a request for a multi-system analysis (see ¶[0063]; multiple disparate access control policies applied at different objects and services may be used to implement the access control policy) and, responsive to the request, query the database for complete permissions on a per user basis across the plurality of enterprise-class systems (see ¶[0086]-[0087], [0096], and [0105]; users by be associated with respective groups associated with access permissions. Users 102-1, 102-2, 102-3, 102-s may be associated with respective groups).
SAXENA does not explicitly disclose, but GRACK discloses, by performing crossover checks linking user groups from a first system of the plurality of enterprise-class systems utilizing a group-based security model to user roles from a second system of the plurality of enterprise-class systems utilizing a role-based security model for detecting SoD risks across the plurality of enterprise-class systems (see claim 1; implementing role based security in an enterprise content management system [using] a role object and . . . using a security proxy property link to role object; adding . . . a security proxy property link to the security adapter object; mapping, using the processor, one or more complex permissions from the role object to one or more primitive permissions).
SAXENA discloses automated access control management for computing systems in a cloud computing environment, where access is defined by policies and rules (see abstract and ¶[0052]) that may include virtual machines (see ¶[0051] and [0076]). RAPHAEL discloses enforcement of data protections policies with policy rules applied to virtual information assets as a stub structure (see abstract and ¶[0059]). It would have been obvious to include the stub structure as taught by RAPHAEL in the system executing the method of SAXENA with the motivation to reference real data sets using virtual information (see RAPHAEL ¶[0059]).
SAXENA discloses automated access control management for computing systems in a cloud computing environment, where access is defined by policies and rules (see abstract and ¶[0052]) across disparate systems (see ¶[0005]. GRACK discloses role based security in an enterprise content management system that includes linking roles to role objects to determine permissions in an enterprise content management system. It would have been obvious to include linking of role objects to roles to determine permissions as taught by GRACK in the system executing the method of SAXENA with the motivation to determine access in an enterprise computing environment.
Claim 16 (Original)
The combination of SAXENA, RAPHAEL, and GRACK discloses the computer program product as set forth in claim 15.
SAXENA further discloses wherein the hits comprise at least a user-to- permission hit, a group-to-permission hit (see ¶[0086], [0105], [0109], and [0155] & Fig. 3D; users are associated with groups that are associated with access permissions. A connection or edge between a pair of nodes represents permissions or privileges. Run a query to determine whether an entity has access to an entity with a set of permissions under a set of conditions), or a role-to-permission hit (see ¶[0069]; use a query to review attributes associated with entities (e.g., roles). Determine whether access to objects are possible for an entity with a role R).
Claim 17 (Original)
The combination of SAXENA, RAPHAEL, and GRACK discloses the computer program product as set forth in claim 15.
SAXENA additionally discloses wherein the instructions are further translatable by the processor for: determining, from the database, a list of permissions on a per user basis across the plurality of enterprise-class systems in the enterprise computing environment, wherein the determining comprises linking a user to a profile or a group, linking the profile or the group to a role, and linking the user to permissions assigned to the role through the profile or the group (see ¶[0118]; nodes may be linked in the access policy graph. See also ¶[0020] and [0069]-[0071]; attributes are associated with entities (e.g., objects services, users roles groups). Determine whether an entity that has an attribute and a role R and objects have classification C may access objects O. Determine objects that actors in classes are able to access based on control policies).
Claim 18 (Original)
The combination of SAXENA, RAPHAEL, and GRACK discloses the computer program product as set forth in claim 17.
SAXENA further discloses wherein the determining further comprises: linking the user to the role, linking the role to the profile or the group, and linking the user to permissions assigned to the profile or the group through the role (see ¶[0069]-[0071] and [0118]; allow data in the store to be linked. Review attributes associated with entities (e.g. users, roles, groups). Determine whether a set of objects may be accessed by an entity. “Developer” role may not access data tagged as “sensitive.” See also ¶[0053]-[0055]; lower level policies may inherit rules associated with higher level policies. Policies are hierarchical).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RICHARD N SCHEUNEMANN whose telephone number is (571)270-7947. The examiner can normally be reached M-F 9am-5pm EST.
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, Patricia Munson can be reached at 571-270-5396. 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.
/RICHARD N SCHEUNEMANN/Primary Examiner, Art Unit 3624
Prosecution Insights