FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003
COMPLETE SPECIFICATION (See Section 10 and Rule 13)
Title of invention: METHOD AND SYSTEM FOR LEARNING BASED ACCESS CONTROL
Applicant:
Tata Consultancy Services Limited
A company Incorporated in India under the Companies Act, 1956
Having address:
Nirmal Building, 9th floor,
Nariman point, Mumbai 400021,
Maharashtra, India
Preamble to the description
The following specification particularly describes the invention and the manner in which it is to be performed.

TECHNICAL FIELD [001] The disclosure herein generally relates to field of information security, and, more particularly, to a method and a system for regulating access of one or more computer related resources.
BACKGROUND [002] An access control system approves or denies users’ request to access information from various computer related resources. Networked computer systems have evolved over the years from simple serially connected computer systems to massively networked computer systems connected via large internal networks, intranets, and the internet. During this evolution, many different models were developed to control user’s access to electronic information stored in the computer systems. Due to the pervasive nature of information sharing in a distributed environment, how a computer system determines if a user or an application has permission to access information (such as a file) has been a complex problem to solve.
[003] In the existing access control models authorization policies contain rules that specifies under what circumstances an access should be allowed or denied. This often requires significant effort to manage policies such as policy creation, association, evaluation, and policy conflicts. Policies are evaluated for every access request in spite of constant user, resource, and policy contexts. Over the years, due to changes in access control characteristics, access rules are no longer user-centric based only on user information. They are based on various other parameters such as attributes, roles, relationships. Whenever an access request comes there can be three scenarios possible. 1) user context changed since last access 2) policy context changed since last access 3) Resource context changed since last access. To check these scenarios, policy evaluation is done every time for an access attempt. This requires significant time, system resources and more administrative effort. Access request evaluation may not be required in case of repeated, similar access requests where user, resource and policy contexts are

constant since last access. In some scenarios where access decision depends mutable attributes requires continuous policy evaluation. However, current access control models do not consider these aspects and continue to evaluate every access request which is inefficient, especially for large systems.
SUMMARY [004] Embodiments of the present disclosure present technological improvements as solutions to one or more of the above-mentioned technical problems recognized by the inventors in conventional systems. For example, in one embodiment, an access control system and method for regulating access of one or more computer related resources is provided. The system includes an input/output interface for receiving at least one access request from a user to access one or more resources. Herein, the at least one access request comprises information of a user identifier and one or more attributes of the user, a resource identifier and one or more attributes of the resources, context of at least one action, and context of an environment. Further, the access control system includes one or more hardware processors and at least one memory in communication with the one or more hardware processors, wherein the one or more hardware processors are configured to execute programmed instructions stored in the memory.
[005] Herein, the access control system is configured to preprocess and transform the information received for the at least one access request based on predefined templates. It is to be noted that the predefined templates comprising user context, resource context, and attributes of an action context. Further, the access control system is configured to compare context of the received at least one access request with a preceding access request and that is stored in a learning module. The context comparison includes comparing one or more attributes of the user earlier and present and context of present authorization with context of preceding authorization. Furthermore, the access control system is configured to determine change in the policy context based on result of the context comparison of present policy for authorization with context of preceding policy for authorization. An

evaluation module of the access control system evaluates an authorization decision based on result of the context comparison. Wherein, context comparison is not found, a policy engine is invoked to evaluate the present policy based on the result of determination module. Finally, based on the results of the policy engine the access control system regulates access of one or more resources.
[006] In another aspect, a method for regulating access of one or more computer related resources is provided. The method includes receiving at least one access request from a user to access one or more resources. The at least one access request comprises information of a user identifier and one or more attributes of the user, a resource identifier and one or more attributes of the resource, context of at least one action, and context of an environment. At the next step, the received information is transformed based on at least one predefined template. The at least one predefined template comprising one or more attributes of a user context, one or more attributes of a resource context, and one or more attributes of an action context. Further, the method includes comparing context of the received at least one access request with at least one preceding completed access, that is stored in the learning module of the access control system. Herein, the context comparison includes comparing one or more attributes of the user earlier and present, one or more attributes of the resource earlier and present, and comparing context of a present policy for authorization with context of preceding policy for authorization.
[007] Furthermore, the method includes determining change in the policy context based on results of the context comparison of present policy with context of preceding policy. Herein, the comparison of policy context associated with matched preceding access request and current policy context associated with the one or more resources to be accessed by the user. An authorization decision is determined using a determination module based on results of the context comparison. It is to be noted that the determination module may redirect the access request to a policy engine based on categorization of the policy. And, the policy

