Patent Application
20160232370
The invention disclosed herein generally relates to the field of automated access control in computer systems. In particular, the invention relates to graphical interaction techniques for configuring an access control mechanism which selectively permits and denies access to resources in a computer system. It is contemplated to implement the interaction techniques as part of a graphical user interface (GUI) in a policy administration point associated with the access control mechanism.
On a high level, attribute-based access control (ABAC) may be defined as a method where a subject's requests to perform operations on resources are granted or denied based on assigned attributes of the subject, assigned attributes of the resource, environment conditions, and a set of one or more policies that are specified in terms of those attributes and conditions. Here, attributes are characteristics of the subject, resource, or environment conditions. Attributes may further be defined to reflect characteristics of an action performed on or in respect of a resource. Attributes contain information given by a name-value pair, which may be single-valued or multiple-valued. A subject is a human user or non-person entity, such as a device that issues access requests to perform operations on resources. Subjects are assigned one or more attributes. A resource (or object) is a system resource for which access is managed by the ABAC system, such as devices, files, records, tables, processes, programs, networks, or domains containing or receiving information. It can be the resource or requested entity, as well as anything upon which an operation may be performed by a subject including data, applications, services, devices, and networks. An operation is the execution of a function at the request of a subject upon a resource. Operations include read, write, edit, delete, copy, execute and modify. Environment conditions describe an operational or situational context in which an access request occurs. Environment conditions are detectable environmental characteristics. Environmental characteristics are generally independent of subject or resource, and may include the current time, day of the week, location of a user, or the current threat level. Finally, a policy is the representation of rules or relationships that makes it possible to determine if a requested access should be allowed, given the values of the attributes of the subject, resource, and possibly environment conditions. A policy may be expressed as a logical function, which maps an access request (or decision request) with a set of attribute values (or references to attribute values) to an access decision (or an indication that the request has not returned a decision).
An ABAC authorization scenario is depicted in
There currently exist general-purpose ABAC policy languages that have the richness to express fine-grained conditions and conditions which depend on external data. A first example is the Extensible Access Control Markup Language (XACML) which is the subject of standardization work in a Technical Committee of the Organization for the Advancement of Structured Information Standards (OASIS, 35 Corporate Drive, Suite 150, Burlington, Mass., 01803-4238, USA). A policy encoded with XACML consists of declarative (in particular, functional) expressions in terms of attributes, and the return value (decision) of the policy is one of Permit, Deny, Not Applicable, or Indeterminate. An XACML policy can apply to many different situations, that is, different subjects, resources, actions and environments and may give different results for them. The XACML specification defines how such a request is evaluated against the policy, particularly what policy attributes are to be evaluated or, at least, which values are required to exist for a successful evaluation to result. A key characteristic of this evaluation process is that the request must describe the attempted access to a protected resource fully by containing information sufficient for all necessary attribute values to be retrieved. In practice, it may be that the request is interpreted in multiple stages by different components, so that a PEP (Policy Enforcement Point) issuing the requests provides only some attribute values initially, and a PDP (Policy Decision Point) or other component responsible for the evaluation can dynamically fetch more values from remote sources as they are needed. A second example is the Axiomatics Language For Authorization™, which the applicant provides.
With regard to terminology in XACML, it is noted that “policy” may on the one hand have the meaning defined above—a representation of rules or relationships that makes it possible to determine if a requested access should be allowed—and, on the other, may refer to a type of element titled Policy inside such a representation of rules and relationships. The term “policy”/“Policy” will be used in both senses in this disclosure, though each particular occurrence should be unambiguous.
XACML-based solutions typically offer “authorization as a service”, wherein a PEP in a target application/system captures access requests in real time and sends them to a PDP for evaluation against a current version one or more XACML policies. Such externalized authorization approach ensures continuity in that it drastically reduces or eliminates the latency between an update of the policy and actual enforcement of the new rules therein.
Available PDP implementations are typically configured to implement a text representation of an ABAC policy, which it retrieves from a policy repository, and are unable to accept ABAC policies in other formats. Likewise, an administrator desiring to update the policy stored in the repository must do so by submitting, through the available administration interface, a new version in text format. Clearly, the administrator interface would as well reject incremental changes that were requested in non-textual form.
It would be desirable to reduce or at least mitigate the above limitations associated with the prior art. In particular, it would be of technical advantage if a currently enforced ABAC policy could be visualized for inspection and analysis in graphical form. In particular, it would be advantageous to visualize to an administrator how a change in an ABAC policy affects access rights in the system, and more precisely to visualize abstract elements of the ABAC policy that have hitherto not been represented graphically. Furthermore, it would be advantageous to provide an administrator interface with graphical elements that are responsive to user manipulation in such manner as to allow an ABAC policy to be input, extended and/or edited. It would be of further advantage if the user's manipulations are not only reflected in a displayed representation of the ABAC policy but also associated with a direct effect on the behaviour of the access control mechanism operating in the computer system. Still further, it would be advantageous to provide a consistency-testing functionality operating at the level of the graphical representation and visualizing its outcome in graphical form.
More precisely, some of the potential technical advantages may be a reduced latency between administrator interface and the access control mechanism; a reduced failure risk since input errors may be discovered more easily and/or by a broader personnel base; more efficient use of an available screen area, as a graphical representation of an ABAC policy may oftentimes occupy less space than a representation by text of legible font size; less time-consuming input, editing and verification processes. Furthermore, the inventors have taken care to structure the graphical representation of the ABAC policy in such manner that translation to and from a textual, machine-interpretable representation is possible in very limited time even in a normal runtime environment; therefore, for practical purposes, the graphical representation is quasi machine-interpretable in itself, so that an administrator may be able to inspect and edit a graphical representation of an ABAC policy that is currently being enforced in the computer system. By virtue of this, real-time or quasi real-time maintenance of the ABAC policy is possible in graphical form, so that valuable downtime of the access control mechanism can be reduced or avoided. The final design of the graphical representation may be developed to be pleasing and intuitive to the user, but in principle does not form part of the invention.
As used herein, a text representation is an arrangement of characters selected from predefined font tables (e.g., characters from one chosen alphabet or script, such as Roman or Greek letters, diacritics, digits, mathematical operators and the like), whereas a representation in graphical form may be understood as a representation going beyond a pure text representation. For instance, a graphical representation may include bitmaps, vector graphics, ideograms and other images, these non-textual elements optionally appearing in combination with textual elements, such as single characters, words, lines and paragraphs. It is envisaged that a graphical representation may include characters of a specialized drawing font adapted to be arranged into lines, boxes, curves, shapes and the like (e.g., characters ┌ ┐ ┘ └ ┤
▴ □
).
At least some of the above advantages are achieved by methods, devices and computer program products having the features set forth in the independent claims appended hereto. Further example embodiments are defined by the dependent claims. In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. Any reference signs appearing in the claims are not to be understood as limiting their scope.
Example embodiments of the invention will now be described in greater detail and with reference to the accompanying drawings, on which:
Unless otherwise stated, the drawings generally show only such components and elements that are necessary to illustrate the present invention; other components and elements may have been intentionally omitted for the sake of clarity.
The access request is to be evaluated against an ABAC policy in a policy repository 190, which may be maintained from a policy administration point (PAP) 404. The PDP 403 may configured to retrieve necessary information describing the ABAC policy from the repository 190. From a policy information point (PIP) 405, the PDP 403 may request any such values of policy attributes that are missing from the initial access request but necessary to evaluate the request against the policy. In turn, the PIP 405 may request these values from an attribute repository 303-304 storing values of subject and resource attributes (in this sense, the repository may be seen as an entity combining the functionalities of the data sources 303 and 304 in
An ABAC policy (or ABAC policy set) may be a set of ordered elements. An element may be a functional expression (example: PolicySet, Policy, Rule), which is susceptible to evaluation by accepting input data and providing output data in response hereto. Functional expressions in terms of the elements may be hierarchically ordered in such manner that one functional expression accepts, as its input data, the output data of one or more subordinate expressions. If the data from the subordinate expressions are necessary for evaluating the parent expression (e.g., it influences the output of the parent expression non-trivially), then evaluation of the parent expression cannot complete until after the subordinate expression has been finally evaluated. Further, an element may be a container expressing a property of an associated element (example: Description, which may be associated with a PolicySet).
It is possible to combine the outputs of standard-type functional expressions using a standard-type logical, mathematical etc. operator (examples: arithmetic addition operator combining numbers, logic AND operator combining Boolean values). For ABAC-specific functional expressions, which as their output may have decisions such as Permit, Deny, Indeterminate, NotApplicable etc., an ABAC policy may further include a combining algorithm, by which a definite decision is arrived at on the basis of two or more decisions from subordinate ABAC-specific functional expressions (example: a deny-overrides combining algorithm joining two Rules with effect Deny).
Specifically, the ABAC policy may be in accordance with an XML language, such as a dedicated access control language, such as XACML. Detailed information on standardized policy syntax and functional requirements is available from OASIS for current (February 2015: version 3.0) and previous releases of XACML. It is expected that future releases of XACML will be backward compatible to a considerable extent, so that many elements of the present invention and teachings contained in this disclosure remain applicable.
An ABAC policy in XML typically is machine-interpretable without any prior compilation step; available generic XML parsers, including SAX and DOM, can be used for this purpose. In at least some available ABAC authorization products, an administrator who is able to work with a textual representation of an ABAC policy may therefore inspect a policy that is being actually enforced by the access control mechanism in the computer system. Similar, any edits the administrator makes in the ABAC policy may be forwarded for enforcement by the access control mechanism (e.g., by a commit-type command) without the delay associated with—and potential errors incurred by—a preceding compilation step.
By the methods and devices proposed in this disclosure, a textual representation of an ABAC policy (e.g., in XACML format mainly using Roman characters, digits and standard operator characters) may serve as a basis for generating a graphical representation of an ABAC policy that is either identical to the textual representation or at least equivalent in the sense that the graphically represented policy returns identical access decisions in response to identical access requests. Conversely, an textual representation of an identical or equivalent ABAC policy may be generated on the basis of a graphical representation. Elements of the graphical representation may contain metadata facilitating the back-conversion into textual form.
It is envisaged that a textual and a graphical representation of one same ABAC policy may be displayed and edited in parallel, e.g. as two selectable modes in a policy administrator interface. The policy administrator interface may be associated with an entity serving as policy decision point, see
By the above functionalities, it may be possible to provide a graphical displaying and editing mode of a policy administrator interface that may serve as a visual programming interface specialized for ABAC policies, hence a tool for inspecting, controlling and defining the behaviour of an access control mechanism in a computer system. The policy administrator interface may be operated in an offline mode and an online mode (each offering a selection of either graphical or textual editing and display). In the online mode, the user's manipulation of the ABAC policy representation may have direct effect on the behaviour of the access control mechanism in the computer system. In the offline mode, the user's manipulations may be given effect after a “commit”, “update” or “apply” command has been given.
In an example embodiment, a graphical representation of an arbitrary syntactically compliant ABAC policy may be generated by defining a symbol being a graphical counterpart of each element of a policy that is allowed under a predefined policy syntax and optionally of allowed relationships between the elements too, such as dependency, hierarchic order etc. In the interest of clarity, ease of learning and limiting the computational load on an processor executing the administrator interface, different allowed elements or relationships in a policy may share a common symbol. Additionally or alternatively, some allowed elements or relationships in a policy may be represented textually, or as metadata associated with one of the symbols. For instance, the administrator may interact (e.g. using a cursor) on one of the symbols to add, inspect or edit associated metadata. As an example, at least some of the symbols forming the graphical representation may be viewable in a normal (where metadata are invisible or only partially visible) and an expanded (where metadata are visible) mode, between which the user of the administrator interface may toggle. The expanded mode may be referred to as a metadata edit mode. Additionally or alternatively, some allowed elements or relationships may be displayed adjacent to one another while others may be displayed separated, in particular in different screen areas.
The inventors' purposeful selection, for each allowed element or relationship of a policy, whether the element/relationship is to be represented graphically or by metadata, what elements/relationships are to share a common symbol, and what elements/relationships are to be grouped together visually, has been arrived at after considering the ABAC model, the structure of an ABAC policy and the functioning of an access control mechanism which the policy controls.
In one example embodiment, it is proposed to use a two-dimensional shape (e.g., circle, square, oval, rectangle, polygonal shape) to represent elements corresponding to XACML elements PolicySet, Policy and Rule. Preferably, the symbols for all of these elements may have the same contour and size but may differ as to their contour line style, in particular the colour of the line. Further preferably, an element corresponding to XACML element Description associated with a PolicySet, Policy or Rule is represented as a visible text string (truncated if necessary to fit) in each shape. This is to say, the element Description is represented textually.
If the ABAC syntax so allows, a new PolicySet, Policy or Rule element may be defined by reference to an existing element of the same type. In an example embodiment, a PolicySet, Policy or Rule element defined by reference may be represented by a symbol having the same contour and shape but differing with regard to its contour line style and/or colour.
Preferably, two or more shapes may be connected by connectors, in particular lines, to reflect a dependency in the ABAC policy. For instance, a hierarchic dependency between a Policy element and N≧1 Rule elements may be graphically represented as a line or curve starting from the Policy element, extending in a predetermined direction (for instance, geometric up/down may signify policy-hierarchic higher/lower, or geometric left/right may signify policy-hierarchic higher/lower) towards the Rule elements, and then bifurcating into N endpoints connecting to each of the Rule elements. Because of the connection lines, the totality of the graphical representation of the ABAC policy may be said to have the appearance of a (possibly rotated) tree. The tree-like structure reflects the hierarchy structure of the policy elements, i.e., the symbols making up the tree-like structure are in a consistent relationship with the PolicySet, Policy and Rule elements of the ABAC policy.
The inventors have considered the option of organizing the PolicySet, Policy and Rule elements in accordance with the subjects and resources to which they pertain. For instance, it would be possible to visualize all Rule elements that apply to a certain user (subject) or group of users in geometric proximity of one another. As a further alternative, it would be possible to collect all symbols representing Rule elements that apply to a certain resource or group of resources. Further still, it would be possible to reflect relationships that exist among users or among resources to which such Rule elements apply. This notwithstanding, the inventors have realized that, although a resource- or user-focused hierarchic structure of the graphical representation may have been potentially more appealing or intuitive to some users of the administrator interface, a graphical representation reflecting the internal dependencies between the policy elements—as described above—is technically more advantageous. In particular, a representation of this type may lend itself to rendering by a linear traversal of the ABAC policy, without an absolute necessity to rearrange the symbols thus generated.
The description of the example embodiment initiated above will now be resumed. Where a PolicySet, Policy or Rule element depends from two or more subordinate Policy or Rule elements, a combining algorithm element of the type introduced above may be used to determine a unique decision on the basis of the outputs of the subordinate elements. For a specific PolicySet or Policy element, a combining algorithm may be selected from a menu which is available when the element is in the metadata edit mode, as outlined above. It is assumed that the number of available combining algorithms is limited and lends itself to memorisation by a skilled user. In an example embodiment, the type of combining algorithm that a superordinate element is configured to apply is indicated by a mnemonic acronym in a specific area inside or next to the shape representing the superordinate element. For instance, XACML combining algorithm permit-overrides may be indicated as “PO” in this area, and first-applicable may be indicated as “FA”. Hence, in this example embodiment, which is freely combinable with the features explained above, the inventors have found it suitable to refrain from representing all elements of the ABAC policy geometrically but have concluded that a purposeful combination of textual and non-textual components is more adequate.
In an example embodiment, the generation process of a graphical representation of several elements on a same level of the policy hierarchy preserves the order in which these elements are defined in the underlying textual representation of the policy. Also, if a user of the administrator interface adds a further child to an element of a graphically represented policy, the new child is added in the location that the user indicated. Put differently, this example embodiment inhibits sorting (or re-sorting after addition) of policy elements on a same level in, say, alphabetical order. An advantage associated with such absence of sorting is that the XACML combining algorithm first-applicable (and its equivalents in other syntaxes) will function consistently. If the elements had been sorted in a particular order, the graphical representation of an ABAC policy may have failed to be fully equivalent to the textual representation.
An ABAC policy which governs the behaviour of an access control mechanism in a computer system of an enterprise with a large number of subjects and resources may occupy several thousands or millions of characters when represented textually. This is in particular so if the population of subjects and/or resources is inhomogeneous, or the computer system is designed to operate in a broad range of changing conditions. It goes without saying that a graphical representation of such an ABAC policy may as well be unwieldy and difficult to fit into a normal personal computer screen without sacrificing visibility. In example embodiments, the inventors have proposed the following measures—to be used singly or in combination—for enabling efficient inspection and editing of such an ABAC policy in an administrator interface.
These measures are exemplified in
As a further measure to facilitate management of a large ABAC policy, the administrator interface shows one same graphical representation of the policy both in a main window 200 and an overview window 210. While the main window 200 can be zoomed in or out to the desired resolution, the overview window conveys a view of the full policy representation while showing a frame 211 indicating the current extent of the main window. This way, the user of the administrator interface may maintain a general impression of those portions of the graphical representation that currently do not fit into the main window.
It is contemplated that the overview window 210 may be located next to the main window 200 or as an insert (or overlay) in the main window 200, such as in the area 220 suggested by a dashed contour.
Preferably, the ABAC policy is visualized in a simpler fashion in the overview window 210. For instance, as suggested in
As a still further measure to facilitate management of a relatively large ABAC policy, the administrator interface may be provided with a search functionality for retrieving textual information associated with symbols graphically representing elements of the ABAC policy. The textual information may relate to both metadata and text in Description elements. Because the metadata text may be visible in the metadata edit mode but not in a normal viewing mode, as already discussed, a user of the administrator interface who is looking for a particular text string may be reduced to entering the metadata edit mode for each of the graphically represented policy elements separately, e.g. in a linear fashion or guided by the user's expectations as to where the text is located. As such, it may be very time-consuming for a user to find specific search phrase in metadata, a need which arises for instance when all occurrences of a given resource or a given subject are to be located.
The search functionality may for instance return the search hits in a hit list in text format. Alternatively or additionally, the graphical representation of those elements of the ABAC policy that contain the search phrase are highlighted.
An efficient implementation of the search functionality may be simplified if, during generation of the graphical representation of an ABAC policy, markers are inserted into interpretation-exempt portions of the textual representation of the ABAC policy (e.g. in comments or annotation fields) or a copy thereof. This way, an annotated textual representation of the ABAC policy is created. A marker may be a unique identifier of a symbol in the graphical representation of the ABAC policy. As such, when a search query pertaining to a textual search phrase is submitted in respect of the graphical representation of the ABAC policy, the search is carried out in the annotated textual representation of the ABAC policy, and the locations of the search hits are translated into symbols of the graphical representation. The search hits may then be displayed in the manner outlined above. Alternatively, the symbols of the graphical representation may carry metadata annotations, which have been added when the symbols were generated from the textual representation, with references to specific portions of the textual representation of the ABAC policy. Line numbers may be used to refer to those specific portions. If the annotations are additionally collected in a look-up table maintained in addition to the graphical and textual representations of the ABAC policy, the search for the search phrase may be carried out in the textual representation (without annotations), upon which the look-up table can be used to find the corresponding symbols of the graphical representation, so that highlighting or other visualization can be added in order to show the locations of the search hits in the graphical representation.
A graphical representation of an XACML Rule element or elements equivalent thereto under different ABAC syntax may be associated with a Condition element, a Target element and may be associated with a value of a variable indicating the effect of the Rule element (e.g. to permit access or deny access), which effect is to be executed by the access control mechanism if certain requirements are fulfilled. More precisely, when a policy decision point evaluates an access request against an ABAC policy, the effect configured for a given Rule element may be executed by an access control mechanism (e.g., a policy enforcement point) when both the requirements in the Condition element and the requirements in the Target element are fulfilled. A preferred order of execution is to initially evaluate the requirement set forth in the Target element and then, if this requirement is fulfilled, to go on to the requirement defined in the Condition element.
A symbol representing a Rule element is preferably provided with a toggle switch (e.g., a two-position slider, as shown at item 113 in
A Target element may be shown, for instance in the editable field 112 of
wherein “Indet.” denotes an error state (Indeterminate), and it is understood that a positive integer value is assigned to each occurrence of N independently of the other occurrences. In view hereof, the simplest possible Target element is of the following form:
Target(AnyOf(AllOf(Match( . . . )))),
wherein the final Match element contains a comparison in terms of string, Boolean, float, integer, date or other values of to attributes, as defined by an administrator or author of the ABAC policy. An example grammar from standardized policy syntax may found in OASIS Standard XACML Release 3.0, in sections 5.6-5.9 and 7.6-7.7 in particular.
The following example Target-compliant expression,
may be transformed into a corresponding Boolean expression, as follows:
(A==a) AND ((B==b) OR ((C==c) AND (D==d)) OR (E==e)). (1)
It is understood that Boolean true/false are taken to correspond to Match/No match, and the error state Indeterminate is not handled. Here, uppercase letters may refer to attributes and lowercase letters may refer to constants; the operator “==” may express a general relationship, such as inequality, equality, inclusion, and may act upon data of an arbitrary type. It is noted for completeness that comparisons of two attributes may generally be defined as well.
While some users of the administrator interface, in particular non-experts in ABAC, may experience difficulties in forming Target-compliant expressions, the users are oftentimes familiar with Boolean formalism. For this reason, in example embodiments, the administrator interface accepts input of Target-type expressions in graphical format and is configured to translate such expressions into a textual representation compliant with the Target-type grammar explained above. The graphical format is a tree-like structure, in which comparisons such as “A==a” are found at leaves, and names or symbols for the Boolean operators AND and OR are indicated at bifurcation points of the structure. As an illustration, a graphical representation of the expression in equation (1) is depicted in
In example embodiments, the editable field 112 is further provided with controls for editing the graphical representation shown therein. Such controls may correspond to the actions “Add AND bifurcation”, “Add OR bifurcation”, “Delete subtree” and/or aids for entering comparisons including an attribute dictionary (or menu), a comparison operator menu. Furthermore, each Match element carries an indication (e.g., a colourful dot) indicating a status of required presence. This is to say, the absence of an attribute value to which the Match element refers is not taken to imply that the comparison is trivially true; instead, if required presence has been indicated the Match element outputs an error state.
As an alternative to structures of the type shown in
A constructive process for generating a structure of the type exemplified in
It is furthermore possible to design a converse process, wherein a semi-graphical tree structure of the type exemplified in
Although the above description of the Target element has been made in connection with the Rule element, a Target element may be associated with a Policy or PolicySet element as well and may then be visualized in a similar manner. In XACML for instance, the Target element identifies the set of access requests (decision requests) that the parent element is intended to evaluate. A Target element appears as a child of a PolicySet and Policy element and may appear as a child of a Rule element.
In an example embodiment, a textual representation is used for displaying and editing Condition elements in Rule, Policy and PolicySet elements of an ABAC policy. Preferably, the administrator interface includes a mode in which the Condition element is edited in a simplified language, such as the Axiomatics Language For Authorization (ALFA), based on which syntax-compliant (e.g. XACML-compliant) policy text is generated. Because ALFA is syntactically similar to Java and C#, it may enable and administrator to develop and edit ABAC policies more easily.
In an example embodiment, fields in the graphical representation that are configured to receive text input, such as the editable fields 111, 112 shown in
Alternatively or additionally, fields for text entry may be equipped with syntax consistency aids, such as one or more of: bracket matching, automatic indentation, highlighting of reserved words, highlighting of defined attributes and automatic syntax consistency verification, wherein the syntax consistency verification may be operating continually or upon user request. In an example embodiment, each Rule, Policy or PolicySet element carries an indicator of whether all information that is mandatory to fulfil syntactic consistency requirements has been entered, or whether the user has yet to make supplementary inputs. The indicator is visible in the normal mode, not only in the metadata edit mode. The element may further carry an indication of a named user responsible for completing its required data fields. The named user may be automatically allocated, say, based on characteristics of a resource to which the represented Rule, Policy or PolicySet element applies, or may be entered by one of the users of the administrator interface.
In an example embodiment, there is provided a functionality indicating all changes made since the beginning of the current session, since the last “apply” command, since the latest saving of a draft copy, or the like. The changes may be indicated explicitly, or symbols of such elements whose data have been edited may be indicated. The indicating of changes may relate to highlighting by an distinctive colour, typeface or use of dedicated markers.
In an example embodiment, a user of the administrator interface may edit the ABAC policy by manipulating certain symbols of the graphical representation. For instance, an adapted drag-and-drop functionality may be available. The adapted drag-and-drop functionality allows a user to activate a symbol (e.g. a Rule, Policy or PolicySet element) by cursor action and to indicate, in a similar fashion, a destination in the graphical representation. Inter alia, rules along the following lines may apply:
Even though the present disclosure describes and depicts specific example embodiments, the invention is not restricted to these specific examples. Modifications and variations to the above example embodiments can be made without departing from the scope of the invention, which is defined by the accompanying claims only.
The devices and methods disclosed above may be implemented as software, firmware, hardware or a combination thereof. In a hardware implementation, the division of tasks between functional units referred to in the above description does not necessarily correspond to the division into physical units; to the contrary, one physical component may have multiple functionalities, and one task may be carried out in a distributed fashion, by several physical components in cooperation. Certain components or all components may be implemented as software executed by a digital processor, signal processor or microprocessor, or be implemented as hardware or as an application-specific integrated circuit. Such software may be distributed on computer readable media, which may comprise computer storage media (or non-transitory media) and communication media (or transitory media). As is well known to a person skilled in the art, the term computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by a computer. Further, it is well known to the skilled person that communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media.
| Number | Date | Country | Kind |
|---|---|---|---|
| 1550137-2 | Feb 2015 | SE | national |
