DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments with respect to claim(s) have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant argued in the remark that
identifying, for the first execution path, a first implementation instance in a first programming application;
identifying, for the first execution path, a second implementation instance in a second programming application, wherein the first programming application is different from the second programming application.
Examiner respectfully disagrees. The above amendment limitations are teaching by the Van Riel et al US 2010/0132012. identifying, for the first execution path, a first implementation instance in a first programming application ([0033] System 100 also includes policy manager 120, which represents one or more components or modules within system 100 that manages security policies for userspace path containers, such as a process 142, i.e. a first instance, of the path containers 132, i.e. of the first programming application, Par 0056, a path container identifier associated with path container (132,134,230) in which the identifier program executes. It can be seen as the policy manager identifying the path of the container to identifier program executes 132 of the 142. The path container identifier acts as a secure, non-forgeable ID card that the running program carries, allowing the underlying security system to apply the correct access control rules for that specific isolated environment);
identifying, for the first execution path, a second implementation instance in a second programming application ( [0033] System 100 also includes policy manager 120, which represents one or more components or modules within system 100 that manages security policies for userspace path containers, such as path containers in process 146, i.e. a second instance , of the path container 134 i.e. a second programming application, Par 0056, a path container identifier associated with path container (132,134,230) in which the identifier program executes. The identifier could be part of a path used to access specific process 146, i.e. instance of the path container 134, i.e. second programming application. It can be seen as the policy manager identifying the path of the container to identifier program executes 134 of the 146), wherein the first programming application is different from the second programming application (fig.1, ([0033] System 100 also includes policy manager 120, which represents one or more components or modules within system 100 that manages security policies for userspace path containers, such as a process 142, i.e. a first instance, of the path containers 132, i.e. of the first programming application, [0033] System 100 also includes policy manager 120, which represents one or more components or modules within system 100 that manages security policies for userspace path containers, such as path containers in process 146, i.e. a second instance , of the path container 134 i.e. a second programming application).
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-11 and 13-20 are rejected under 35 U.S.C. 103 as being unpatentable over Ross et al US 11,711374 in view of Allen US 10,419,483 and Van Riel et al US 2010/0132012.
As per claim 1. Ross discloses computer-implemented method for determining implementation consistency for one or more role-based access control (RBAC) policies (col 1, lines 62-67 the whitelist including Role Based Access Control (RBAC) rules and permissions associated with the plurality of users to understand access currently allowed from the plurality of users to the applications, the permissions deployed via an application programing interface (API) onto an identity access management (IAM) system within the computing environment. Wherein the based on the permission the identity access management path is executed in the computing environment) comprising:
generating an abstract policy model of a first RBAC policy using a symbolic abstraction model to determine a set of execution paths for the first RBAC policy (col 2, lines 62-65 graphically visualizing the permissions provided to organizational units of users or individual users and overlaying that information with actual user behavior col 3, lines 17-19 a configuration file or program via application programming interfaces (APIs) of the identity and access management system. and col 19, lines 65-67 generating a whitelist , i.e. abstract policy model, identifying at least one user of the plurality of users permitted to access at least one application. col 20, lines 14-28 generating further permissions for the plurality of users based on the metadata associated with accessing the applications by the plurality of users.
(118) The method 1000 may include providing a graphical representation, i.e. a symbolic abstraction model , of actions of the user with respect to the actions the user is entitled to perform and actions that the user actually performs with respect to the application. Thus, the system can analyze the activity and behavior of users, and analyze the information related to the access of the users to the application and actions performed by the users with respect to the application. Permissions provided to the user based on the role , i.e. role based policy, may be compared with access, i.e. a set of execution of paths, of the user to the application and actions performed by the user with respect to the application );
determining a first satisfiability function representation for a first execution path of the set of execution paths using the symbolic abstraction model (col 17, lines 44-49 the metadata discovered about user access behavior may include network logs of the user access events into the applications or other user activity conducted on client devices. The metadata may include telemetry data concerning access operations, i.e. satisfiability function, time of day, a client device used or an amount of data written to or read from the applications, The metadata may also include data from an identity store utilized by the system to organize information into a consumable form around organization units, groups, and roles. The metadata may also include the RBAC rules and permissions associated with the users and groups of users to understand the access to the applications currently allowed for the users. wherein the metadata is generating by access operations of the application of nodes wherein the node can be the user, client and not limited);
in response to providing the first satisfiability function representation to a satisfiability solver model, receiving a first input from the satisfiability solver model that is an example solution to the first execution path(col 17, lines 57-62 The controller 210 can analyze metadata, i.e. a satisfiability solver model, to determine the access behavior of users within different organizational units defined within the identity store. This access behavior can be compared against policies that are defined around organizational access permissions to ensure that corporate policies are not breached);
identifying, for the first execution path, a first implementation instance in a first application,i.e. a first programming language ( col 18, lines 3-10, the subset 915, i.e. a first implementation instance, may include applications used by users performing a first role in the enterprise and col 18, lines 30-35 The detection of potential exploits may also allow creating a security policy/ subset / implementation instance. The security policy may allow only those relationships that have been established and validated, and disallow creation of any other relationships in the future. ) and a second implementation instance in a second application, i.e. a second programming language, wherein the first programming language is different from the second programming language ( col 18, lines 3-10, the subset 925, i.e. a second implementation instance, may include applications, i.e. second application, used by users performing a second role in the enterprise. The subset 935 may represent potentially vulnerable nodes if security rules of the enterprise prohibit using the same applications or access the same data by users with different roles or business functions within the enterprise).
determining that the first RBAC policy is inconsistently implemented by applying the first input to the first implementation instance and the second implementation instance of the first execution path ( col 18, lines 35-60 , These RBAC policies can be defined, i.e. determining, via a whitelist (commonly known as a zero trust rule set) or as a backlist defining the access that in not permitted. (99) Some embodiments may allow, upon identifying current relationships between different environments, review of the relationships between applications and creating a baseline. The baseline may include currently allowed relationships. The graph database can be constantly updated based on metadata / subset 915 and subset 925, i.e. first and second implementation instance respectively collected from networks logs and analyzed to detect deviations from the baseline.(100) The graph database can be analyzed to determine connections between the applications associated with an individual user, users of a specific role, or users belonging to specific groups. The result of this analysis may allow providing a view of functions of a department, division, and members of the certain roles within the enterprise. Col 17, lines 24-29 The metadata 910-M, 920-M, 930-M, 940-M, 950-M may also include business functions, metadata / subset 915 and subset 925, i.e. first and second implementation instance respectively the applications, regulatory requirements associated with the applications, recovery objectives, cyber security context, types of operations conducted, access operations, time of day, client devices used by the users, and so forth).
Ross does not disclose identifying, for the first execution path, a first implementation instance in a first programming language and a second implementation instance in a second programming language, wherein the first programming language is different from the second programming language; applying the first input to the first implementation instance and the second implementation instance of the first execution path.
However, Allen discloses identifying, for the first execution path, a first implementation instance in a first programming language and a second implementation instance in a second programming language (col 13, lines 30-50 , a branching-type instruction, i.e. first implementation instance, may refer back to a point in a straight-line path that has already been processed; in such a case, the straight-line path may be split into two straight-line paths and an artificial node may be inserted. For example, a program may start at offset 10 in the executable instructions and continue through the straight-line path of instructions to offset 20 ), wherein the first programming language is different from the second programming language (col 21, lines 62-68 and col 22, lines 1-15 col 13, lines 30-50 , a branching-type instruction, i.e. first implementation instance, may refer back to a point in a straight-line path that has already been processed; in such a case, the straight-line path may be split into two straight-line paths and an artificial node may be inserted. For example, a program may start at offset 10 in the executable instructions and continue through the straight-line path of instructions to offset 20 and col 26, lines 23-30 The server(s) also may be capable of executing programs or scripts in response to requests from user devices, such as by executing one or more web applications that may be implemented as one or more scripts or programs written in any programming language, such as Java®, C, C# or C++, or any scripting language, such as Ruby, PHP, Perl, Python or TCL, ) and applying the first input to the first implementation instance and the second implementation instance of the first execution path (col 13, lines 30-50 , a branching-type instruction, i.e. first implementation instance, may refer back to a point in a straight-line path that has already been processed; in such a case, the straight-line path may be split into two straight-line paths and an artificial node may be inserted. For example, a program may start at offset 10 in the executable instructions and continue through the straight-line path of instructions to offset 20. However, sometime later, there may be a jump instruction to an instruction at offset 14. In such a case, the straight-line path from 10-20 may be broken into a straight-line path from 10-13 and 14-20, and the original straight-line path becomes two consecutive straight-line paths, even though there is no branch in the middle. An artificial node to reflect that there is an external jump into the middle of the straight-line path may be effectively created in this manner. Then, in 518, the code analyzer performing the process 500 determines whether it has reached the last instruction of the program instructions. If more instructions in the program instructions remain to be analyzed, the code analyzer performing the process 500 returns to 506, whereupon the code analyzer retrieves the next instruction , i.e. second implementation instance, of the program instructions and col 22, lines 25-36 the operations performed in 810-16 and 824-28 may be replaced with operations that, for each policy violation, insert hard constraints directly into the original program instructions, except for code portions annotated as critical, in order to produce the remediated instructions. ).
Ross and Allen are both considered to be analogous to the claimed invention because they are in the same field of analyzing the policy.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Ross to incorporate the teachings of Alllen and provide the execution flows.
Doing so would provide the policy analyzer may have determined from the policy that the program instructions, thereby increasing to determine that a hard constraint of ten iterations of the loop may be permitted without violating policies corresponding to the program instructions.
The combination fails to disclose
identifying, for the first execution path, a first implementation instance in a first programming application;
identifying, for the first execution path, a second implementation instance in a second programming application, wherein the first programming application is different from the second programming application.
However, Van Riel et al US 2010/0132012. identifying, for the first execution path, a first implementation instance in a first programming application ([0033] System 100 also includes policy manager 120, which represents one or more components or modules within system 100 that manages security policies for userspace path containers, such as a process 142, i.e. a first instance, of the path containers 132, i.e. of the first programming application, Par 0056, a path container identifier associated with path container (132,134,230) in which the identifier program executes. It can be seen as the policy manager identifying the path of the container to identifier program executes 132 of the 142. The path container identifier acts as a secure, non-forgeable ID card that the running program carries, allowing the underlying security system to apply the correct access control rules for that specific isolated environment);
identifying, for the first execution path, a second implementation instance in a second programming application ( [0033] System 100 also includes policy manager 120, which represents one or more components or modules within system 100 that manages security policies for userspace path containers, such as path containers in process 146, i.e. a second instance , of the path container 134 i.e. a second programming application, Par 0056, a path container identifier associated with path container (132,134,230) in which the identifier program executes. The identifier could be part of a path used to access specific process 146, i.e. instance of the path container 134, i.e. second programming application. It can be seen as the policy manager identifying the path of the container to identifier program executes 134 of the 146), wherein the first programming application is different from the second programming application (fig.1, ([0033] System 100 also includes policy manager 120, which represents one or more components or modules within system 100 that manages security policies for userspace path containers, such as a process 142, i.e. a first instance, of the path containers 132, i.e. of the first programming application, [0033] System 100 also includes policy manager 120, which represents one or more components or modules within system 100 that manages security policies for userspace path containers, such as path containers in process 146, i.e. a second instance , of the path container 134 i.e. a second programming application).
Ross and Allen and Van Riel are both considered to be analogous to the claimed invention because they are in the same field of analyzing the policy.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Ross to incorporate the teachings of Alllen, including the teaching of Van Riel and provide the execution flows.
Doing so would provide the policy analyzer may have determined from the policy that the program instructions, thereby increasing to determine that a hard constraint of ten iterations of the loop may be permitted without violating policies corresponding to the program instructions.
As per claim 2. Ross and Allen and Van Riel discloses the computer-implemented method of claim 1, Ross discloses wherein the first RBAC policy is determined to be inconsistently implemented by determining that a first output of the first implementation instance differs from a second output from the second implementation instance ( col 2, lines 29-40 The metadata may include network logs of the user access events into the applications or other user activity conducted on client devices. The metadata may include telemetry data concerning access operations, time of day, a client device used, or an amount of data written to or read from the applications. The metadata may also include data from identity stores which the system can utilize to organize information into a consumable form. The metadata may also include Role Based Access Control (RBAC) rules and permissions associated with users and groups of users to understand the access currently allowed from the users to the applications).
As per claim 3. Ross and Allen and Van Riel discloses The computer-implemented method of claim 1, Ross discloses wherein the abstract policy model of the first RBAC policy includes an abstraction tree having execution paths that progress through one or more decision nodes representing policy definition conditions (col 17, lines 44-55 The metadata discovered about user access behavior may include network logs of the user access events into the applications or other user activity conducted on client devices. The metadata may include telemetry data concerning access operations, time of day, a client device used or an amount of data written to or read from the applications. The metadata may also include data from an identity store utilized by the system to organize information into a consumable form around organization units, groups, and roles. The metadata may also include the RBAC rules and permissions associated with the users and groups of users to understand the access to the applications currently allowed for the users. ).
As per claim 4. Ross and Allen and Van Riel discloses The computer-implemented method of claim 1, Ross discloses further comprising generating the first execution path into a symbolic expression using the symbolic abstraction model before generating the first satisfiability function representation for the first execution path ( col 2, lines 62-65 graphically visualizing the permissions provided to organizational units of users or individual users and overlaying that information with actual user behavior col 3, lines 17-19 a configuration file or program via application programming interfaces (APIs) of the identity and access management system. and col 19, lines 65-67 generating a whitelist , i.e. abstract policy model, identifying at least one user of the plurality of users permitted to access at least one application. col 20, lines 14-28 generating further permissions for the plurality of users based on the metadata associated with accessing the applications by the plurality of users.
(118) The method 1000 may include providing a graphical representation, i.e. a symbolic abstraction model , of actions of the user with respect to the actions the user is entitled to perform and actions that the user actually performs with respect to the application. Thus, the system can analyze the activity and behavior of users, and analyze the information related to the access of the users to the application and actions performed by the users with respect to the application. Permissions provided to the user based on the role , i.e. role based policy, may be compared with access, i.e. a set of execution of paths, of the user to the application and actions performed by the user with respect to the application).
As per claim 5. Ross and Allen and Van Riel discloses The computer-implemented method of claim 1, Ross discloses further comprising receiving inputs from the satisfiability solver model for each execution path in the abstract policy model (col 17, lines 57-62 The controller 210 can analyze metadata, i.e. a satisfiability solver model, to determine the access behavior of users within different organizational units defined within the identity store. This access behavior can be compared against policies that are defined around organizational access permissions to ensure that corporate policies are not breached ).
As per claim 6. Ross and Allen and Van Riel discloses The computer-implemented method of claim 1, Ross discloses wherein the abstract policy model includes execution paths within the set of execution paths that cover all potential inputs to the first RBAC policy ( col 2, lines 62-65 graphically visualizing the permissions provided to organizational units of users or individual users and overlaying that information with actual user behavior col 3, lines 17-19 a configuration file or program via application programming interfaces (APIs) of the identity and access management system. and col 19, lines 65-67 generating a whitelist , i.e. abstract policy model, identifying at least one user of the plurality of users permitted to access at least one application. col 20, lines 14-28 generating further permissions for the plurality of users based on the metadata associated with accessing the applications by the plurality of users.
(118) The method 1000 may include providing a graphical representation, i.e. a symbolic abstraction model , of actions of the user with respect to the actions the user is entitled to perform and actions that the user actually performs with respect to the application. Thus, the system can analyze the activity and behavior of users, and analyze the information related to the access of the users to the application and actions performed by the users with respect to the application. Permissions provided to the user based on the role , i.e. role based policy, may be compared with access, i.e. a set of execution of paths, of the user to the application and actions performed by the user with respect to the application).
As per claim 7. Ross and Allen and Van Riel discloses The computer-implemented method of claim 1, Ross discloses wherein: the first RBAC policy includes an allow effect and a deny effect; and the abstract policy model includes execution paths corresponding to the allow effect or the deny effect (col 18, lines 20-45 relationships between the applications and groups of users. The groups may include groups of employees within an organizational unit, employees with similar roles, groups of customers of the enterprise, and so forth. Certain embodiments may allow detecting attempts or potential exploits to gain access between different environments. The detection of potential exploits may be implemented with monitoring policies, so if anybody in the future attempts to gain access between different environments, an authorized person can be notified immediately. The detection of potential exploits may also allow creating a security policy. The security policy may allow only those relationships that have been established and validated, and disallow creation of any other relationships in the future.
(98) Alternatively, the prevention of potential exploits may be implemented using RBAC-based permissions which are deployed via API onto the Identity Access Management (IAM) system within the environment (for example, LDAP, Okta, Sailpoint). This approach facilitates the prevention of access which violates corporate policy. These RBAC policies can be defined via a whitelist (commonly known as a zero trust rule set) or as a backlist defining the access that in not permitted.
).
As per claim 8. Ross and Allen and Van Riel discloses The computer-implemented method of claim 7, Ross discloses wherein the abstract policy model includes a second execution path corresponding to both the allow effect and the deny effect (col 18, lines 20-45 relationships between the applications and groups of users. The groups may include groups of employees within an organizational unit, employees with similar roles, groups of customers of the enterprise, and so forth. Certain embodiments may allow detecting attempts or potential exploits to gain access between different environments. The detection of potential exploits may be implemented with monitoring policies, so if anybody in the future attempts to gain access between different environments, an authorized person can be notified immediately).
As per claim 9. Ross and Allen and Van Riel discloses The computer-implemented method of claim 7, Ross discloses wherein the abstract policy model includes a second execution path corresponding to both the allow effect and the deny effect (col 187,lines 20-45 The detection of potential exploits may be implemented with monitoring policies, so if anybody in the future attempts to gain access between different environments, an authorized person can be notified immediately. The detection of potential exploits may also allow creating a security policy. The security policy may allow only those relationships that have been established and validated, and disallow creation of any other relationships in the future.
(98) Alternatively, the prevention of potential exploits may be implemented using RBAC-based permissions which are deployed via API onto the Identity Access Management (IAM) system within the environment (for example, LDAP, Okta, Sailpoint). This approach facilitates the prevention of access which violates corporate policy. These RBAC policies can be defined via a whitelist (commonly known as a zero trust rule set) or as a backlist defining the access that in not permitted.
).
As per claim 10. Ross and Allen and Van Riel discloses The computer-implemented method of claim 1,Ross discloses wherein the symbolic abstraction model generates symbolic expressions of execution paths using a common intermediate language that encodes semantics of multiple source languages (col 13, lines 30-50 , a branching-type instruction, i.e. first implementation instance, may refer back to a point in a straight-line path that has already been processed; in such a case, the straight-line path may be split into two straight-line paths and an artificial node may be inserted. For example, a program may start at offset 10 in the executable instructions and continue through the straight-line path of instructions to offset 20. However, sometime later, there may be a jump instruction to an instruction at offset 14. In such a case, the straight-line path from 10-20 may be broken into a straight-line path from 10-13 and 14-20, and the original straight-line path becomes two consecutive straight-line paths, even though there is no branch in the middle. An artificial node to reflect that there is an external jump into the middle of the straight-line path may be effectively created in this manner. Then, in 518, the code analyzer performing the process 500 determines whether it has reached the last instruction of the program instructions. If more instructions in the program instructions remain to be analyzed, the code analyzer performing the process 500 returns to 506, whereupon the code analyzer retrieves the next instruction , i.e. second implementation instance, of the program instructions and col 22, lines 25-36 the operations performed in 810-16 and 824-28 may be replaced with operations that, for each policy violation, insert hard constraints directly into the original program instructions, except for code portions annotated as critical, in order to produce the remediated instructions ).
As per claim 11. Ross and Allen and Van Riel discloses The computer-implemented method of claim 10, Allen discloses wherein the first implementation instance in the first programming language is obtained from a cloud computing system that stores multiple implementation instances of the first execution path (col 13, lines 30-50 , a branching-type instruction, i.e. first implementation instance, may refer back to a point in a straight-line path that has already been processed; in such a case, the straight-line path may be split into two straight-line paths and an artificial node may be inserted. For example, a program may start at offset 10 in the executable instructions and continue through the straight-line path of instructions to offset 20. However, sometime later, there may be a jump instruction to an instruction at offset 14. In such a case, the straight-line path from 10-20 may be broken into a straight-line path from 10-13 and 14-20, and the original straight-line path becomes two consecutive straight-line paths, even though there is no branch in the middle. An artificial node to reflect that there is an external jump into the middle of the straight-line path may be effectively created in this manner. Then, in 518, the code analyzer performing the process 500 determines whether it has reached the last instruction of the program instructions. If more instructions in the program instructions remain to be analyzed, the code analyzer performing the process 500 returns to 506, whereupon the code analyzer retrieves the next instruction , i.e. second implementation instance, of the program instructions and col 22, lines 25-36 the operations performed in 810-16 and 824-28 may be replaced with operations that, for each policy violation, insert hard constraints directly into the original program instructions, except for code portions annotated as critical, in order to produce the remediated instructions ).
As per claim 13. Ross and Allen and Van Riel discloses The computer-implemented method of claim 1, Ross discloses wherein the first RBAC policy belongs to a set of RBAC policies maintained by a cloud computing system (col 12, lines 5-15the security policy can be deployed to the computing environment (e.g., computing environment 100 in FIG. 1). For example, cloud drivers 250.sub.1-250.sub.Z can produce requests, instructions, commands, and the like which are suitable for and accepted by cloud services 260.sub.1-260.sub.Z (respectively) to implement the security policy in the computing environments hosted by cloud services 260.sub.1-260.sub.Z (respectively). ).
As per claim 14, this claim is rejected based on the rational set forth in the claim 1.
As per claim 15. Ross and Allen and Van Riel discloses The computer-implemented method of claim 14, Ross discloses wherein determining whether the first RBAC policy is consistently implemented includes comparing a first output of the first implementation instance that applies the first input with a second output from the second implementation instance that applies the first input (col 2, lines 29-40 The metadata may include network logs of the user access events into the applications or other user activity conducted on client devices. The metadata may include telemetry data concerning access operations, time of day, a client device used, or an amount of data written to or read from the applications. The metadata may also include data from identity stores which the system can utilize to organize information into a consumable form. The metadata may also include Role Based Access Control (RBAC) rules and permissions associated with users and groups of users to understand the access currently allowed from the users to the applications ).
As per claim 16. Ross and Allen and Van Riel discloses The computer-implemented method of claim 15, Ross discloses further comprising determining the first RBAC policy is not consistently implemented based on the first output of the first implementation instance differing from the second output from the second implementation instance (col 17, lines 44-55 The metadata discovered about user access behavior may include network logs of the user access events into the applications or other user activity conducted on client devices. The metadata may include telemetry data concerning access operations, time of day, a client device used or an amount of data written to or read from the applications. The metadata may also include data from an identity store utilized by the system to organize information into a consumable form around organization units, groups, and roles).
As per claim 17. Ross and Allen and Van Riel discloses The computer-implemented method of claim 15, Ross discloses further comprising determining the first RBAC policy is consistently implemented based, at least in part, on the first output of the first implementation instance matching the second output from the second implementation instance ( col 2, lines 29-40 The metadata may include network logs of the user access events into the applications or other user activity conducted on client devices. The metadata may include telemetry data concerning access operations, time of day, a client device used, or an amount of data written to or read from the applications. The metadata may also include data from identity stores which the system can utilize to organize information into a consumable form. The metadata may also include Role Based Access Control (RBAC) rules and permissions associated with users and groups of users to understand the access currently allowed from the users to the applications).
As per claim 18. Ross and Allen and Van Riel discloses The computer-implemented method of claim 17, Ross disclose further comprising determining the first RBAC policy is consistently implemented based on outputs matching across all inputs between implementation instances in the first programming language and the second programming language for each execution path in the abstract policy model of the first RBAC policy (col 17, lines 44-55 The metadata discovered about user access behavior may include network logs of the user access events into the applications or other user activity conducted on client devices. The metadata may include telemetry data concerning access operations, time of day, a client device used or an amount of data written to or read from the applications. The metadata may also include data from an identity store utilized by the system to organize information into a consumable form around organization units, groups, and roles. The metadata may also include the RBAC rules and permissions associated with the users and groups of users to understand the access to the applications currently allowed for the users).
As per claim 16, this claim is rejected based on the same rational set forth in the claim 1.
As per claim 20. Ross and Allen and Van Riel discloses The system of claim 19, Ross discloses wherein the satisfiability solver model is a satisfiability modulo theory (SMT) solver (col 17, lines 57-62 The controller 210 can analyze metadata, i.e. a satisfiability solver model, to determine the access behavior of users within different organizational units defined within the identity store. This access behavior can be compared against policies that are defined around organizational access permissions to ensure that corporate policies are not breached).
Claim(s) 12 is rejected under 35 U.S.C. 103 as being unpatentable over Ross et al US 11,711374 in view of Allen US 10,419,483 and Van Riel in view of Yeh et al US 7,546,226.
As per claim 12. Ross and Allen and Van Riel discloses the computer-implemented method of claim 1, Ross discloses wherein the first programming language is C++ (col 14, lines 35-42 Ross and Allen) and the second programming language is C#.
The combination fails to disclose input by the second programming language is C# .
However, Yeh disclose input by the second programming language is C# (col 13, lines 59-60 the user input query 520 in the C-Sharp programming language.).
Ross and Allen and Van Riel and Yeh are both considered to be analogous to the claimed invention because they are in the same field of analyzing the policy.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Ross to incorporate the teachings of Alllen, including the teaching of Van Riel including the teaching of Yeh and provide the execution flows.
Doing so would provide the policy analyzer may have determined from the policy that the program instructions, thereby increasing to determine that a hard constraint of ten iterations of the loop may be permitted without violating policies corresponding to the program instructions.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABU S SHOLEMAN whose telephone number is (571)270-7314. The examiner can normally be reached EST: 9am-5pm.
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, JORGE ORTIZ CRIADO can be reached at 571-272-7624. 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.
/ABU S SHOLEMAN/Primary Examiner, Art Unit 2496
Prosecution Insights