engine evaluates the policy based on directions from the determination module to regulate access of one or more resources.
[008] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.
BRIEF DESCRIPTION OF THE DRAWINGS [009] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles:
[010] FIG. 1 illustrates a block diagram of a system for regulating access of one or more computer related resources, according to some embodiments of the present disclosure.
[011] FIG. 2 is a functional block diagram to illustrate system for regulating access of one or more computer related resources, according to some embodiments of the present disclosure.
[012] FIG. 3 shows a functional flow diagram of the system to illustrate a learning-based access control flow of the system, according to some embodiments of the present disclosure.
[013] FIG. 4 shows a flow diagram to illustrate context preparation from the information received in access request, according to some embodiments of the present disclosure.
[014] FIG. 5(a) & (b) shows flow charts to illustrate learning flow of the access control system, according to some embodiments of the present disclosure.
[015] FIG. 6 to illustrate policy management of the access control system, according to some embodiments of the present disclosure.

[016] FIG. 7 shows a functional flow diagram to illustrate policy evaluation of the access control system, according to some embodiments of the present disclosure.
[017] FIG. 8 illustrates a functional flow diagram for policy categorization of the access control system, according to some embodiments of the present disclosure.
[018] FIG. 9 illustrates a flowchart of a method for regulating access of one or more computer related resources, according to some embodiments of the present disclosure.
[019] FIG. 10 shows a functional flow diagram of a method for learning based access control, according to some embodiments of the present disclosure.
DETAILED DESCRIPTION OF EMBODIMENTS [020] Exemplary embodiments are described with reference to the accompanying drawings. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. Wherever convenient, the same reference numbers are used throughout the drawings to refer to the same or like parts. While examples and features of disclosed principles are described herein, modifications, adaptations, and other implementations are possible without departing from the scope of the disclosed embodiments. It is intended that the following detailed description be considered as exemplary only, with the true scope being indicated by the following claims.
[021] Referring now to the drawings, and more particularly to FIG. 1 through FIG. 10, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments and these embodiments are described in the context of the following exemplary system and/or method.

[022] FIG. 1 illustrates a block diagram of an access control system 100 for regulating access of one or more computer related resources, in accordance with an example embodiment. Although the present disclosure is explained considering that the access control system 100 is implemented on a server, it may be understood that the access control system 100 may comprises one or more computing devices 102, such as a laptop computer, a desktop computer, a notebook, a workstation, a cloud-based computing environment and the like. It will be understood that the system 100 may be accessed through one or more input/output interfaces 104-1, 104-2... 104-N, collectively referred to as I/O interface 104. Examples of the I/O interface 104 may include, but are not limited to, a user interface, a portable computer, a personal digital assistant, a handheld device, a smartphone, a tablet computer, a workstation, and the like. The I/O interface 104 are communicatively coupled to the access control system 100 through a network 106.
[023] In an embodiment, the network 106 may be a wireless or a wired network, or a combination thereof. In an example, the network 106 can be implemented as a computer network, as one of the different types of networks, such as virtual private network (VPN), intranet, local area network (LAN), wide area network (WAN), the internet, and such. The network 106 may either be a dedicated network or a shared network, which represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), and Wireless Application Protocol (WAP), to communicate with each other. Further, the network 106 may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices. The network devices within the network 106 may interact with the system 100 through communication links.
[024] The access control system 100 may be implemented in a workstation, a server, and a network server. In an embodiment, the computing device 102 further comprises one or more hardware processors 108, one or more

