DETAILED ACTION
Introduction
This Final Office Action is in response to remarks filed on June 29, 2026, for the application with serial number 18/077,644.
Claims 1-5, 8-12, and 15-18 are pending. Note that claim 15 is labeled “currently amended,” but claim 15 is not marked up. Therefore, claim 15 will be treated as previously presented.
Interview
The Examiner acknowledges the interview conducted on June 29, 2026, in which the subject matter eligibility of the claims was discussed with regards to the Finjan decision.
Response to Remarks
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. Specifically, the Applicant submits that the present claims recite subject matter that is similar to the subject matter recited in Finjan v. Blue Coat. See Remarks p. 9. In response, the Examiner points out that the Finjan claims involve the apparent use of a link of a Downloadable to a security profile that apparently improves the performance of a computer. In contrast, the present claims merely recite steps for defining user permissions to access a system. No apparent improvement to the performance of a machine is recited in the claims. The “links” of the present claims do not appear to be hyperlinks; the “links” are merely associations. See, for example, ¶[0007] and Fig. 5 of the present Application that discusses linking risks. Contrary to the Applicant’s assertions, the present claims do not contain a specific data structure. The claims merely recite steps for determining user permissions based on roles and defined user groups. No apparent improvement to the performance of a computer as a tool is recited in the claims. It is unclear to the Examiner what was previously “impossible” in the art, as alleged by the Applicant. Defining access and user permissions across different systems is, on its face, not impossible. For example, providing an administrative user with administrative access to two different systems is not an inherent impossibility. The idea is abstract, as indicated in the rejection, below.
The rejection for lack of subject matter eligibility is maintained.
35 USC §103 Rejections
The Applicant traverses the rejection of independent claims 1, 8, and 15 as being obvious over Saxena in view of Raphael and Grack; contending that the combination of references do not teach disparate systems. See Remarks pp. 14-15. In response, the Examiner points out the breadth of the term: “systems.” Computer software and hardware “systems”, in general, contain combinable elements. It can be difficult do distinguish what constitutes a “system;” and what distinguishes a single “system” from multiple “systems.” For example, multiple computers running different operating systems on a network could be said to be part of a single system. The skilled artisan would understand that the method of Grack could be implemented across multiple systems. This is evidenced by a full reading of Grack, which states that a computing system may contain one or more operating systems. See col 6, ln 59-col 7, ln 12 & col 8, ln 44-59. Moreover, Grack is combined with Saxena, and Saxena explicitly teaches an IT infrastructure is disparate subsystems. See Saxena ¶[0005].
The Applicant further contends that Grack is deficient because Grack does not teach detection of SoD risks. See Remarks p. 15. Again, the Examiner reiterates that Grack is combined with Saxena. The combination of references would lead the skilled artisan to the claimed invention. Saxena teaches identification of risk based on separation of duty guidelines. See cited ¶[0021]-[0022] and [0137]. Grack is merely cited for permissions linked to roles, as indicated.
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 (Previously Presented)
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 accessed by authorized entities. Provide software applications for customer use. Cloud providers supply computers, 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 (Previously Presented)
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 accessed by authorized entities. Provide software applications for customer use. Cloud providers supply computers, 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 (Previously Presented)
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 accessed by authorized entities. Provide software applications for customer use. Cloud providers supply computers, 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
THIS ACTION IS MADE FINAL. 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 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