Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “image generation unit” in claims 1, 3,-8.
“an information addition unit” in claim 2.
“an attribute value input unit” in claim 4.
“a policy generation unit”; “an attribute value determination unit” in claim 5
“an attribute value input unit “ in claim 7.
“a policy generation unit”; “an attribute value determination unit” in claim 8
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
1. Claims 1-12 are rejected under 35 U.S.C. 103 as being unpatentable over Reeder, Robert W., NPL, Expandable Grids: A user interface visualization technique and a policy semantics to support fast, accurate security and privacy policy authoring. Carnegie Mellon University, 2008. (“Reeder”) in view of NEVATIA et al, EP3757843A1
(“NEVATIA”)
Regarding independent claim 1, Reeder teaches an access policy display device (see at least 3.5.2 Apparatus, “All participants solved a series of permission-setting tasks on a computer running Windows XP, Version 2002, Service Pack 1, using either the XPFP or Salmon permission-setting user interface. Timestamped screen video and mouse and keyboard actions were recorded with a software tool developed for user study data collection. Participants’ initial and final permissions settings were recorded for each task instance.”) comprising:
an image generation unit (see at least 3.5.2 Apparatus, “All participants solved a series of permission-setting tasks on a computer running Windows XP, Version 2002, Service Pack 1, using either the XPFP or Salmon permission-setting user interface. Timestamped screen video and mouse and keyboard actions were recorded with a software tool developed for user study data collection. Participants’ initial and final permissions settings were recorded for each task instance”) which sets an image region for each combination of an attribute value of one attribute and an attribute value of another attribute in two attributes selected from two or more attributes constituting a condition of an access policy (see at least 5.3 The Expandable Grid concept An Expandable Grid is a two-dimensional interactive matrix display. When displaying a policy in an Expandable Grid, two of the policy’s attributes can be selected for display along the Expandable Grid’s two axes. The attributes’ values become the labels along the horizontal and vertical axes of the Expandable Grid. The labels define columns and rows that constitute a grid. At the intersection of each column and each row is a grid cell, which contains a graphical representation (such as a colored square) of the policy’s decision for the values corresponding to the column and row labels. For an Expandable Grid to be truly expandable, and not just a static table, at least one of the two displayed attributes should have its values arranged in a hierarchy, which can be displayed along an Expandable Grid axis in an interactive tree, such as a Java Swing JTree component [84]. The interactive tree or trees along the axes of an Expandable Grid can be expanded to show more of a hierarchy’s values or contracted to show fewer. When such expansion or contraction takes place, rows or columns are added to or removed from the grid, so that each visible hierarchy node always has a corresponding visible row or column (see Figure 5.1). ,
a degree of access permission or access denial in a plurality of the combinations (see at least 4.1 Policy Authoring Defined “Policy” can mean many things in different contexts, so it is important to give a definition that is germane to the present work on security and privacy policies. For the purposes of this work, a policy is defined as a function that maps sets of elements (tuples) onto a discrete set of results, typically the set {ALLOW, DENY} (however, other result sets are possible; for example, Lederer et al. describe a policy-based privacy system in which tuples representing requests for a person’s location are mapped to the set {PRECISE, APPROXIMATE, VAGUE, UNDISCLOSED} [78]). Elements are defined as the attributes relevant to a specific policy domain; the values those attributes can take on are referred to as element values. Element values may be literal values, such as the username “jsmith,” or they may be expressions, such as “if the customer has opted in.” Policies are expressed through rules, which are statements of specific mappings of tuples to results. Policy authoring is the task of specifying the element values in a domain, specifying rules involving those elements, and verifying that the policy comprised by those rules matches the policy that is intended. In the privacy policy domain, for example, a policy maps tuples of the form (, , , , ) to the set {ALLOW, DENY} [10]. Here, user category, action, data category, purpose, and condition are elements. ALLOW and DENY are results. An example privacy policy rule would map the tuple (“Marketing Reps,” “use,” “customer address,” “mailing advertisements,” “the customer has opted in”) to the value ALLOW, indicating that marketing representatives can use the customer address data field for the purpose of mailing advertisements if the customer has opted in. Here, “Marketing Reps,” “use,” “customer address,” “mailing advertisements,” and “the customer has opted in” are element values. To take another example, in the file permissions domain, a policy maps tuples of the form (, , ) to the set ALLOW, DENY. An example rule might map (“jsmith,” “execute,” “calculator.exe”) to the value DENY, indicating that the user jsmith cannot execute the program calculator.exe. Since the rules in a policy may not cover all possible tuples, policy-based security and privacy systems typically have a default rule. For example, the SPARCLE system has the default rule that all 5-tuples of (, , , , ) map to DENY. Additional rules are specified by policy authors and all author-specified rules map a 5-tuple to ALLOW. The default rule need not necessarily be a default DENY; a default ALLOW is also possible (policies with a default ALLOW rule are often called “blacklists,” because any element value listed explicitly in the policy is denied access), or the default can vary according to some values in the tuples (for instance, a default rule might state that all accesses to shared files on a computer are allowed by default to local users but denied by default to remote users). Similarly, user-specified rules need not necessarily map exclusively to ALLOW or exclusively to DENY; it is possible to allow users to specify rules that map to either ALLOW or DENY. However, policy.”; 5.1.1 File access control as an example policy-authoring domain “In a basic file access control system, there are resources, principals, and actions. Resources are files and folders, the data to which access is to be controlled. Principals are system users, processes, computers, and other entities that may attempt to access resources. Actions are operations that may be performed on resources, such as “read,” “write,” “execute,” and “delete.” A request is an attempt by a principal to perform an action on a resource. A request can be represented as a set of principal, action, and resource. We call the components of a request, i.e., principal, action, and resource, attributes, and specific values for principal, action, and resource values. To give an example of these concepts, a request by a user named jsmith to execute a file called calculator.exe could be represented as the tuple (“jsmith,” “execute,” “calculator.exe”). The values would be “jsmith,” “execute,” and “calculator.exe.” A policy is a function that maps requests to results, which are drawn from the result set {ALLOW, DENY}, indicating whether the request is granted or not. We call a specific mapping of values to a resulta decision. The actual decisions that will be issued by a policy are specified by policy authors, or simply authors, who are people authorized to control resources. Policy authors might be system administrators who control many resources for an organization or end users who may control files or personal information belonging to them that resides on organizational systems or in their own pervasive devices. Policy authors often specify policies as a set of rules. A rule is a statement of a specific mapping of one or more requests (each consisting of a principal, action, and resource) to a result. For example, a rule might map the request (“jsmith,” “execute,” “calculator.exe”) to the decision DENY, indicating that the user jsmith cannot execute the program calculator.exe. If a policy author put this rule into place, then if the request (“jsmith,” “execute,” “calculator.exe”) were made, the access control system’s decision would be to output DENY. Because a given set of rules may not apply to all possible requests, a file access control system will have a default rule that indicates whether requests are allowed or denied by default. A typical default rule is default-deny, which states that all requests not explicitly granted by other rules are denied. A defaultallow is also possible (spam or firewall “blacklists” are examples of default-allow policies) or the default rule can produce both ALLOW and DENY decisions depending on input values (for instance, a default rule might state that all accesses to shared files on a computer are allowed by default to local users but denied by default to remote users). Since a file system may have thousands of principals and files, file access control systems typically provide a means for constructing composite values, which are collections of values. Values that are not composite are atomic values). For instance, in hierarchical file systems, files are naturally aggregated into folders and folders into higher-level folders. Principals might be placed into groups or roles according to their position in an organization, such as “Executives,” “Managers,” and “Employees.” (The term “role” comes from role-based access control, in which a role is a construct for associating principals with actions and resources according to organizational functions [115].) Specific files and users are atomic values while folders and groups or roles are composite values. Groups and folders allow policy authors to write rules that apply to all components of a composite value, such as a rule that denies access to all employees to delete files in a folder called “Critical files.” Composite values thus allow for more succinct policies, since a single rule can apply to many input values, such as any of multiple employees. Composite values also allow for policies that cover as-yet-unknown input values; the example rule above would apply to any future employees or future files added to the “Critical files” folder.”), and
generates an image in which a plurality of the image regions is displayed that allows for distinguishing the degree; and a display which displays the image (see at least 5.3.1.1 Pop-out effects “Visual pop-out” is a perceptual phenomenon in which a object in a visual search space is immediately distinguishable to a viewer from other objects in the space [130, 109, 136]. Pop-out may occur because an object’s orientation, shape, color, motion, or other visual feature is different from most objects in the visual scene. In an Expandable Grid in which colored squares are used to represent policy decisions, visual pop-out makes it easy to spot anomalies. For example, if, in a file permissions policy, a particular group is meant to be denied access to all files in a particular folder, and red squares represent DENY decisions in an Expandable Grid display of the policy, any green squares representing errant ALLOW decisions would pop out and be easily recognized by a policy author.
PNG
media_image1.png
298
520
media_image1.png
Greyscale
Reeder is understood to be silent on the remaining limitations of claim 1.
In the same field of endeavor, NEVATIA teaches an image generation unit ( [0055] of NEVATIA “Fig. 3 is a diagram of example components of a device 300. Device 300 may correspond to client device 210, server device 220, security monitoring platform 230, computing resource 245, and/or the like. In some implementations, client device 210, server device 220, security monitoring platform 230, and/or computing resource 245 may include one or more devices 300 and/or one or more components of device 300. As shown in Fig. 3, device 300 may include a bus 310, a processor 320, a memory 330, a storage component 340, an input component 350, an output component 360, and/or a communication interface 370.”)calculates a degree of access permission or access denial in a plurality of the combinations (see at least [0031]As further shown in Fig. 1B, and by reference number 125, the security monitoring platform may determine a probability score for the current access rights assigned to the user based on the access rights data model that was generated and trained using the combination of unsupervised and supervised machine learning techniques, as described in further detail above. For example, in some implementations, the security monitoring platform may determine a set of features that relate to the user (e.g., a job title, clearance level, employment status, and/or the like), which may be input to the access rights data model to predict an access level, set of permissions, and/or the like that maps to the set of features that relate to the user. Accordingly, the security monitoring platform may compare the current access rights assigned to the user and the access level, the set of permissions, and/or the like that is predicted using the access rights data model, and the probability score may represent a probability that the current access rights assigned to the user are correct. For example, if the user is associated with various attributes or features that are consistent with a restricted access level (e.g., read-only access, unauthorized access) but the user has a critical access level that provides unrestricted access, the probability score may have a low value to indicate that the access level assigned to the user may need to be revoked or revised. In contrast, if the user is associated with various attributes or features that are consistent with the critical access level (e.g., a system administrator role, a high clearance level, and/or the like) or the permissions assigned to the user are limited to the restricted access level, the probability score may have a high value to indicate that the access level assigned to the user is likely correct.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the method of displaying a policy in an Expandable Grid of Reeder with determine probability score for the current access rights assigned to the user of NEVATIA because this modification would indicate the current access rights assigned to the user are correct or not ([0031] of NEVATIA)
Thus, the combination of Reeder and NEVATIA teaches an access policy display device comprising: an image generation unit which sets an image region for each combination of an attribute value of one attribute and an attribute value of another attribute in two attributes selected from two or more attributes constituting a condition of an access policy, calculates a degree of access permission or access denial in a plurality of the combinations, and generates an image in which a plurality of the image regions is displayed that allows for distinguishing the degree; and a display which displays the image.
Regarding claim 2, Reeder and NEVATIA teach the access policy display device according to claim 1, further comprising an information addition unit which superimposes access-related information related to access permission or access denial on the image (see at least Reeder:5.3.2.3 More than two attributes The Expandable Grid can accommodate two policy attributes on each of its two axes, but when a policy has more than two attributes, other solutions must be devised. In our file-permissions Expandable Grid, the principal and resource attributes are displayed along the axes, but a third attribute, action, had to be displayed as well. Our solution was to use a subgrid, which is a set of small squares within the larger square of each grid cell. Each square of the subgrid represents an action—for example, for the five-square subgrids in the grid cells shown in Figure 5.2, the upper left square of each subgrid represents “read,” the upper right square represents “write,” the middle left square represents “execute,” the middle right square represents “delete,” and the lower square represents “administrate,” as indicated in the interface’s legend. The subgrids can create visual clutter, but our interface allows the policy author to select only a subset of actions to show in the subgrid. For example, Figure 5.3 shows subgrids of two squares that only show “read” and “write.” The subgrid solution is not scalable; although we did not test its limits, it cannot be expected to show attributes with more than 10 or so values.”; [0035];[0055] of NEVATIA “Fig. 3 is a diagram of example components of a device 300. Device 300 may correspond to client device 210, server device 220, security monitoring platform 230, computing resource 245, and/or the like. In some implementations, client device 210, server device 220, security monitoring platform 230, and/or computing resource 245 may include one or more devices 300 and/or one or more components of device 300. As shown in Fig. 3, device 300 may include a bus 310, a processor 320, a memory 330, a storage component 340, an input component 350, an output component 360, and/or a communication interface 370.”) In addition, the same motivation is used as the rejection for claim 1.
PNG
media_image2.png
484
514
media_image2.png
Greyscale
where showing R, W is considered as superimposes access-related information related to access permission or access denial on the image)
Regarding claim 3, Reeder and NEVATIA teach the access policy display device according to claim 1, wherein the image generation unit generates a plurality of images with different types of combinations of the two attributes, the display displays the plurality of images on a single screen (see at least section 5 with Figure 5.2 of Reeder; [0031];[0035]” Accordingly, as shown in Fig. 1C, and by reference number 135, the security monitoring platform may receive, from a client device, feedback regarding an outcome from the action that was performed in relation to the current access rights assigned to the user. For example, the client device may be operated by an administrator or other user authorized to apply changes to the user access rights within the cloud applications, and information related to the action performed by the security monitoring platform may be communicated to the client device to enable manual intervention and/or human oversight over the actions performed by the security monitoring platform. Accordingly, the information related to the action performed by the security monitoring platform may be displayed on the client device (e.g., in a dashboard or other interface that indicates the action that was performed, the attributes or features that were the basis of the action, the probability score on which the action was based, and/or the like). Accordingly, the user operating the client device may review the action that was performed to maintain, revoke, elevate, modify, and/or revise the current access rights assigned to the user, and the user may provide feedback by approving, rejecting, or revising the action. Additionally, or alternatively, the security monitoring platform may receive one or more user-defined rules from the client device (e.g., to define certain access control policies, access levels, and/or the like), and the one or more user-defined rules may be used in combination with the probability score described in more detail elsewhere herein to determine the action to be performed in relation to the current access rights assigned to one or more users”;; [0055] of NEVATIA “Fig. 3 is a diagram of example components of a device 300. Device 300 may correspond to client device 210, server device 220, security monitoring platform 230, computing resource 245, and/or the like. In some implementations, client device 210, server device 220, security monitoring platform 230, and/or computing resource 245 may include one or more devices 300 and/or one or more components of device 300. As shown in Fig. 3, device 300 may include a bus 310, a processor 320, a memory 330, a storage component 340, an input component 350, an output component 360, and/or a communication interface 370.”) In addition, the same motivation is used as the rejection for claim 1.
PNG
media_image3.png
490
492
media_image3.png
Greyscale
Regarding claim 4, Reeder and NEVATIA teach the access policy display device according to claim 3, further comprising an attribute value input unit which accepts input of the attribute value, wherein the image generation unit generates the image by fixing the attribute value of attribute to the input attribute value (see at least 5.3 The Expandable Grid concept An Expandable Grid is a two-dimensional interactive matrix display. When displaying a policy in an Expandable Grid, two of the policy’s attributes can be selected for display along the Expandable Grid’s two axes. The attributes’ values become the labels along the horizontal and vertical axes of the Expandable Grid. The labels define columns and rows that constitute a grid. At the intersection of each column and each row is a grid cell, which contains a graphical representation (such as a colored square) of the policy’s decision for the values corresponding to the column and row labels. For an Expandable Grid to be truly expandable, and not just a static table, at least one of the two displayed attributes should have its values arranged in a hierarchy, which can be displayed along an Expandable Grid axis in an interactive tree, such as a Java Swing JTree component [84]. The interactive tree or trees along the axes of an Expandable Grid can be expanded to show more of a hierarchy’s values or contracted to show fewer. When such expansion or contraction takes place, rows or columns are added to or removed from the grid, so that each visible hierarchy node always has a corresponding visible row or column (see Figure 5.1).”; [0031-0035][0055] of NEVATIA “Fig. 3 is a diagram of example components of a device 300. Device 300 may correspond to client device 210, server device 220, security monitoring platform 230, computing resource 245, and/or the like. In some implementations, client device 210, server device 220, security monitoring platform 230, and/or computing resource 245 may include one or more devices 300 and/or one or more components of device 300. As shown in Fig. 3, device 300 may include a bus 310, a processor 320, a memory 330, a storage component 340, an input component 350, an output component 360, and/or a communication interface 370.)
Regarding claim 5, Reeder and NEVATIA teach the access policy display device according to claim 3, further comprising:
a policy generation unit which generates the access policy based on policy definition information (see at least Reeder: 5.1.3 Notes on the definitions of policy and policy authoring One could define a policy as a set of rules. However, we have intentionally defined a policy as a function, and stated that a set of rules is merely a means for specifying a policy rather than the definition of a policy. We make this distinction because many of today’s list-of-rules policy-authoring user interfaces imply that a policy is merely the sum of a set of rules, and fail to make users aware that because of default rules, composite values, rule conflicts, and precedence rules, a policy is actually more than the sum of the rules a user specifies. With our visualization-centered approach to policy-authoring interface design, a policy is presented to users as a function that maps requests to results, so users will see exactly what decisions their policies will result in, rather than have to reconstruct policies in their heads by taking their own rules, default rules, composite values, and precedence rules into account. We sometimes use the term effective policy to clearly distinguish our notion of policy as a function from the notion of a set of rules. Effective policy is the function that results from a set of rules after the application of defaults and the resolution of conflicts; [0033]; [0035] of NEVATIA “Accordingly, as shown in Fig. 1C, and by reference number 135, the security monitoring platform may receive, from a client device, feedback regarding an outcome from the action that was performed in relation to the current access rights assigned to the user. For example, the client device may be operated by an administrator or other user authorized to apply changes to the user access rights within the cloud applications, and information related to the action performed by the security monitoring platform may be communicated to the client device to enable manual intervention and/or human oversight over the actions performed by the security monitoring platform. Accordingly, the information related to the action performed by the security monitoring platform may be displayed on the client device (e.g., in a dashboard or other interface that indicates the action that was performed, the attributes or features that were the basis of the action, the probability score on which the action was based, and/or the like). Accordingly, the user operating the client device may review the action that was performed to maintain, revoke, elevate, modify, and/or revise the current access rights assigned to the user, and the user may provide feedback by approving, rejecting, or revising the action. Additionally, or alternatively, the security monitoring platform may receive one or more user-defined rules from the client device (e.g., to define certain access control policies, access levels, and/or the like), and the one or more user-defined rules may be used in combination with the probability score described in more detail elsewhere herein to determine the action to be performed in relation to the current access rights assigned to one or more users.”)
and an attribute value determination unit which determines the attribute value based on the policy definition information (see at least Reeder: 4.1 Policy Authoring Defined “Policy” can mean many things in different contexts, so it is important to give a definition that is germane to the present work on security and privacy policies. For the purposes of this work, a policy is defined as a function that maps sets of elements (tuples) onto a discrete set of results, typically the set {ALLOW, DENY} (however, other result sets are possible; for example, Lederer et al. describe a policy-based privacy system in which tuples representing requests for a person’s location are mapped to the set {PRECISE, APPROXIMATE, VAGUE, UNDISCLOSED} [78]). Elements are defined as the attributes relevant to a specific policy domain; the values those attributes can take on are referred to as element values. Element values may be literal values, such as the username “jsmith,” or they may be expressions, such as “if the customer has opted in.” Policies are expressed through rules, which are statements of specific mappings of tuples to results. Policy authoring is the task of specifying the element values in a domain, specifying rules involving those elements, and verifying that the policy comprised by those rules matches the policy that is intended. In the privacy policy domain, for example, a policy maps tuples of the form (, , , , ) to the set {ALLOW, DENY} [10]. Here, user category, action, data category, purpose, and condition are elements. ALLOW and DENY are results. An example privacy policy rule would map the tuple (“Marketing Reps,” “use,” “customer address,” “mailing advertisements,” “the customer has opted in”) to the value ALLOW, indicating that marketing representatives can use the customer address data field for the purpose of mailing advertisements if the customer has opted in. Here, “Marketing Reps,” “use,” “customer address,” “mailing advertisements,” and “the customer has opted in” are element values. To take another example, in the file permissions domain, a policy maps tuples of the form (, , ) to the set ALLOW, DENY. An example rule might map (“jsmith,” “execute,” “calculator.exe”) to the value DENY, indicating that the user jsmith cannot execute the program calculator.exe”; section 5.1.1 File access control as an example policy-authoring domain “In a basic file access control system, there are resources, principals, and actions. Resources are files and folders, the data to which access is to be controlled. Principals are system users, processes, computers, and other entities that may attempt to access resources. Actions are operations that may be performed on resources, such as “read,” “write,” “execute,” and “delete.” A request is an attempt by a principal to perform an action on a resource. A request can be represented as a set of principal, action, and resource. We call the components of a request, i.e., principal, action, and resource, attributes, and specific values for principal, action, and resource values. To give an example of these concepts, a request by a user named jsmith to execute a file called calculator.exe could be represented as the tuple (“jsmith,” “execute,” “calculator.exe”). The values would be “jsmith,” “execute,” and “calculator.exe.” A policy is a function that maps requests to results, which are drawn from the result set {ALLOW, DENY}, indicating whether the request is granted or not. We call a specific mapping of values to a result A policy is a function that maps requests to results, which are drawn from the result set {ALLOW, DENY}, indicating whether the request is granted or not. We call a specific mapping of values to a resulta decision. The actual decisions that will be issued by a policy are specified by policy authors, or simply authors, who are people authorized to control resources. Policy authors might be system administrators who control many resources for an organization or end users who may control files or personal information belonging to them that resides on organizational systems or in their own pervasive devices. Policy authors often specify policies as a set of rules. A rule is a statement of a specific mapping of one or more requests (each consisting of a principal, action, and resource) to a result. For example, a rule might map the request (“jsmith,” “execute,” “calculator.exe”) to the decision DENY, indicating that the user jsmith cannot execute the program calculator.exe. If a policy author put this rule into place, then if the request (“jsmith,” “execute,” “calculator.exe”) were made, the access control system’s decision would be to output DENY..”; [0032] of NEVATIA “As further shown in Fig. 1B, and by reference number 130, the security monitoring platform may perform an action related to the current access rights assigned to the user based on the probability score. For example, in some implementations, the action may include maintaining the current access rights based on the probability score satisfying a threshold that indicates that the current access level is likely correct (e.g., the current access level is consistent with a predicted access level that the access rights data model maps to a set of attributes or features associated with the user). In other examples, the action may include revoking or elevating the current access rights assigned to the user based on the probability score satisfying a threshold that indicates that the current access level is likely incorrect (e.g., the current access level is inconsistent with the predicted access level that the access rights data model maps to the set of attributes or features associated with the user). For example, where the access rights data model maps the set of attributes or features associated with the user to a restricted or limited access level and the probability score indicates that the current access level is likely incorrect, the action may include revoking or revising the current access rights assigned to the user. In another example, where the access rights data model maps the set of attributes or features associated with the user to a critical (e.g., unrestricted) access level and the probability score indicates that the current access level is likely incorrect, the action may include elevating the current access rights assigned to the user to another profile with a greater level of access.)., wherein the image generation unit generates the image by fixing the attribute value of attribute to the determined attribute value (see at least Reeder: chapter 5, section 5.3 “The Expandable Grid concept An Expandable Grid is a two-dimensional interactive matrix display. When displaying a policy in an Expandable Grid, two of the policy’s attributes can be selected for display along the Expandable Grid’s two axes. The attributes’ values become the labels along the horizontal and vertical axes of the Expandable Grid. The labels define columns and rows that constitute a grid. At the intersection of each column and each row is a grid cell, which contains a graphical representation (such as a colored square) of the policy’s decision for the values corresponding to the column and row labels. For an Expandable Grid to be truly expandable, and not just a static table, at least one of the two displayed attributes should have its values arranged in a hierarchy, which can be displayed along an Expandable Grid axis in an interactive tree, such as a Java Swing JTree component [84]. The interactive tree or trees along the axes of an Expandable Grid can be expanded to show more of a hierarchy’s values or contracted to show fewer. When such expansion or contraction takes place, rows or columns are added to or removed from the grid, so that each visible hierarchy node always has a corresponding visible row or column (see Figure 5.1).”; [0032]-[0035] of NEVATIA) In addition, the same motivation is used as the rejection for claim 1.
Regarding claim 6, Reeder and NEVATIA teach the access policy display device according to claim 2, Remaining limitations of claim 6 is similar in scope to claim 3 and therefore rejected under the same rationale.
Regarding claim 7, Reeder and NEVATIA teach the access policy display device according to claim 6, further comprising: Remaining limitations of claim 7 is similar in scope to claim 4 and therefore rejected under the same rationale.
Regarding claim 8, Reeder and NEVATIA teach the access policy display device according to claim 6, further comprising: Remaining limitations of claim 8 is similar in scope to claim 5 and therefore rejected under the same rationale.
Regarding claim 9, Reeder teaches an access policy display method comprising: setting an image region for each combination of an attribute value of one attribute and an attribute value of another attribute in two attributes selected from two or more attributes constituting a condition of an access policy (see at least 5.3 The Expandable Grid concept An Expandable Grid is a two-dimensional interactive matrix display. When displaying a policy in an Expandable Grid, two of the policy’s attributes can be selected for display along the Expandable Grid’s two axes. The attributes’ values become the labels along the horizontal and vertical axes of the Expandable Grid. The labels define columns and rows that constitute a grid. At the intersection of each column and each row is a grid cell, which contains a graphical representation (such as a colored square) of the policy’s decision for the values corresponding to the column and row labels. For an Expandable Grid to be truly expandable, and not just a static table, at least one of the two displayed attributes should have its values arranged in a hierarchy, which can be displayed along an Expandable Grid axis in an interactive tree, such as a Java Swing JTree component [84]. The interactive tree or trees along the axes of an Expandable Grid can be expanded to show more of a hierarchy’s values or contracted to show fewer. When such expansion or contraction takes place, rows or columns are added to or removed from the grid, so that each visible hierarchy node always has a corresponding visible row or column (see Figure 5.1). ,
a degree of access permission or access denial in a plurality of the combinations (see at least 4.1 Policy Authoring Defined “Policy” can mean many things in different contexts, so it is important to give a definition that is germane to the present work on security and privacy policies. For the purposes of this work, a policy is defined as a function that maps sets of elements (tuples) onto a discrete set of results, typically the set {ALLOW, DENY} (however, other result sets are possible; for example, Lederer et al. describe a policy-based privacy system in which tuples representing requests for a person’s location are mapped to the set {PRECISE, APPROXIMATE, VAGUE, UNDISCLOSED} [78]). Elements are defined as the attributes relevant to a specific policy domain; the values those attributes can take on are referred to as element values. Element values may be literal values, such as the username “jsmith,” or they may be expressions, such as “if the customer has opted in.” Policies are expressed through rules, which are statements of specific mappings of tuples to results. Policy authoring is the task of specifying the element values in a domain, specifying rules involving those elements, and verifying that the policy comprised by those rules matches the policy that is intended. In the privacy policy domain, for example, a policy maps tuples of the form (, , , , ) to the set {ALLOW, DENY} [10]. Here, user category, action, data category, purpose, and condition are elements. ALLOW and DENY are results. An example privacy policy rule would map the tuple (“Marketing Reps,” “use,” “customer address,” “mailing advertisements,” “the customer has opted in”) to the value ALLOW, indicating that marketing representatives can use the customer address data field for the purpose of mailing advertisements if the customer has opted in. Here, “Marketing Reps,” “use,” “customer address,” “mailing advertisements,” and “the customer has opted in” are element values. To take another example, in the file permissions domain, a policy maps tuples of the form (, , ) to the set ALLOW, DENY. An example rule might map (“jsmith,” “execute,” “calculator.exe”) to the value DENY, indicating that the user jsmith cannot execute the program calculator.exe. Since the rules in a policy may not cover all possible tuples, policy-based security and privacy systems typically have a default rule. For example, the SPARCLE system has the default rule that all 5-tuples of (, , , , ) map to DENY. Additional rules are specified by policy authors and all author-specified rules map a 5-tuple to ALLOW. The default rule need not necessarily be a default DENY; a default ALLOW is also possible (policies with a default ALLOW rule are often called “blacklists,” because any element value listed explicitly in the policy is denied access), or the default can vary according to some values in the tuples (for instance, a default rule might state that all accesses to shared files on a computer are allowed by default to local users but denied by default to remote users). Similarly, user-specified rules need not necessarily map exclusively to ALLOW or exclusively to DENY; it is possible to allow users to specify rules that map to either ALLOW or DENY. However, policy.”; 5.1.1 File access control as an example policy-authoring domain “In a basic file access control system, there are resources, principals, and actions. Resources are files and folders, the data to which access is to be controlled. Principals are system users, processes, computers, and other entities that may attempt to access resources. Actions are operations that may be performed on resources, such as “read,” “write,” “execute,” and “delete.” A request is an attempt by a principal to perform an action on a resource. A request can be represented as a set of principal, action, and resource. We call the components of a request, i.e., principal, action, and resource, attributes, and specific values for principal, action, and resource values. To give an example of these concepts, a request by a user named jsmith to execute a file called calculator.exe could be represented as the tuple (“jsmith,” “execute,” “calculator.exe”). The values would be “jsmith,” “execute,” and “calculator.exe.” A policy is a function that maps requests to results, which are drawn from the result set {ALLOW, DENY}, indicating whether the request is granted or not. We call a specific mapping of values to a resulta decision. The actual decisions that will be issued by a policy are specified by policy authors, or simply authors, who are people authorized to control resources. Policy authors might be system administrators who control many resources for an organization or end users who may control files or personal information belonging to them that resides on organizational systems or in their own pervasive devices. Policy authors often specify policies as a set of rules. A rule is a statement of a specific mapping of one or more requests (each consisting of a principal, action, and resource) to a result. For example, a rule might map the request (“jsmith,” “execute,” “calculator.exe”) to the decision DENY, indicating that the user jsmith cannot execute the program calculator.exe. If a policy author put this rule into place, then if the request (“jsmith,” “execute,” “calculator.exe”) were made, the access control system’s decision would be to output DENY. Because a given set of rules may not apply to all possible requests, a file access control system will have a default rule that indicates whether requests are allowed or denied by default. A typical default rule is default-deny, which states that all requests not explicitly granted by other rules are denied. A defaultallow is also possible (spam or firewall “blacklists” are examples of default-allow policies) or the default rule can produce both ALLOW and DENY decisions depending on input values (for instance, a default rule might state that all accesses to shared files on a computer are allowed by default to local users but denied by default to remote users). Since a file system may have thousands of principals and files, file access control systems typically provide a means for constructing composite values, which are collections of values. Values that are not composite are atomic values). For instance, in hierarchical file systems, files are naturally aggregated into folders and folders into higher-level folders. Principals might be placed into groups or roles according to their position in an organization, such as “Executives,” “Managers,” and “Employees.” (The term “role” comes from role-based access control, in which a role is a construct for associating principals with actions and resources according to organizational functions [115].) Specific files and users are atomic values while folders and groups or roles are composite values. Groups and folders allow policy authors to write rules that apply to all components of a composite value, such as a rule that denies access to all employees to delete files in a folder called “Critical files.” Composite values thus allow for more succinct policies, since a single rule can apply to many input values, such as any of multiple employees. Composite values also allow for policies that cover as-yet-unknown input values; the example rule above would apply to any future employees or future files added to the “Critical files” folder.”), and generating an image in which a plurality of the image regions is displayed that allows for distinguishing the degree; and displaying the image (see at least 5.3.1.1 Pop-out effects “Visual pop-out” is a perceptual phenomenon in which a object in a visual search space is immediately distinguishable to a viewer from other objects in the space [130, 109, 136]. Pop-out may occur because an object’s orientation, shape, color, motion, or other visual feature is different from most objects in the visual scene. In an Expandable Grid in which colored squares are used to represent policy decisions, visual pop-out makes it easy to spot anomalies. For example, if, in a file permissions policy, a particular group is meant to be denied access to all files in a particular folder, and red squares represent DENY decisions in an Expandable Grid display of the policy, any green squares representing errant ALLOW decisions would pop out and be easily recognized by a policy author.”) Reeder is understood to be silent on the remaining limitations of claim 9.
In the same field of endeavor, NEVATIA teaches calculating a degree of access permission or access denial in a plurality of the combinations (see at least [0031]As further shown in Fig. 1B, and by reference number 125, the security monitoring platform may determine a probability score for the current access rights assigned to the user based on the access rights data model that was generated and trained using the combination of unsupervised and supervised machine learning techniques, as described in further detail above. For example, in some implementations, the security monitoring platform may determine a set of features that relate to the user (e.g., a job title, clearance level, employment status, and/or the like), which may be input to the access rights data model to predict an access level, set of permissions, and/or the like that maps to the set of features that relate to the user. Accordingly, the security monitoring platform may compare the current access rights assigned to the user and the access level, the set of permissions, and/or the like that is predicted using the access rights data model, and the probability score may represent a probability that the current access rights assigned to the user are correct. For example, if the user is associated with various attributes or features that are consistent with a restricted access level (e.g., read-only access, unauthorized access) but the user has a critical access level that provides unrestricted access, the probability score may have a low value to indicate that the access level assigned to the user may need to be revoked or revised. In contrast, if the user is associated with various attributes or features that are consistent with the critical access level (e.g., a system administrator role, a high clearance level, and/or the like) or the permissions assigned to the user are limited to the restricted access level, the probability score may have a high value to indicate that the access level assigned to the user is likely correct.”) In addition, the same motivation is used as the rejection for claim 1.
Thus, the combination of Reeder and NEVATIA teaches an access policy display method comprising: setting an image region for each combination of an attribute value of one attribute and an attribute value of another attribute in two attributes selected from two or more attributes constituting a condition of an access policy, calculating a degree of access permission or access denial in a plurality of the combinations, and generating an image in which a plurality of the image regions is displayed that allows for distinguishing the degree; and displaying the image.
Regarding claim 10, Reeder and NEVATIA teach the access policy display method according to claim 9, further comprising: Remaining limitations of claim 10 is similar in scope to claim 2 and therefore rejected under the same rationale.
Regarding independent claim 11, Reeder teaches a non-transitory computer readable recording medium storing an access policy display program for causing a computer(see at least 2.4 Information visualization “Information visualization began at the confluence of computer graphics, human-computer interaction, perceptual psychology, and databases [30, 32, 135]. Research in information visualization has produced a wide variety of techniques for displaying large multidimensional datasets on a computer screen and allowing users to quickly pick out patterns in multidimensional data. Here we review those techniques that most closely resemble the Expandable Grid, a two-dimensional interactive table with expandable tree views along its axes. “3.5.2 Apparatus, “All participants solved a series of permission-setting tasks on a computer running Windows XP, Version 2002, Service Pack 1, using either the XPFP or Salmon permission-setting user interface. Timestamped screen video and mouse and keyboard actions were recorded with a software tool developed for user study data collection. Participants’ initial and final permissions settings were recorded for each task instance”) to execute: setting an image region for each combination of an attribute value of one attribute and an attribute value of another attribute in two attributes selected from two or more attributes constituting a condition of an access policy (see at least 5.3 The Expandable Grid concept An Expandable Grid is a two-dimensional interactive matrix display. When displaying a policy in an Expandable Grid, two of the policy’s attributes can be selected for display along the Expandable Grid’s two axes. The attributes’ values become the labels along the horizontal and vertical axes of the Expandable Grid. The labels define columns and rows that constitute a grid. At the intersection of each column and each row is a grid cell, which contains a graphical representation (such as a colored square) of the policy’s decision for the values corresponding to the column and row labels. For an Expandable Grid to be truly expandable, and not just a static table, at least one of the two displayed attributes should have its values arranged in a hierarchy, which can be displayed along an Expandable Grid axis in an interactive tree, such as a Java Swing JTree component [84]. The interactive tree or trees along the axes of an Expandable Grid can be expanded to show more of a hierarchy’s values or contracted to show fewer. When such expansion or contraction takes place, rows or columns are added to or removed from the grid, so that each visible hierarchy node always has a corresponding visible row or column (see Figure 5.1). ,
a degree of access permission or access denial in a plurality of the combinations (see at least 4.1 Policy Authoring Defined “Policy” can mean many things in different contexts, so it is important to give a definition that is germane to the present work on security and privacy policies. For the purposes of this work, a policy is defined as a function that maps sets of elements (tuples) onto a discrete set of results, typically the set {ALLOW, DENY} (however, other result sets are possible; for example, Lederer et al. describe a policy-based privacy system in which tuples representing requests for a person’s location are mapped to the set {PRECISE, APPROXIMATE, VAGUE, UNDISCLOSED} [78]). Elements are defined as the attributes relevant to a specific policy domain; the values those attributes can take on are referred to as element values. Element values may be literal values, such as the username “jsmith,” or they may be expressions, such as “if the customer has opted in.” Policies are expressed through rules, which are statements of specific mappings of tuples to results. Policy authoring is the task of specifying the element values in a domain, specifying rules involving those elements, and verifying that the policy comprised by those rules matches the policy that is intended. In the privacy policy domain, for example, a policy maps tuples of the form (, , , , ) to the set {ALLOW, DENY} [10]. Here, user category, action, data category, purpose, and condition are elements. ALLOW and DENY are results. An example privacy policy rule would map the tuple (“Marketing Reps,” “use,” “customer address,” “mailing advertisements,” “the customer has opted in”) to the value ALLOW, indicating that marketing representatives can use the customer address data field for the purpose of mailing advertisements if the customer has opted in. Here, “Marketing Reps,” “use,” “customer address,” “mailing advertisements,” and “the customer has opted in” are element values. To take another example, in the file permissions domain, a policy maps tuples of the form (, , ) to the set ALLOW, DENY. An example rule might map (“jsmith,” “execute,” “calculator.exe”) to the value DENY, indicating that the user jsmith cannot execute the program calculator.exe. Since the rules in a policy may not cover all possible tuples, policy-based security and privacy systems typically have a default rule. For example, the SPARCLE system has the default rule that all 5-tuples of (, , , , ) map to DENY. Additional rules are specified by policy authors and all author-specified rules map a 5-tuple to ALLOW. The default rule need not necessarily be a default DENY; a default ALLOW is also possible (policies with a default ALLOW rule are often called “blacklists,” because any element value listed explicitly in the policy is denied access), or the default can vary according to some values in the tuples (for instance, a default rule might state that all accesses to shared files on a computer are allowed by default to local users but denied by default to remote users). Similarly, user-specified rules need not necessarily map exclusively to ALLOW or exclusively to DENY; it is possible to allow users to specify rules that map to either ALLOW or DENY. However, policy.”; 5.1.1 File access control as an example policy-authoring domain “In a basic file access control system, there are resources, principals, and actions. Resources are files and folders, the data to which access is to be controlled. Principals are system users, processes, computers, and other entities that may attempt to access resources. Actions are operations that may be performed on resources, such as “read,” “write,” “execute,” and “delete.” A request is an attempt by a principal to perform an action on a resource. A request can be represented as a set of principal, action, and resource. We call the components of a request, i.e., principal, action, and resource, attributes, and specific values for principal, action, and resource values. To give an example of these concepts, a request by a user named jsmith to execute a file called calculator.exe could be represented as the tuple (“jsmith,” “execute,” “calculator.exe”). The values would be “jsmith,” “execute,” and “calculator.exe.” A policy is a function that maps requests to results, which are drawn from the result set {ALLOW, DENY}, indicating whether the request is granted or not. We call a specific mapping of values to a resulta decision. The actual decisions that will be issued by a policy are specified by policy authors, or simply authors, who are people authorized to control resources. Policy authors might be system administrators who control many resources for an organization or end users who may control files or personal information belonging to them that resides on organizational systems or in their own pervasive devices. Policy authors often specify policies as a set of rules. A rule is a statement of a specific mapping of one or more requests (each consisting of a principal, action, and resource) to a result. For example, a rule might map the request (“jsmith,” “execute,” “calculator.exe”) to the decision DENY, indicating that the user jsmith cannot execute the program calculator.exe. If a policy author put this rule into place, then if the request (“jsmith,” “execute,” “calculator.exe”) were made, the access control system’s decision would be to output DENY. Because a given set of rules may not apply to all possible requests, a file access control system will have a default rule that indicates whether requests are allowed or denied by default. A typical default rule is default-deny, which states that all requests not explicitly granted by other rules are denied. A defaultallow is also possible (spam or firewall “blacklists” are examples of default-allow policies) or the default rule can produce both ALLOW and DENY decisions depending on input values (for instance, a default rule might state that all accesses to shared files on a computer are allowed by default to local users but denied by default to remote users). Since a file system may have thousands of principals and files, file access control systems typically provide a means for constructing composite values, which are collections of values. Values that are not composite are atomic values). For instance, in hierarchical file systems, files are naturally aggregated into folders and folders into higher-level folders. Principals might be placed into groups or roles according to their position in an organization, such as “Executives,” “Managers,” and “Employees.” (The term “role” comes from role-based access control, in which a role is a construct for associating principals with actions and resources according to organizational functions [115].) Specific files and users are atomic values while folders and groups or roles are composite values. Groups and folders allow policy authors to write rules that apply to all components of a composite value, such as a rule that denies access to all employees to delete files in a folder called “Critical files.” Composite values thus allow for more succinct policies, since a single rule can apply to many input values, such as any of multiple employees. Composite values also allow for policies that cover as-yet-unknown input values; the example rule above would apply to any future employees or future files added to the “Critical files” folder.”), and generating an image in which a plurality of the image regions is displayed that allows for distinguishing the degree; and displaying the image (see at least 5.3.1.1 Pop-out effects “Visual pop-out” is a perceptual phenomenon in which a object in a visual search space is immediately distinguishable to a viewer from other objects in the space [130, 109, 136]. Pop-out may occur because an object’s orientation, shape, color, motion, or other visual feature is different from most objects in the visual scene. In an Expandable Grid in which colored squares are used to represent policy decisions, visual pop-out makes it easy to spot anomalies. For example, if, in a file permissions policy, a particular group is meant to be denied access to all files in a particular folder, and red squares represent DENY decisions in an Expandable Grid display of the policy, any green squares representing errant ALLOW decisions would pop out and be easily recognized by a policy author.”) Reeder is understood to be silent on the remaining limitations of claim 11.
In the same field of endeavor, NEVATIA teaches a non-transitory computer readable recording medium storing an access policy display program for causing a computer to ([0004] According to some implementations, a non-transitory computer-readable medium may store one or more instructions. The one or more instructions, when executed by one or more processors of a device, may cause the one or more processors”;[0056]) to execute: calculating a degree of access permission or access denial in a plurality of the combinations (see at least [0031]As further shown in Fig. 1B, and by reference number 125, the security monitoring platform may determine a probability score for the current access rights assigned to the user based on the access rights data model that was generated and trained using the combination of unsupervised and supervised machine learning techniques, as described in further detail above. For example, in some implementations, the security monitoring platform may determine a set of features that relate to the user (e.g., a job title, clearance level, employment status, and/or the like), which may be input to the access rights data model to predict an access level, set of permissions, and/or the like that maps to the set of features that relate to the user. Accordingly, the security monitoring platform may compare the current access rights assigned to the user and the access level, the set of permissions, and/or the like that is predicted using the access rights data model, and the probability score may represent a probability that the current access rights assigned to the user are correct. For example, if the user is associated with various attributes or features that are consistent with a restricted access level (e.g., read-only access, unauthorized access) but the user has a critical access level that provides unrestricted access, the probability score may have a low value to indicate that the access level assigned to the user may need to be revoked or revised. In contrast, if the user is associated with various attributes or features that are consistent with the critical access level (e.g., a system administrator role, a high clearance level, and/or the like) or the permissions assigned to the user are limited to the restricted access level, the probability score may have a high value to indicate that the access level assigned to the user is likely correct.”) In addition, the same motivation is used as the rejection for claim 1.
Thus, the combination of Reeder and NEVATIA teaches a non-transitory computer readable recording medium storing an access policy display program for causing a computer to execute: setting an image region for each combination of an attribute value of one attribute and an attribute value of another attribute in two attributes selected from two or more attributes constituting a condition of an access policy, calculating a degree of access permission or access denial in a plurality of the combinations, and generating an image in which a plurality of the image regions is displayed that allows for distinguishing the degree; and displaying the image.
Regarding claim 12 Reeder and NEVATIA teach the non-transitory computer readable recording medium according to claim 11, Remaining limitations of claim 12 is similar in scope to claim 2 and therefore rejected under the same rationale.
Contact
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SARAH LE whose telephone number is (571)270-7842. The examiner can normally be reached Monday: 8AM-4:30PM EST, Tuesday: 8 AM-3:30PM EST, Wednesday: 8AM-2:30PM EST, Thursday and Friday off.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kent Chang can be reached at (571) 272-7667. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SARAH LE/Primary Examiner, Art Unit 2614