memory 110, hereinafter referred as a memory 110 and a data repository 112, for example, a repository 112. The memory 110 is in communication with the one or more hardware processors 108, wherein the one or more hardware processors 108 are configured to execute programmed instructions stored in the memory 110, to perform various functions as explained in the later part of the disclosure. The repository 112 may store data processed, received, and generated by the access control system 100.
[025] The access control system 100 supports various connectivity options such as BLUETOOTH®, USB, ZigBee and other cellular services. The network environment enables connection of various components of the system 100 using any communication link including Internet, WAN, MAN, and so on. In an exemplary embodiment, the access control system 100 is implemented to operate as a stand-alone device. In another embodiment, the access control system 100 may be implemented to work as a loosely coupled device to a smart computing environment. The components and functionalities of the access control system 100 are described further in detail.
[026] In the preferred embodiment, the access control system 100 is configured for regulating access of one or more computer related resources as shown in block diagram of FIG. 1. The access control system 100 comprises a learning module 114 which is configured to learn preceding access control aspects such as preceding access policy evaluation results, preceding access denials, access requests using the user, and the policy datasets as shown in FIG. 2.
[027] FIG. 3 illustrates flow of learning based access control system, to determine an authorization decision based on context comparison and policy evaluation by a policy engine for regulating access of one or more computer related resources. The access control system 100 receives the information from the input/output interface and preprocesses and transform based on at least one predefined template. Further, the access control system 100 includes an interceptor

module 118, a context preparator module 120, a context comparator module 122, a determination module 124, and a policy engine 126.
[028] According to an embodiment of the disclosure, the input/output interface 104 is configured to receive at least one access request from a user to access one or more computer related resources. The at least one access request may comprise, but not limited to, information of a user identifier and one or more attributes of the user, a resource identifier and one or more attributes of the resources, context of at least one action, and context of an environment.
[029] Referring FIG. 2, a functional flow diagram 200 of the system 100, to illustrate the learning module 114 of the system 100. Herein, the interceptor module 118 intercepts the user access request to determine whether similar preceding access request exists in the learning module 114. Wherein if the preceding access request exists, the access control system 100 is configured to determine whether the user context or context of one or more resources is changed from the stored preceding access request. If there is no preceding access exist in the learning module 114, the access control system 100 is configured to determine any access request exist for at least one resource irrespective of the user.
[030] In one embodiment, wherein the access control system receives an access request in the form of user (U), Resource (R), Action (A). The access control system gets user context (Name, Attributes), resource context (Name, Attributes), action context, and environmental context (Date, Time, Location). The access control system searches for preceding access requests (U, R, A) in the learning module 114 and corresponding a decision to allow user to access or deny the user access request. It is to be noted that the context of preceding access requests in the learning module 114 on which decision was made is compared with the current access request from the user. There may be two scenarios, one of them is if the context matches, the access control system 100 gets the decision and enforces the decision. In another scenario, wherein either context of the user or the context of

the resource is changed since the preceding access request for one or more computer related resources.
[031] In another embodiment, wherein a new policy is added or there were some changes made to the existing policy with respect to the one or more computer related resources. Herein, a policy evaluator of the access control system will pick the new/changed policies, collect the access requests for the resource associated with the policy from the learning module 114. The access requests are selected based on the resource identifier grouped by user identifier and action. The policy evaluator selects the access request with maximum number of occurrences of the user identifier and action for the resource associated with the policy and send the access request to the context preparator module 120. The context preparator module 120 transforms the current access request according to the pre-defined templates and send it back to the policy evaluator. The Policy evaluator sends the transformed access request to the policy engine 126 for policy evaluation. Policy evaluation is performed for all the access requests and each access request, user, resource, action, policy, and evaluation context details are stored in the learning module 114 with policy_context_changed is marked to indicate change in the existing policy. In case no access request found in the learning module 114, policy evaluation is performed and only authorization policy context and policy evaluation context are stored in the learning module 114.
[032] In yet another embodiment, wherein if the context of the policy is
not changed, when context of the preceding policy is compared with the created or
modified policy, apply the preceding decision of the access control, and record the
present access request, the user context, the resource context and the policy context.
If the context of the policy is changed then the access control system 100 is
configured to evaluate the policy based on the current user, resource, action,
environment context attributes. The policy engine 126 evaluates rules with the help
of current user, resource, action, environment attributes. The
Policy_context_change indicates change in the policy since the last evaluation

