Claims:We Claim:
1. A processor implemented method, comprising:
receiving, by an access policy creation and management system (APCMS) via one or more hardware processors, an access policy requirement document, the access policy requirement document comprising a policy statement in a natural language (402);
identifying, by the APCMS via the one or more hardware processors, an entity type and an entity value of one or more entities present in the policy statement using an entity tagger (404);
generating, by the APCMS via the one or more hardware processors, a link tree based on the identified entity type and the entity value of the one or more entities (406);
identifying, by the APCMS via the one or more hardware processors, one or more target entities in the link tree based on a predefined target entity identification criterion (408);
determining, by the APCMS via the one or more hardware processors, whether a policy name is present in the policy statement by performing a string matching between the policy statement and a plurality of policy names using a string matching algorithm, wherein the plurality of policy names are accessed from a policy database (410);
upon determining that the policy name is not present in the policy statement, determining, by the APCMS via the one or more hardware processors, one or more relationships of type policy that are present between the one or more identified target entities by accessing information about the one or more identified target entities from a knowledge graph (412);
extracting, by the APCMS via the one or more hardware processors, one or more matching policy names based on the one or more determined relationships using the plurality of policy names, wherein the one or more matching policy names are added in a matching policy set created and comprised in the policy database, for the policy statement (414);
accessing, by the APCMS via the one or more hardware processors, a policy metadata and a policy link tree associated with each matching policy name present in the matching policy set from the policy database (416);
comparing, by the APCMS via the one or more hardware processors, the generated link tree with the policy link tree associated each matching policy name to identify a policy scenario (418);
creating, by the APCMS via the one or more hardware processors, a policy metadata associated with a policy based on the identified policy scenario, wherein the policy is one of: a new policy, and an existing policy (420); and
storing, by the APCMS via the one or more hardware processors, the policy metadata associated with the policy in the policy database (422).

2. The processor implemented method of claim 1, wherein the step of generating, by the APCMS via the one or more hardware processors, the link tree based on the identified entity type and the entity value of the one or more entities comprises:
generating, by the APCMS via the one or more hardware processors, a parse tree based on the identified entity type and the entity value of the one or more entities using a dependency parser, the parse tree comprising a plurality of parse tree nodes, wherein each parse tree node of the plurality of parse tree nodes comprises a tag, wherein the tag is a relevant tag, or an irrelevant tag, and wherein the relevant tag comprises one of: a method tag, an entity tag, and an operation tag;
identifying, by the APCMS via the one or more hardware processors, one or more parse tree nodes of the plurality of parse tree nodes that has the method tag or the operation tag;
converting, by the APCMS via the one or more hardware processors, the identified one or more parse tree nodes into one or more edges, wherein the one or more converted edges are provided with a label depending on the relevant tag;
adding, by the APCMS via the one or more hardware processors, each edge of the one or more edges to a parent node of the respective parse tree node;
identifying, by the APCMS via the one or more hardware processors, at least one parse tree node in the plurality of parse tree nodes that is presented as an attribute in the knowledge graph;
converting, by the APCMS via the one or more hardware processors, the at least one parse tree node into an attribute of a parent node of the least one parse tree node; and
removing, by the APCMS via the one or more hardware processors, one or more parse tree nodes that comprise the irrelevant tags to obtain the link tree.

3. The processor implemented method of claim 1, wherein the policy scenario is one of: a new policy creation, an existing policy updation, and an existing policy based new policy creation.

4. The processor implemented method of claim 3, wherein the policy scenario is the new policy creation in case the generated link tree is not matching with the policy link tree associated with each matching policy name present in the matching policy set, wherein the policy scenario is the existing policy updation in case the generated link tree is a subtree of the policy link tree associated with a matching policy name present in the matching policy set, and wherein the policy scenario is the existing policy based new policy creation in case the generated link tree is one of: the subtree of the policy link tree associated with the matching policy name present in the matching policy set and a superset of the policy link tree associated with the matching policy name present in the matching policy set.

5. The processor implemented method of claim 4, further comprising:
upon identifying that the policy scenario is the new policy creation, performing:
identifying, by the APCMS via the one or more hardware processors, a top level node of the generated link tree as a policy target attribute;
identifying, by the APCMS via the one or more hardware processors, one or more sub-level nodes of the generated link tree as one or more policy rules of the policy;
converting, by the APCMS via the one or more hardware processors, the generated link tree into an output tree based on the identified target attribute and the one or more policy rules; and
creating, by the APCMS via the one or more hardware processors, the policy metadata based on the output tree.

6. The processor implemented method of claim 4, further comprising:
upon identifying that the policy scenario is the existing policy updation, performing:
determining, by the APCMS via the one or more hardware processors, one or more differences between the generated link tree and the policy link tree associated with the matching policy name present in the matching policy set, the one or more differences comprising one or more of: differences in (i) one or more policy rules, (ii) one or more policy attributes, and (iii) one or more policy methods;
updating, by the APCMS via the one or more hardware processors, the generated link tree based on the one or more differences to obtain an output tree; and
updating, by the APCMS via the one or more hardware processors, the policy metadata based on the output tree.

7. The processor implemented method of claim 4, further comprising:
upon identifying that the policy scenario is the existing policy based new policy creation, performing:
performing, by the APCMS via the one or more hardware processors, copying of one or more policy rules, one or more policy attributes, and one or more policy methods present in the policy link tree associated with the matching policy name present in the matching policy set;
updating, by the APCMS via the one or more hardware processors, the generated link tree based, at least in part, on the copied one or more policy rules, the one or more policy attributes, and the one or more policy methods to obtain an output tree; and
creating, by the APCMS via the one or more hardware processors, the policy metadata based on the output tree.