based on this the determination module 124 directs the access request to the policy engine 126 for evaluation.
[033] In one example, wherein a user access request is received to access one or more computer related resources. The access request comprises context of a user, context of resource to be accessed and context of an action to be performed. Herein. The user context includes user role as a scientist of an organization, and project of the user is research and innovation group of the organization. Further, the resource context of the access request comprises name of a confidential document and author of the confidential document. The action context of the access request is to view the confidential document.
[034] Referring FIG. 3, a functional block diagram 300 to illustrate a learning-based access control for regulating access of one or more computer related resources. Wherein, when a user attempts to access a resource, the user sends access request to the access control system. An interceptor module 118 of the access control system intercepts the access request and forwards it to a context preparator module. It would be appreciated that the interceptor module 118 ensures required details of the access request for further processing. The access request contains user details, resource details, action details and environment details. The user details comprise user identifier, resource details comprise resource identifier, action details comprise action performed, and environment details comprise date, time, user machine, location, and any other details. The context preparator module 120 transforms the access request according to the predefined templates. In one scenario, user template may have attributes in the form of attribute key value pairs (Key= “Designation”, Value= “Consultant”) including custom attributes with associated predefined procedures for calculation. For example, custom attribute age associated with method {age_calculator}. Herein, the age_calculator is invoked to calculate age of the user and populates the value as (Key= “Age”, Value= “calculated value”. This way context preparator module transforms access request

to that format that can be understood by a context comparator module 122. The transformed access request is forwarded to the context comparator module 122.
[035] The context comparator module 122 checks whether preceding access requests exists for the user, resource, action in request in the learning module 114. If access request exists in the learning module 114, the context comparator module 122 checks whether user or resource context changed. This is done by comparing current user context with the user context of matched preceding access request, current resource context with the resource context of the matched preceding access request. Further, the context comparator module 122 checks policy context is changed since the matched historical access request evaluation (Figure 5a). The determination module 124 determines the authorization decision based on context comparison and policy evaluation indicator. If contexts are not changed and policy evaluation indicator is marked “No” then it gets the evaluation result for the matched access request and send it back to the application. Otherwise, the determination module 124 redirects the access request to a policy engine 126 for policy evaluation. In case preceding access requests are not found in the learning module 114 for the user, resource, action of current access request, the context comparator module 122 performs partial search for access requests with resource, and action. If it finds access request, it compares user contexts, resource contexts, policy contexts and determination module 124 determines an authorization decision based on context comparison and policy evaluation indicator. After the authorization decision, the access request, user, resource, access, policy, evaluation contexts are stored in the learning module 114.
[036] Referring FIG. 4, a flow diagram 400, to illustrate a context preparation from the information received from the user. The received information is transformed into a form based on predefined template using a context preparator module 120. The context preparation is transforming the access request, received from the application, to a predefined format that is understood by the context comparator module 122. The context preparation is done based on the predefined

templates comprises of user, resource, action attributes, custom attributes that require calculations using methods, for each method an indicator that indicates real time evaluation required. Usually access request is received with minimal details. However, policy evaluation may require details of additional attributes. The predefined template defines all attributes that are required for policy evaluation and context comparison. The policy also uses attributes from the pre-defined templates. The transformation process comprises, collecting attributes from templates, appending collected attributes to the access request. Collecting attributes is preceded by calculation of custom attributes, fetching attribute values for fixed attributes. Example for custom attributes include age, city, weekday and so on. These custom attributes are associated with pre-defined methods. Example for fixed attributes are project, designation, role etc. Once all attributes are collected, they are appended to access request in the form of user context, resource context, action context. In one example, wherein

[037] Referring FIG. 5(a) & 5(b) (collectively referred to as FIG. 5), a flow chart 500, to illustrate learning flow of the access control system. Wherein, Fig 5(a) illustrates context comparison part of the learning flow. The context comparator module 122 receives transformed access request from the context preparator module 120. The context comparator module 122 checks for any preceding access requests exist for the user, resource, action of present access request. If no access request exists, then it checks for access requests for the resource, action of present access request. If access request found for the first scenario, it compares user context of the matched preceding access request with the user context of the present access request. The user context comparison process

comprises a step of getting user attributes in the user context of matched access request.
[038] It would be User context is of the form {Attribute1= “Value”, Attribute2= “value”, Attribute3= “Value” …. AttributeN= “value”}. Each attribute key value pair is compared with the user context of the present access request by using a procedure compare_user_context (user_context_or_comparison). The user_ context_for_comparison will have user context associated with matched preceding access request in the form {Attribute1= “Value”, Attribute2= “value”, Attribute3= “Value” …. Attribute N= “value”}. The procedure returns “Match” in case all attributes matches, otherwise “change”. The process is followed for resource comparison also. For the scenarios where access requests found for resource, action criteria, it will get recent user contexts of the matched access requests, same process is followed for user, resource context comparison.
[039] FIG. 5(a) further illustrates policy context change. The policy
context change check process gets the policy context of the matched preceding
access request by referring policy _ evaluation _context and policy_context
associated with the matched access request. Then, it checks, any policy context
exists for the resource after the matched access request with
policy_context_indicator marked “Yes”. If it finds then policy context is changed, otherwise, policy is not changed since previous evaluation.
[040] Figure 5(b) further illustrates access context and evaluation context storage in the learning module 114. This process is performed for two scenarios 1) Access request comparison 2) policy evaluation. When access request is compared, the determination module 124 determines authorization decision based on the context change and policy_context_change indicator. In case user, resource, policy context is not changed and policy_ evaluation_ indicator is marked “No” then evaluation result of the matched access request is considered. In this scenario, the access request context, the access context, the user context, resource context of