8. The processor implemented method of claim 1, further comprising:
upon determining that the policy name is present in the policy statement, extracting, by the APCMS via the one or more hardware processors, at least one matching policy name based on the policy name using the plurality of policy names, wherein the at least one matching policy name is added in the matching policy set created for the policy statement;
accessing, by the APCMS via the one or more hardware processors, the policy metadata and the policy link tree associated with each matching policy name present in the matching policy set from the policy database;
comparing, by the APCMS via the one or more hardware processors, the generated link tree with the policy link tree associated with each matching policy name to identify the policy scenario;
updating, by the APCMS via the one or more hardware processors, the link tree based on the identified policy scenario; and
creating, by the APCMS via the one or more hardware processors, the policy metadata based on the updated link tree.

9. An access policy creation and management system (APCMS) (200), comprising:
a memory (202) storing instructions;
one or more communication interfaces (206); and
one or more hardware processors (204) coupled to the memory (202) via the one or more communication interfaces (206), wherein the one or more hardware processors (204) are configured by the instructions to:
receive an access policy requirement document, the access policy requirement document comprising a policy statement in a natural language;
identify an entity type and an entity value of one or more entities present in the policy statement using an entity tagger;
generate a link tree based on the identified entity type and the entity value of the one or more entities;
identify one or more target entities in the link tree based on a predefined target entity identification criterion;
determine whether a policy name is present in the policy statement by performing a string matching between the policy statement and a plurality of policy names using a string matching algorithm, wherein the plurality of policy names are accessed from a policy database;
upon determining that the policy name is not present in the policy statement, determine one or more relationships of type policy that are present between the one or more identified target entities by accessing information about the one or more identified target entities from a knowledge graph;
extract one or more matching policy names based on the one or more determined relationships using the plurality of policy names, wherein the one or more matching policy names are added in a matching policy set created and comprised in the policy database, for the policy statement;
access a policy metadata and a policy link tree associated with each matching policy name present in the matching policy set from the policy database;
compare the generated link tree with the policy link tree associated each matching policy name to identify a policy scenario;
create a policy metadata associated with a policy based on the identified policy scenario, wherein the policy is one of: a new policy, and an existing policy; and
store the policy metadata associated with the policy in the policy database.

10. The system as claimed in claim 9, wherein the step of generating, by the APCMS via the one or more hardware processors, the link tree based on the identified entity type and the entity value of the one or more entities comprises:
generating a parse tree based on the identified entity type and the entity value of the one or more entities using a dependency parser, the parse tree comprising a plurality of parse tree nodes, wherein each parse tree node of the plurality of parse tree nodes comprises a tag, wherein the tag is a relevant tag, or an irrelevant tag, and wherein the relevant tag is one of: a method tag, an entity tag, and an operation tag;
identifying one or more parse tree nodes of the plurality of parse tree nodes that has the method tag or the operation tag;
converting the identified one or more parse tree nodes into one or more edges, wherein the one or more converted edges are provided with a label depending on the relevant tag;
adding each edge of the one or more edges to a parent node of the respective parse tree node;
identifying at least one parse tree node in the plurality of parse tree nodes that is presented as an attribute in the knowledge graph;
converting the at least one parse tree node into an attribute of a parent node of the least one parse tree node; and
removing one or more parse tree nodes that comprise the irrelevant tags to obtain the link tree.

11. The system as claimed in claim 9, wherein the policy scenario is one of: a new policy creation, an existing policy updation, and an existing policy based new policy creation.

12. The system as claimed in claim 11, wherein the policy scenario is the new policy creation in case the generated link tree is not matching with the policy link tree associated with each matching policy name present in the matching policy set, wherein the policy scenario is the existing policy updation in case the generated link tree is a subtree of the policy link tree associated a matching policy name present in the matching policy set, and wherein the policy scenario is the existing policy based new policy creation in case the generated link tree is one of: the subtree of the policy link tree associated with the matching policy name present in the matching policy set; and a superset of the policy link tree associated with the matching policy name present in the matching policy set.

13. The system as claimed in claim 12, wherein the system is further caused to:
upon identifying that the policy scenario is the new policy creation, performing:
identifying a top level node of the generated link tree as a policy target attribute;
identifying one or more sub-level nodes of the generated link tree as one or more policy rules of the policy;
converting the generated link tree into an output tree based on the identified target attribute and the one or more policy rules; and
creating the policy metadata based on the output tree.

14. The system as claimed in claim 12, wherein the system is further caused to:
upon identifying that the policy scenario is the existing policy updation, performing:
determining one or more differences between the generated link tree and the policy link tree associated with the matching policy name present in the matching policy set, the one or more differences comprising one or more of: differences in (i) one or more policy rules, (ii) one or more policy attributes, and (iii) one or more policy methods;
updating the generated link tree based on the one or more differences to obtain an output tree; and
updating the policy metadata based on the output tree.

15. The system as claimed in claim 12, wherein the system is further caused to:
upon identifying that the policy scenario is the existing policy based new policy creation, performing:
performing copying of one or more policy rules, one or more policy attributes, and one or more policy methods present in the policy link tree associated with the matching policy name present in the matching policy set;
updating the generated link tree based, at least in part, on the copied one or more policy rules, the one or more policy attributes, and the one or more policy methods to obtain an output tree; and
creating the policy metadata based on the output tree.

16. The system as claimed in claim 9, wherein the system is further caused to:
upon determining that the policy name is present in the policy statement, extracting at least one matching policy name based on the policy name using the plurality of policy names, wherein the at least one matching policy name is added in the matching policy set created for the policy statement;
accessing the policy metadata and the policy link tree associated with each matching policy name present in the matching policy set from the policy database;
comparing the generated link tree with the policy link tree associated with each matching policy name to identify the policy scenario;
updating the link tree based on the identified policy scenario; and
creating the policy metadata based on the updated link tree.

Dated this 16th Day of March 2022
Tata Consultancy Services Limited
By their Agent & Attorney

(Adheesh Nargolkar)
of Khaitan & Co
Reg No IN-PA-1086 , Description: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 CREATING AND MANAGING ACCESS POLICIES OF AN ENTERPRISE

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 access management, and, more particularly, to a method and a system for creating and managing access policies of an enterprise.

BACKGROUND
[002] Access control systems associated with enterprises are generally managed by administrators. They are responsible for creating and managing access policies, modifying access rules as per the enterprise requirement and managing the access control system. The administrators may either use commands or user interface (UI) based tools for making changes in the access control system. However, this manual process of managing the access control system becomes increasingly difficult when an access policy that needs to be created or modified contains number of rules as the administrator has to go through a lot of fields to generate the accurate access policy.
[003] Further, different process flows may need to be followed by the administrator based on the requested modification that further increases the load of the administrator. Additionally, while generating the access policy, the rules and entities that are to be included in the access policy depends on the understanding of policy requirement by the administrator, that sometimes may also lead to misrepresentation of the entities present in the access policy, misunderstood perspective of the policy requirement and imminent failures in policy processing, which ultimately lead to false access decisions.
[004] Some techniques are available that aid in obtaining access policy statements from a policy document. However, the available techniques cannot aid enterprises in actual management of the access policies as access policy creation may still require involvement of administrators for understanding the policy requirement.