present access request, and policy context, policy evaluation context of matched preceding access request are stored in the learning module 114.
[041] Furthermore, wherein the context is changed then the determination module 124 directs the present access request to the policy engine 126 for evaluation. In this scenario, after evaluation, the access request context, the access context, the user context, resource context of present access request, and policy context, policy evaluation context of policy evaluation are stored in the learning module 114. For the second scenario wherein policy evaluator executes in case of policy creation/modification, there can be two scenarios possible. First scenario is access requests found for the policy in the learning module 114, wherein complete policy evaluation is performed and the access request context, the access context, the user context, resource context of the existing access request, and policy context, policy evaluation context of policy evaluation are stored with policy_ context_ change indicator marked “Yes”. In second scenario wherein existing access requests not found then the policy evaluation is performed and only policy context and policy evaluation context are stored with policy_ context _ change indicator marked “Yes”.
[042] Referring FIG. 6, a flow chart 600, to illustrate policy management of the access control system 100. Policy management consists of policy creation/existing policy modification. It is to be noted that an administrator creates or modifies policies to control access on resources. The policy is created based on predefined templates comprises of user, resource, action attributes. As part of policy, the administrator specifies target which indicates the policy applicability to a resource and rules. Rules may also contain target that indicates applicability. Rule also contains conditions based on user, resource, action attributes, and also custom procedures based on attributes.
[043] Referring FIG. 7, a functional flow diagram 700 to illustrate policy evaluation of the access control system 100. The policy evaluation is performed by a policy engine 126 of the access control system 100 to arrive at the authorization

decision for an access request. The policy evaluation takes input access request, checks applicability of policy to the access request and evaluates all rule conditions with user, resource, access attributes of the access request. For example, in the policy the rule condition says designation either “XXX” or ‘YYY”. It gets value for designation attribute from the user context and compares it with designation value in the rule condition. If it matches, rule effect will be the authorization decision “Allow’ or ‘Deny”. Once the policy evaluation is done, the determination module 124 component informs the authorization decision to the application.
[044] Referring FIG. 8, a functional flow diagram 800 to illustrate policy categorization of the access control system 100. The Policy categorization indicates whether policy needs to be evaluated every time or not. In some scenarios, access request needs to be evaluated every time when it consists of conditions that involve methods based on certain attributes which contain range of values. For example, for time-based access if a resource needs to be controlled for specific time allow access to a resource between 9AM to 6 PM. This scenario requires policy evaluation every time because access request time may vary for each access request. Decision from the security learning system would not be accurate in this scenario. For this reason, when policy is created/or modified, the access control system sets policy_ evaluation_ indicator to ‘Yes’ or “No” based on the procedures used in the policy. The procedures used are from templates and are associated with real-time evaluation indicator is set to Yes or No. Based on the real-time indicator, it categorizes the policy.
[045] Referring FIG. 9, illustrates a processor-implemented method 900 for regulating access of one or more computer related resources. The method 900 comprises one or more steps as follows.
[046] In the preferred embodiment, at the step 902 receiving at least one access request from a user to access one or more resources. The at least one access request comprises information of a user identifier and one or more attributes of the

user, a resource identifier and one or more attributes of the resources, context of at least one action, and context of an environment.
[047] In the preferred embodiment, at the step 904 transforming the information received for the at least one access request based on at least one predefined template. Wherein, the at least one predefined template comprising user context, resource context, and action context attributes.
[048] In the preferred embodiment, at the step 906 comparing context of
the received at least one access request with at least one preceding completed access that is stored in the learning module 114. It would be appreciated that the context comparison includes comparing one or more attributes of the user earlier and present, one or more attributes of the resource earlier and present, and context of present policy with context of preceding policy.
[049] In the preferred embodiment, at the step 908 determining change in the policy context based on result of the context comparison of present policy with context of preceding policy for authorization. The policy context comparison is associated with matched preceding access requests and present policy context associated with the one or more resources.
[050] In the preferred embodiment, at the step 910 determining an authorization decision using a determination module 124 based on result of the context comparison.
[051] In the preferred embodiment, at the step 912 evaluating the policy using a policy engine 126 based on the direction from the determination module 124 to regulate access of one or more resources.
[052] Referring FIG. 10, a flow diagram 1000, to illustrate a functional flow for regulating access of one or more computer related resources. When the user, resource, and policy context remain same for an access request, the access control system 100 gets authorization decision from the previous evaluation results.

For an access request, if current user or resource or policy context not matches with previous evaluation context then the access control system 100 invokes a policy engine 126 for determining the authorization decision.
[053] The written description describes the subject matter herein to enable any person skilled in the art to make and use the embodiments. The scope of the subject matter embodiments is defined by the claims and may include other modifications that occur to those skilled in the art. Such other modifications are intended to be within the scope of the claims if they have similar elements that do not differ from the literal language of the claims or if they include equivalent elements with insubstantial differences from the literal language of the claims.
[054] The embodiments of present disclosure herein address unresolved problem of regulating access of one or more computer related resources whenever an access request comes, policy evaluation is done every time for an access attempt. This requires significant time, system resources and more administrative effort. The disclosure proposes a learning-based access control system and method which arrives at access decision based on previous and current policy evaluations. When the user, resource, and policy context remain same for an access request, the access control system gets authorization decision from the previous evaluation results. For an access request, if current user or resource or policy context not matches with previous evaluation context then the access control system invokes a policy engine 126 for determining the authorization decision.
[055] It is to be understood that the scope of the protection is extended to such a program and in addition to a computer-readable means having a message therein; such computer-readable storage means contain program-code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The hardware device can be any kind of device which can be programmed including e.g. any kind of computer like a server or a personal computer, or the like, or any combination

thereof. The device may also include means which could be e.g. hardware means like e.g. an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a combination of hardware and software means, e.g. an ASIC and an FPGA, or at least one microprocessor and at least one memory with software processing components located therein. Thus, the means can include each hardware means, and software means. The method embodiments described herein could be implemented in hardware and software. The device may also include software means. Alternatively, the embodiments may be implemented on different hardware devices, e.g. using a plurality of CPUs.
[056] The embodiments herein can comprise hardware and software elements. The embodiments that are implemented in software include but are not limited to, firmware, resident software, microcode, etc. The functions performed by various components described herein may be implemented in other components or combinations of other components. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can comprise, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
[057] The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope of the disclosed embodiments. Also, the words “comprising,” “having,” “containing,” and “including,” and other similar forms are

intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise.
[058] Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., be non-transitory. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, nonvolatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, and any other known physical storage media.
[059] It is intended that the disclosure and examples be considered as exemplary only, with a true scope of disclosed embodiments being indicated by the following claims.

WE CLAIM:
1. A processor-implemented method for regulating access of one or more computer related resources, wherein the processor-implemented method comprising:
receiving, via one or more hardware processors, at least one access request from a user to access the one or more computer related resources, wherein the at least one access request comprises information of the user identifier and one or more attributes of the user, a resource identifier and one or more attributes of the resources, context of at least one action, and context of an environment;
transforming, via the one or more hardware processors, the information received for the at least one access request based on at least one predefined template, wherein the at least one predefined template comprising the user context, the resource context and the action context attributes;
comparing, via the one or more hardware processors, context of the received at least one access request with context of a preceding completed access stored in a learning module, wherein the context comparison includes:
comparing one or more attributes of the user of received access request with one or more attributes of a user of preceding completed access;
comparing one or more attributes of the resource of received access request with one or more attributes of the resource of preceding completed access; and
comparing context of present policy for authorization with context of preceding policy for authorization; identifying, via the one or more hardware processors, at least one change in the context of preceding policy based on results of the context

comparison of the present policy with the context of the preceding policy to
categorize the present policy; and
determining, via one or more hardware processors, an authorization
decision to regulate access of one or more computer related resources:
based on results of the context comparison of the received at least one access request and the categorization of policy; and further evaluate the policy using a policy engine if at least one change is identified in the policy.
2. The method claimed in claim 1, wherein the context preparation includes one or more attribute values of current user, one or more resources to be accessed, and at least one action to be performed on the accessed resource based on the predefined template.
3. The method claimed in claim 1, wherein context comparison includes access request comparison for a match with user identifier, resource identifier and action.
4. The method claimed in claim 1, wherein change in policy includes marking of policy for every time evaluation based on the indicator in the template against procedures used in the policy.
5. The method claimed in claim 1, wherein new policy creation and modification in the existing policy are preceded by creation of user templates, resource templates, and action templates, wherein templates comprises attributes, custom attributes, procedure associated with custom attributes, an indicator indicating real-time evaluation required.
6. The method claimed in claim 1, wherein the categorization of policy evaluation details for storage is based on user access attempts, resource wise access attempts in terms of access request context, access context, user context, resource context, a policy context, and an evaluation context.

7. The method claimed in claim 1, wherein the comparison of policy context associated with matched access request and current policy context associated with the one or more computer related resources.
8. An access control system for regulating access of one or more resources, wherein the access control system comprising:
an input/output interface for receiving at least one access request from a user to access one or more resources, wherein the at least one access request comprises information of a user identifier and one or more attributes of the user, a resource identifier and one or more attributes of the resources, context of at least one action, and context of an environment; one or more hardware processors;
at least one memory in communication with the one or more hardware processors, wherein the one or more hardware processors are configured to execute programmed instructions stored in the memory to:
transform the information received for the at least one access request based on at least one predefined template, wherein the at least one predefined template comprising the user context, the resource context and the action context attributes;
compare context of the received at least one access request with context of a preceding completed access stored in a learning module, wherein the context comparison includes:
comparing one or more attributes of the user of received
access request with one or more attributes of a user of
preceding completed access;
comparing one or more attributes of the resource of received
access request with one or more attributes of the resource of
preceding completed access; and
comparing context of present policy for authorization with
context of preceding policy for authorization;

identify change in the policy context based on result of the context comparison of the present policy with the context of the preceding policy to categorize the policy, wherein the comparison of policy context associated with matched access request and current policy context associated with the one or more resources; and
determine an authorization decision to regulate access of one or more computer related resources based on:
result of the context comparison of the received at least one access request and the categorization of policy; and further evaluate the policy via a policy engine, if at least one change is identified in the policy.