SUMMARY
[005] 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 aspect, there is provided a processor implemented method for creating and managing access policies of an enterprise. The method comprises receiving, by an access policy creation and management system (APCMS) via one or more hardware processors, an access policy requirement document, the access policy requirement document comprising a policy statement in a natural language; identifying, by the APCMS via the one or more hardware processors, an entity type and an entity value of one or more entities present in the policy statement using an entity tagger; generating, by the APCMS via the one or more hardware processors, a link tree based on the identified entity type and the entity value of the one or more entities; identifying, by the APCMS via the one or more hardware processors, one or more target entities in the link tree based on a predefined target entity identification criterion; determining, by the APCMS via the one or more hardware processors, whether a policy name is present in the policy statement by performing a string matching between the policy statement and a plurality of policy names using a string matching algorithm, wherein the plurality of policy names are accessed from a knowledge graph; upon determining that the policy name is not present in the policy statement, determining, by the APCMS via the one or more hardware processors, one or more relationships of type policy that are present between the one or more identified target entities by accessing information about the one or more identified target entities from the knowledge graph; extracting, by the APCMS via the one or more hardware processors, one or more matching policy names based on the one or more determined relationships using the plurality of policy names, wherein the one or more matching policy names are added in a matching policy set created and comprised in a policy database, for the policy statement; accessing, by the APCMS via the one or more hardware processors, a policy metadata and a policy link tree associated with each matching policy name present in the matching policy set from the policy database; comparing, by the APCMS via the one or more hardware processors, the generated link tree with the policy link tree associated each matching policy name to identify a policy scenario; creating, by the APCMS via the one or more hardware processors, a policy metadata associated with a policy based on the identified policy scenario, wherein the policy is one of: a new policy, and an existing policy; and storing, by the APCMS via the one or more hardware processors, the policy metadata associated with the policy in the policy database.
[006] In another aspect, there is provided an access policy creation and management system for creating and managing access policies of an enterprise. The system comprises a memory storing instructions; one or more communication interfaces; and one or more hardware processors coupled to the memory via the one or more communication interfaces, wherein the one or more hardware processors are configured by the instructions to: receive an access policy requirement document, the access policy requirement document comprising a policy statement in a natural language; identify an entity type and an entity value of one or more entities present in the policy statement using an entity tagger; generate a link tree based on the identified entity type and the entity value of the one or more entities; identify one or more target entities in the link tree based on a predefined target entity identification criterion; determine whether a policy name is present in the policy statement by performing a string matching between the policy statement and a plurality of policy names using a string matching algorithm, wherein the plurality of policy names are accessed from a knowledge graph; upon determining that the policy name is not present in the policy statement, determine one or more relationships of type policy that are present between the one or more identified target entities by accessing information about the one or more identified target entities from the knowledge graph; extract one or more matching policy names based on the one or more determined relationships using the plurality of policy names, wherein the one or more matching policy names are added in a matching policy set created and comprised in a policy database, for the policy statement; access a policy metadata and a policy link tree associated with each matching policy name present in the matching policy set from the policy database; compare the generated link tree with the policy link tree associated each matching policy name to identify a policy scenario; create a policy metadata associated with a policy based on the identified policy scenario, wherein the policy is one of: a new policy, and an existing policy; and store the policy metadata associated with the policy in the policy database.
[007] In yet another aspect, there are provided one or more non-transitory machine-readable information storage mediums comprising one or more instructions which when executed by one or more hardware processors cause a method for creating and managing access policies of an enterprise. The method comprises receiving, by an access policy creation and management system (APCMS) via one or more hardware processors, an access policy requirement document, the access policy requirement document comprising a policy statement in a natural language; identifying, by the APCMS via the one or more hardware processors, an entity type and an entity value of one or more entities present in the policy statement using an entity tagger; generating, by the APCMS via the one or more hardware processors, a link tree based on the identified entity type and the entity value of the one or more entities; identifying, by the APCMS via the one or more hardware processors, one or more target entities in the link tree based on a predefined target entity identification criterion; determining, by the APCMS via the one or more hardware processors, whether a policy name is present in the policy statement by performing a string matching between the policy statement and a plurality of policy names using a string matching algorithm, wherein the plurality of policy names are accessed from a knowledge graph; upon determining that the policy name is not present in the policy statement, determining, by the APCMS via the one or more hardware processors, one or more relationships of type policy that are present between the one or more identified target entities by accessing information about the one or more identified target entities from the knowledge graph; extracting, by the APCMS via the one or more hardware processors, one or more matching policy names based on the one or more determined relationships using the plurality of policy names, wherein the one or more matching policy names are added in a matching policy set created and comprised in a policy database, for the policy statement; accessing, by the APCMS via the one or more hardware processors, a policy metadata and a policy link tree associated with each matching policy name present in the matching policy set from the policy database; comparing, by the APCMS via the one or more hardware processors, the generated link tree with the policy link tree associated each matching policy name to identify a policy scenario; creating, by the APCMS via the one or more hardware processors, a policy metadata associated with a policy based on the identified policy scenario, wherein the policy is one of: a new policy, and an existing policy; and storing, by the APCMS via the one or more hardware processors, the policy metadata associated with the policy in the policy database.
[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 is an example representation of an environment, related to at least some example embodiments of the present disclosure.
[011] FIG. 2 illustrates an exemplary block diagram of a system for creating and managing access policies of an enterprise, in accordance with an embodiment of the present disclosure.
[012] FIG. 3 illustrates a schematic block diagram representation of a policy metadata creation process for creating policy metadata associated with a policy based on a policy statement stated in a natural language, in accordance with an embodiment of the present disclosure.
[013] FIGS. 4A and 4B, collectively, illustrate an exemplary flow diagram of a method for creating and managing access policies of the enterprise, in accordance with an embodiment of the present disclosure.
[014] FIG. 5A illustrates an example representation of entity value and entity types that can be present in the policy statement, in accordance with an embodiment of the present disclosure.
[015] FIG. 5B is an example representation of a link tree generated for the policy statement, in accordance with an embodiment of the present disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS
[016] 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.
[017] As discussed earlier, the administrators manually manage the access control system of the enterprises based on their own understanding of the policy requirement which sometimes leads to incorrect policy creation/updation and access decisions due to misunderstanding in the perspective of the policy requirement or misrepresentation of the entities in the policy requirement. Further, some access policy requirement may include multiple rules and entities, so for generating an access policy based on the policy requirement, the administrator may be required to go through a lot of fields and process flows, thereby ensuring accuracy of the generated policy is a challenge as accuracy cannot be guaranteed due to presence of human errors that may occur while creating policies manually. Additionally, even if advanced access control systems are developed for creating and managing access policies, the access control systems may include a plurality of web pages to cater each individual type of policy creation and modification request, so the administrators, before addressing any request, may need to manually look for the relevant page among the plurality of web pages which may not be a desired thing to do for the administrators.
[018] To address the above technical problems, a system and a method are provided by the present disclosure that enables administrator to easily perform their access control and management activities. The system also facilitates access policy creation, modification, and management. More specifically, an access policy creation and management system (APCMS) (also referred as system and interchangeably used herein) is provided for creating and managing access policies of an enterprise. The system receives policy requirement, drafted in natural language text as an input. The system then identifies a policy scenario specified in the policy requirement i.e., whether a new access policy is to be created or an existing policy needs to be modified or a new policy needs to be created based on an existing policy. Based on the identified policy scenario, the system generates a meta-data required for the access policy to be created/updated using knowledge graph associated with the enterprise and existing policies. The metadata includes all the rules, sub-rules, parameters, and attributes that are required for creating/updating the access policy. The access control system can directly use the metadata to accurately generate/update the existing policy. As the policy scenario identification is done by the system and the perspective of the administrator plays no role in identifying policy scenario, the errors, such as misunderstanding in the perspective of the policy requirement or misrepresentation of the entities in the policy requirement that use to occur due to manual intervention are thereby eliminated.
[019] Referring now to the drawings, and more particularly to FIGS. 1 through 5B, 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.
[020] FIG. 1 illustrates an exemplary representation of an environment 100 related to at least some example embodiments of the present disclosure. Although the environment 100 is presented in one arrangement, other embodiments may include the parts of the environment 100 (or other parts) arranged otherwise depending on, for example, identification of entity type and entity values, generation of link tree, etc. The environment 100 generally includes a user device, such as a user device 102, an access policy creation and management system (hereinafter referred as ‘APCMS’) 106, a database 108 and a policy database 110 each coupled to, and in communication with (and/or with access to) a network 104. It should be noted that one user device is shown for the sake of explanation; there can be more number of user devices.
[021] The network 104 may include, without limitation, a light fidelity (Li-Fi) network, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a satellite network, the Internet, a fiber optic network, a coaxial cable network, an infrared (IR) network, a radio frequency (RF) network, a virtual network, and/or another suitable public and/or private network capable of supporting communication among two or more of the parts or users illustrated in FIG. 1, or any combination thereof.
[022] Various entities in the environment 100 may connect to the network 104 in accordance with various wired and wireless communication protocols, such as Transmission Control Protocol and Internet Protocol (TCP/IP), User Datagram Protocol (UDP), 2nd Generation (2G), 3rd Generation (3G), 4th Generation (4G), 5th Generation (5G) communication protocols, Long Term Evolution (LTE) communication protocols, or any combination thereof.
[023] The user device 102 is associated with a user (e.g., a user or an entity such as an organization) who wants to either create an access policy or update an existing access policy using the APCMS 106. Examples of the user device 102 include, but are not limited to, a personal computer (PC), a mobile phone, a tablet device, a Personal Digital Assistant (PDA), a server, a voice activated assistant, a smartphone, and a laptop.
[024] In an embodiment, the user device 102 may include an access control system (not shown in FIG. 1) that is responsible for creating access policies of an enterprise/organization using the APCMS 106. In another embodiment, the environment 100 may also include the access control system that is coupled to, and in communication with the network 104.
[025] In an embodiment, the database 108 stores all the information associated with an enterprise, such as information about enterprise entities like employees, projects, resources, locations, and the relations between them. In one embodiment, the database 108 also stores a knowledge graph that is created from the enterprise data consisting of all the administrative details of the enterprise. In at least one example embodiment, the knowledge graph includes entities like employees, projects, domains, locations, resources, and relations between them. The knowledge graph may help in identifying enterprise specific entities and constructing a link tree between these entities.
[026] In an embodiment, the policy database 110 stores a plurality of access policies that are created for the enterprise. The policy database 110 also stores information such as a policy metadata and a policy link tree associated with each access policy of the plurality of access policies. It should be noted that the information associated with each access policy is stored corresponding to their policy name in the policy database. In at least one example embodiment, the policy database 110 stores all the access policies that are created by the access control system of the enterprise.
[027] The access policy creation and management system (APCMS) 106 includes one or more hardware processors and a memory. The APCMS 106 is configured to perform one or more of the operations described herein. The APCMS 106 is configured to receive an access policy requirement document from the user device 102 via the network 104. The access policy requirement document includes a policy statement that is written in a natural language. The APCMS 106 is then configured to identify entity type and entity values of one or more entities that might be present in the policy statement using an entity tagger. Once the entity type and entity values of the entities are identified, the APCMS 106 uses them to generate a link tree.
[028] Thereafter, the APCMS 106 identifies one or more target entities in the link tree based on a predefined target entity identification criterion. In an embodiment, the predefined target entity identification criterion is to identify entities present in two top levels of the link tree as the target entities. The APCMS 106 then identifies whether a policy name is present in the policy statement by performing a string matching between the policy statement and a plurality of policy names accessed from the knowledge graph using a string matching algorithm. Examples of the string matching algorithm includes, but are not limited to, Naïve string search, boyer-moore string search algorithm, aho-corasick algorithm, bitap algorithm, boyer-moore-horspool algorithm etc.
[029] In case it is determined that the policy name is not present in the policy statement, the APCMS 106 determines one or more relationships of type policy that are present between the one or more identified target entities by accessing information about the one or more identified target entities from the knowledge graph. Thereafter, the APCMS 106 extracts one or more matching policy names based on the one or more determined policy type relationships using the plurality of policy names. The one or more matching policy names are then added in a matching policy set created for the policy statement. In an embodiment, the matching policy set is created in the policy database 110.
[030] Further, the APCMS 106 accesses the policy metadata and the policy link tree associated with each matching policy name present in the matching policy set from the policy database to compare the generated link tree with the policy link tree associated with each matching policy name for identifying a policy scenario. In an embodiment, the policy scenario is one of a new policy creation, an existing policy updation and an existing policy based new policy creation.
[031] In one embodiment, the policy scenario is the new policy creation in case the generated link tree is not matching with the policy link tree associated with each matching policy name present in the matching policy set. The policy scenario is the existing policy updation in case the generated link tree is a subtree of the policy link tree associated with a matching policy name present in the matching policy set. The policy scenario is the existing policy based new policy creation in case the generated link tree is one of the subtree of the policy link tree associated with the matching policy name present in the matching policy set, or a superset of the policy link tree associated with the matching policy name present in the matching policy set.
[032] Once the policy scenario is identified i.e., the APCMS 106 creates a policy metadata associated with a policy based on the identified policy scenario. The policy is one of a new policy or an existing policy. The creation of policy metadata is explained in detail with reference to FIGS. 4A and 4B. The metadata includes structure of policy to be created/modified, i.e., number of rules, each rule with sub rules, parameters, and attributes.
[033] In an embodiment, the APCMS 106 may share the created policy metadata with the user device 102 using the network 104 and the access control system present in the user device 102 may then use the policy metadata to create/update the policy. In another embodiment, the APCMS 106 may store the created policy metadata in the policy database 110 and the access control system may access the policy metadata from the policy database 110 using the network 104 for creating/updating the policy. In yet another embodiment, the APCMS 106 may share the created policy metadata with the access control system using the network 104 and the access control system directly uses the policy metadata to create/update the policy.
[034] In case the policy name is found to be present in the policy statement, the APCMS 106 extracts at least one matching policy name based on the policy name from the policy database 110. The APCMS 106 then adds the at least one matching policy name in the matching policy set created for the policy statement in the policy database 110. Thereafter, the APCMS 106 accesses the policy metadata and the policy link tree associated with the at least one matching policy name. Further, the APCMS 106 compares the generated link tree with the policy link tree associated with each matching policy name to identify the policy scenario.
[035] Once the policy scenario is identified i.e., an intent of the policy statement is known, the APCMS 106 updates the link tree based on the identified policy scenario. The process of updating the link tree is explained in detail with reference to FIGS. 4A and 4B. The updated link tree is then used by the APCMS 106 to create a policy metadata. The created policy metadata is then either shared with the user device 102 access control system or stored in the policy database 110 as explained earlier.
[036] In an embodiment, the APCMS 106 is also configured to identify an identical and/or a colliding policy with the policy that is being generated. In particular, the APCMS 106 is configured to identify existing policies similar to the policy that is being created and the existing policies that are contradicting with the policy that is being created.
[037] In one embodiment, the APCMS 106 is configured to calculate a dissimilarity measure between the policy that is being created (also referred as policy under creation) and the plurality of access policies that are stored in the policy database 110. In at least one example embodiment, the APCMS 106 uses a cosine similarity measure or a Jaccard distance measure to determine dissimilarity between the policy under creation and the plurality of access policies. If the dissimilarity measure is found to be less than a predefined dissimilarity threshold set for the dissimilarity measure between the policy under creation and an access policy, the APCMS 106 considers the access policy as the similar policy. And all the access policy that are found to be similar to the policy under creation is then shared by the APCMS 106 with the user device 102. The user of the user device 102 can take the decision of modifying or deleting the existing policy or the policy under creation.
[038] Additionally, in one embodiment, the APCMS 106 is configured to identify one or more existing access policies that are in contradiction with the policy that is being created. In at least one example embodiment, the APCMS 106 uses antonym identifier packages to calculate a contradiction measure between the policy under creation and the plurality of access policies. If the contradiction measure is found to be more than a predefined contradiction threshold set for the contradiction measure between the policy under creation and the access policy, the APCMS 106 considers the access policy as the contradictory policy. And the one or more existing access policy that are found to be contradictory with the policy under creation is then shared by the APCMS 106 with the user device 102. The user of the user device 102 can take the decision of modifying or deleting or adding the existing policy or the policy under creation.
[039] The number and arrangement of systems, devices, and/or networks shown in FIG. 1 are provided as an example. There may be additional systems, devices, and/or networks; fewer systems, devices, and/or networks; different systems, devices, and/or networks; and/or differently arranged systems, devices, and/or networks than those shown in FIG. 1. Furthermore, two or more systems or devices shown in FIG. 1 may be implemented within a single system or device, or a single system or device shown in FIG. 1 may be implemented as multiple, distributed systems or devices. Additionally, or alternatively, a set of systems (e.g., one or more systems) or a set of devices (e.g., one or more devices) of the environment 100 may perform one or more functions described as being performed by another set of systems or another set of devices of the environment 100 (e.g., refer scenarios described above).
[040] FIG. 2 illustrates an exemplary block diagram of an access policy creation and management system (APCMS) 200 for creating and managing access policies of an enterprise, in accordance with an embodiment of the present disclosure. In an embodiment, the access policy creation and management system (APCMS) may also be referred as system and may be interchangeably used herein. The system 200 is similar to the APCMS 106 explained with reference to FIG. 1. In some embodiments, the system 200 is embodied as a cloud-based and/or SaaS-based (software as a service) architecture. In some embodiments, the system 200 may be implemented in a server system. In some embodiments, the system 200 may be implemented in a variety of computing systems, such as laptop computers, notebooks, hand-held devices, workstations, mainframe computers, and the like.
[041] In an embodiment, the system 200 includes one or more processors 204, communication interface device(s) or input/output (I/O) interface(s) 206, and one or more data storage devices or memory 202 operatively coupled to the one or more processors 204. The one or more processors 204 may be one or more software processing modules and/or hardware processors. In an embodiment, the hardware processors can be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor(s) is configured to fetch and execute computer-readable instructions stored in the memory 202.
[042] The I/O interface device(s) 206 can include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like and can facilitate multiple communications within a wide variety of networks N/W and protocol types, including wired networks, for example, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. In an embodiment, the I/O interface device(s) can include one or more ports for connecting a number of devices to one another or to another server.
[043] The memory 202 may include any computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. In an embodiment a database 208 can be stored in the memory 202, wherein the database 208 may comprise, but are not limited to, policy metadata that is created using the system 200, and the like. The memory 202 further comprises (or may further comprise) information pertaining to input(s)/output(s) of each step performed by the systems and methods of the present disclosure. In other words, input(s) fed at each step and output(s) generated at each step are comprised in the memory 202 and can be utilized in further processing and analysis.
[044] FIG. 3, with reference to FIGS, 1-2, illustrates a schematic block diagram representation 300 of a policy metadata creation process associated with the system 200 of FIG. 2 or the APCMS 106 of FIG. 1 for creating policy metadata associated with a policy based on policy statement stated in a natural language, in accordance with an embodiment of the present disclosure.
[045] FIGS. 4A and 4B, collectively, with reference to FIGS. 1, 2 and 3, illustrate an exemplary flow diagram of a method 400 for creating and managing access policies of the enterprise, in accordance with an embodiment of the present disclosure. The method 400 may use the system 200 of FIG. 2 and APCMS 106 of FIG. 1 for execution. In an embodiment, the system 200 comprises one or more data storage devices or the memory 202 operatively coupled to the one or more hardware processors 204 and is configured to store instructions for execution of steps of the method 400 by the one or more hardware processors 204. The sequence of steps of the flow diagram may not be necessarily executed in the same order as they are presented. Further, one or more steps may be grouped together and performed in form of a single step, or one step may have several sub-steps that may be performed in parallel or in sequential manner. The steps of the method 400 of the present disclosure will now be explained with reference to the components of the system 200 as depicted in FIG. 2, and the flow diagram.
[046] In an embodiment of the present disclosure, at step 402, the one or more hardware processors 204 comprised in the system 200 receive an access policy requirement document from a user device (e.g., the user device 102). The access policy requirement document includes a policy statement written in a natural language.
[047] At step 404 of the present disclosure, the one or more hardware processors 204 of the system 200 identify an entity type and an entity value of one or more entities present in the policy statement using an entity tagger. In an embodiment, the entity tagger is a dictionary based methodology used for identifying entities. The identifiable entity values and entity types are found in the knowledge graph. In particular, the entity tagger is configured to find and tag one or more entities present in the policy statement, from the knowledge graph with appropriate entity types. For example, the access policy requirement document includes the policy statement ‘Employees working in projects A or B can access ODC2 provided they have completed NDA and Security quiz’. So, at this step, entity types that are present in the policy statement, such as user, project, privilege, work zone and compliance are identified and then the entity values of the identified entities are identified, such as for the entity ‘user’, entity value is ‘Employees’ in the received policy statement. Similarly, the entity value for the entity ‘project’ is identified as ‘project A or project B’. An example representation of entity value and entity types that can be present in the input statement is shown with reference to FIG. 5A.
[048] At step 406 of the present disclosure, the one or more hardware processors 204 of the system 200 create a link tree based on the identified entity type and the entity value of the one or more entities. The above step 406 is better understood by way of following description.
[049] In an embodiment, once the entity type and the entity value of the one or more entities is available, the hardware processors 204 use a dependency parser to generate a parse tree based on the identified entity type and the entity value of the one or more entities. In one embodiment, the dependency parser is a customized dependency parser designed based on natural language processing (NLP) package spacy’s dependency parser. The dependency parser is configured to generate a tree structure (also referred as the parse tree) for an input sentence, such as the policy statement using a part of speech of words in the input sentence and the one or more entities whose information is accessed from the knowledge graph. The parse tree includes a plurality of parse tree nodes. Each parse tree node of the plurality of parse tree nodes includes a tag. The tag is either a relevant tag or an irrelevant tag. In one embodiment, the relevant tag includes one of a method tag, an entity tag, and an operation tag. All other tags are considered as the irrelevant tag.
[050] So, once the parse tree is generated, the one or more hardware processors 204 of the system 200 identify one or more parse tree nodes of the plurality of parse tree nodes that has the method tag or the operation tag. In particular, the nodes in the parse tree that has method tag, or the operation tag are identified and marked. Thereafter, the hardware processors 204 convert the identified one or more parse tree nodes into one or more edges i.e., the nodes that has method tag or the operation tag are converted into edges. Additionally, the hardware processors 204 provide a label to each edge of the one or more converted edges depending on the relevant tag i.e., if the method node is converted into an edge, then a method label is provided to that edge. Similarly, if the operation node is converted into an edge, then an operation label is provided to that edge.
[051] Further, the hardware processors 204 add each edge of the one or more edges to a parent node of the respective parse tree node. In particular, the converted edge with the method label or the operation label is added as edge to the parent node of the same parse tree node that is converted into the edge. Once the edges with method tag and the operation tag are converted into edges, the hardware processors 204 identify at least one parse tree node in the plurality of parse tree nodes that is presented as an attribute in the knowledge graph. Basically, nodes that are presented as attribute in the knowledge graphs are first identified. Thereafter, among those nodes, the at least one node that is also present in the parse tree is identified. The hardware processors 204 then convert the at least one parse tree node into an attribute of a parent node of the least one parse tree node. In particular, the identified at least one parse tree node is added as the attribute node to the parent node of the at least one parse tree node in the parse tree.
[052] The one or more nodes that comprise the irrelevant tags in the parse tree are then removed by the hardware processors 204 from the parse tree to obtain the link tree. An example representation of the link tree generated for the policy statement is shown with reference to FIG. 5B.
[053] At step 408 of the present disclosure, the one or more hardware processors 204 of the system 200 identify one or more target entities in the link tree based on a predefined target entity identification criterion. In an embodiment, the predefined target entity identification criterion includes identifying top two level nodes in the link tree as the target entities. So, with reference to the previous example, the target entities that are identified includes ODC2 (Workzone), Project A (Project), and Project B (Project).
[054] In an embodiment, at step 410 of the present disclosure, the one or more hardware processors 204 of the system 200 determine whether a policy name is present in the policy statement by performing a string matching between the policy statement and a plurality of policy names using the string matching algorithm. In particular, the string matching is performed between the policy statement and each policy name of the plurality of policy names to check whether any matching policy name is present in the policy statement. In one embodiment, the plurality of policy names is accessed from the policy database 110.
[055] At step 412 of the present disclosure, upon determining that the policy name is not present in the policy statement, the one or more hardware processors 204 of the system 200 determine one or more relationships of type policy that are present between the one or more identified target entities by accessing information about the one or more identified target entities from the knowledge graph. With reference to the previous example, the policy statement does not include any policy name, hence the step 412 is performed. At this step, the information about the target entities i.e., the top two layer entities are accessed from the knowledge graph and then it is checked whether any relationship of type policy exist between them in the knowledge graph.
[056] Thereafter, at step 414, the one or more hardware processors 204 of the system 200 extract one or more matching policy names based on the one or more determined relationships using the plurality of policy names. In particular, the once the policy type relationships are determined between the target entities, the hardware processors 204 compare policy names present in the policy type relationships with the plurality of policy names that are present in the policy database 110 to determine the one or more matching policy names. Further, the one or more matching policy names are added to a matching policy set created and included in the policy database 110 for the policy statement.
[057] At step 416 of the present disclosure, the one or more hardware processors 204 of the system 200 access a policy metadata and a policy link tree associated with each matching policy name present in the matching policy set from the policy database. In particular, the policy metadata and the policy link tree associated with each matching policy name is accessed at this step.
[058] At step 418 of the present disclosure, the one or more hardware processors 204 of the system 200 compare the generated link tree with the policy link tree associated each matching policy name to identify a policy scenario. The above step 418 is better understood by way of following description.
[059] The generated link tree is compared with the policy link tree associated each matching policy name to check whether the generated link tree is matching with the policy link tree associated with any matching policy. In case the generated link tree is not matching with the policy link tree associated with each matching policy name present in the matching policy set, the hardware processors 204 identify the policy scenario i.e., the intent of the policy statement as the new policy creation. It means a new policy is to be created as per the policy requirement stated in the policy statement.
[060] In another case, if the generated link tree is found to be a subtree of the policy link tree associated with a matching policy name present in the matching policy set, the hardware processors 204 identify the policy scenario i.e., the intent of the policy statement as the existing policy updation. In particular, if the created link tree is found to be a part of the policy link tree associated with the matching policy name, the policy scenario is considered as the existing policy updation. It means an existing policy is to be changed as per the policy requirement stated in the policy statement.
[061] In yet another case, if the generated link tree is found to be one of the subtree of the policy link tree associated with the matching policy name present in the matching policy set and a superset of the policy link tree associated with the matching policy name present in the matching policy set, the hardware processors 204 identify the policy scenario i.e., the intent of the policy statement as the existing policy based new policy creation. It means an existing policy is used as a base policy for creating a new policy as per the policy requirement stated in the policy statement.
[062] At step 420 of the present disclosure, once the policy scenario is identified, the one or more hardware processors 204 of the system 200 create a policy metadata associated with a policy based on the identified policy scenario. The policy is one of a new policy or an existing policy. The above step 420 is better understood by way of following description.
[063] In an embodiment, upon identifying that the policy scenario is the new policy creation, the hardware processors 204 identify a top level node of the generated link tree as a policy target attribute. So, with reference to the previous example, the ODC2 (Workzone) is identified as the policy target attribute. Then, the hardware processors 204 identify one or more sub-level nodes of the generated link tree as one or more policy rules of the policy i.e., the new policy to be created. So, at this step, the project A and project B are identified as the sub-level nodes and as the entities have the same requirement and have a connector, they are made into a single rule with connector ‘OR’. Similarly, the compliance nodes i.e., ‘NDA’ and ‘Security quiz’ are identified as the sub-level nodes and as the entities have the same requirement and have a connector, they are made into a single rule with connector ‘AND’.
[064] Thereafter, the hardware processors 204 convert the generated link tree into an output tree based on the identified target attribute and the one or more policy rules. In particular, a similar output tree is created based on the updated link tree. The output tree is further utilized by the hardware processors 204 to create the policy metadata associated with the policy. An example representation of the policy metadata created for the policy statement can be represented as:
Policy Name/Id: ProjectAorB_ODC2
Policy Target: ODC2
Privilege: Access
Rule 1:
Relationship: User -> Project A -> ODC2
Or
Relationship: User -> Project B -> ODC2
Rule 2:
Allow On: Complete/True
Compliance: NDA
And
Compliance: Security quiz
[065] In an embodiment, the created policy metadata and the output tree associated with the policy is stored in the policy database 110 under the created policy name. Additionally, a relationship is created between project A and ODC2, project B and ODC2 with label ProjectAorB_ODC2 and type policy in the knowledge graph.
[066] In another embodiment, upon identifying that the policy scenario is the existing policy updation, the hardware processors 204 first determine one or more differences between the generated link tree and the policy link tree associated with the matching policy name present in the matching policy set. The one or more differences includes one or more of differences in either one or more policy rules, or one or more policy attributes, or one or more policy methods. For example, the policy statement includes ‘Modify ODC3_ProjectC policy to allow all employees except customer executives’. So, in this case a new rule is to be added to forbid customer executives from entering ODC3 in the exiting policy named ‘ODC3_ProjectC’. An example representation of the policy metadata created for the example policy statement can be represented as:
Policy Name: ODC3_ProjectC
Policy Target. ODC3
Privilege. Access
Decision Combining Algorithm: DenyOverrides
Rule1:
Subject. Employees under Project C
Rule2:
Completion check. NDA, Security Quiz
Rule3:
Forbid. Customer Executive
[067] Thereafter, the hardware processors 204 updates the generated link tree based on the one or more differences to obtain the output tree i.e., the generated link tree is updated to include an additional rule of forbidding customer executives. The updated link tree is then copied to create the output tree. Further, the hardware processors 204 update the policy metadata based on the output tree.
[068] As explained earlier, the updated policy metadata and the output tree associated with the policy is stored in the policy database 110.
[069] In yet another embodiment, upon identifying that the policy scenario is the existing policy based new policy creation, the hardware processors 204 perform copying of one or more policy rules, one or more policy attributes, and one or more policy methods present in the policy link tree associated with the matching policy name present in the matching policy set. Thereafter, hardware processors 204 update the generated link tree based, at least in part, on the copied one or more policy rules, the one or more policy attributes, and the one or more policy methods to obtain the output tree. In particular, the policy rules, the policy attributes, and the policy methods of the matching policy are applied on the entities present in the created link tree to obtain the output tree of the policy.
[070] Then, hardware processors 204 create the policy metadata based on the output tree for the policy statement.
[071] In case, it is determined that the policy name is present in the policy statement at step 410, the hardware processors 204 extract at least one matching policy name based on the policy name using the plurality of policy names. Thereafter, the hardware processors 204 access the policy metadata and the policy link tree associated with each matching policy name present in the matching policy set from the policy database. Further, the hardware processors 204 compare the generated link tree with the policy link tree associated with each matching policy name to identify the policy scenario. Once the policy scenario is identified, the link tree is updated based on the identified policy scenario as explained earlier. It should be noted that the policy scenario in this case can be either the existing policy updation or the existing policy based new policy creation. The process of updating link tree based on the identified scenario is explained in detail with reference to the step 420 and the process is not reiterated herein for the sake of brevity.
[072] At step 422 of the present disclosure, the one or more hardware processors 204 of the system 200 store the policy metadata associated with the policy in the policy database 110.
[073] It should be noted that the policy metadata generated by the system 200 is not an executable policy. The metadata includes required component, such as policy attributes, number of rules, each rule attributes and methods that are necessary for creating a new policy or updating an existing policy. The policy metadata can then be shared with any access control system or a policy creation engine for generating/updating the policy.
[074] 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.
[075] As discussed earlier, the administrators manage the access control system manually and the managing becomes increasingly difficult when an access policy that needs to be created or modified contains number of rules as the administrator has to go through a lot of fields to generate the accurate access policy. So, to overcome the disadvantages, embodiments of the present disclosure provide a method and a system for creating and managing access policies of an enterprise. More specifically, the system performs policy scenario identification, and the perspective of the administrator plays no role in identifying policy scenario, thus significantly reducing the errors, such as misunderstanding in the perspective of the policy requirement or misrepresentation of the entities in the policy requirement that use to occur due to manual intervention. The system also identifies duplicate or colliding policies that might be missed when administrator manually create the policy, thereby eliminating potential policy collisions and duplications of existing access policies.
[076] 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 both 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.
[077] 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.
[078] 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.
[079] 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.
[080] 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.