DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . 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 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.
Response to Arguments
A pre-appeal conference was held in response to applicant’s pre-appeal brief request on 10/30/2025. The panel was persuaded by the arguments set forth by the applicant in the pre-appeal brief request and a decision to re-open prosecution was mailed on 01/23/2026.
Pursuant to the pre-appeal conference decision, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of newly found prior art.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-3, 7, 12 and 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over Delany (U. S. Pat. No. 7,085,834 B2) (hereinafter “Delany”) in view of Doermann et al. (U. S. Pat. No. 9,218,502 B1) (hereinafter “Doermann”)
Regarding Claim 1, Delany teaches:
A computer-executed method for filesystem access control in an organization- based access control system, comprising (Delany: [Col 8, lines 13-18], (94) Group Manager 44 allows entities to create, delete and manage groups of users who need identical access privileges to a specific resource or set of resources. Managing and controlling privileges for a group of related people--rather than handling their needs individually--yield valuable economies of scale):
maintaining graph data comprising a team node tree that comprises a plurality of team nodes and one or more hierarchical relationships between the plurality of team nodes (Delany: [col 14, line 65, (127) FIG. 5 shows a hierarchical tree), each team node of the plurality of team nodes representing a team of users in the organization-based access control system, each team node being associated with (Delany: [Col 14, lines 21-31, (125) FIG. 5 depicts an exemplar directory tree that can be stored on Directory Server 36. Each node on the tree is an entry in the directory structure that includes an identity profile. In one embodiment, the entity can be a user, group or organization. Node 230 is the highest node on the tree and represents an entity responsible for the directory structure. In one example, an entity may set up an Extranet and grant Extranet access to many different companies. The entity setting up the Extranet is node 230. Each of the companies with Extranet access would have a node at a level below node 230. Each company may be broken up into organizations. The organizations could be departments in the company or logical groups to help manage the users.):
(a) one or more users in the represented team (Delany: [Col 2, lines 1-2], (7) A user can be a member of a group by explicitly identifying that user as a member. [Col 14,lines 40-41], FIG. 5 shows organization A having two end users: employee 1 with node 250 and employee 2 with node 252),
(b) a set of resources for the represented team, where resources in the set of resources are file system resources, (Delany: [Col 6, lines 4-12], (83) FIG. 1 shows two types of resources: resource 22 and resource 24. Resource 22 is external to Web Server 18 but can be accessed through Web Server 18. Resource 24 is located on Web Server 18. A resource can be anything that is possible to address with a uniform resource locator (URL, see RFC 1738). A resource can include a web page, software application, file, database, directory, a data unit, etc. In one embodiment, a resource is anything accessible to a user on a network),
(c) a team node-specific set of policies that define rights of the one or more users to access the set of resources for the represented team (Delany: [Col 9, lines 49-51], (100) Authentication and Authorization decisions are based on policy domains and policies. A policy domain is a logical grouping of Web Server host ID's, host names, URL prefixes, and rules. [Col 9, lines 54-56], Rules specify the conditions in which access to requested resources is allowed or denied, and to which end users these conditions apply. [Col 9, lines 49-52], (100) Authentication and Authorization decisions are based on policy domains and policies. A policy domain is a logical grouping of Web Server host ID's, host names, URL prefixes, and rules),
and (d) one or more other team nodes as either a parent node or child node of each of the one or more other team nodes (Delany: [Col 2, lines 25-33], A user is a nested member of a first group if that user is a member of a second group and the second group is a member of the first group. There can be multiple levels of nesting. For example, an entity can be a nested member of a first group if that entity is a member of a second group, which is a member of a third group, which is a member of a fourth group, . . . , which is a member of the first group. [Col 33, lines 40-45], This relationship is displayed as a tree on its side, with the roots on the left and the leaves on the right. The display allows the user to tunnel down from a particular group to display the groups contained in (e.g. that are a member of) that group, and so on);
for each parent team node of a set of parent team nodes in the team node tree (Delany: [Col 2, lines 45-57], A first level of containing groups includes one or more groups that contain one or more of the second set of groups and one or more groups that contain one or more of the third set of groups. For one or more additional levels of containing groups, each level of containing groups includes one or more groups that contain other groups at a lower level of containing groups. For each particular group of each level of containing groups, the system notes a container relationship for groups of an immediately lower level of containing groups that are members of the particular group. In one embodiment, when reporting the list of groups for a user, the containment relationships are also reported), determining an effective access policy, for said each parent team node, comprising (Delany: [Col 9, lines 61-67] – [Col 10, lines 1-7], (101) A policy is a grouping of a URL pattern, resource type, operation type (such as a request method), and policy rules. These policy rules are the second level rules described above. There are two levels of rules available (first and second levels) for authentication, authorization, and auditing. Policies are always attached to a policy domain and specify the fine-grain portion of a web name space that a policy protects. In practice, the host names and URL prefixes from the policy's policy domain are logically concatenated with the policy's URL pattern. The resulting overall pattern is compared to the incoming URL. If there is a match, then the policy's various rules are evaluated to determine whether the request should be allowed or denied; if there is not a match, then default policy domain rules are used):
detecting an instruction, from a particular user that is associated with a particular team node of the team node tree, to perform an access operation, of a particular type, on a particular resource that is associated with a particular child team node of the particular team node (Delany: [Col 9, lines 5-10], In a typical unprotected web site, end users cause their browsers to send a request to a Web Server. The request is usually an HTTP request, which includes a URL. The Web Server then translates, or maps, the URL into a file system's name space and locates the matching resource. The resource is then returned to the browser)
responsive to detecting the instruction: determining that the particular user has the right to perform the particular type of access operation on the particular resource based, at least in part, on information from the effective access policy for the particular team node (Delany: [Col 6, lines 61-62], (101) A policy is a grouping of a URL pattern, resource type, operation type (such as a request method), and policy rules. [Col 9, lines 36-39], After authenticating the user, Web Gate 28 queries Access Server 34 about whether the user is authorized to access the resource requested. [col 9, lines 44-46], If the user is authorized, the user is granted access to the resource; otherwise, the user's request is denied))
and responsive to determining that the particular user has the right to perform the particular type of access operation on the particular resource, causing performance of the access operation instructed by the instruction (Delany: [Col 19, lines 16-23], That is, the manager will determine which attributes the user may view based on the access information (e.g. from FIG. 11) and the user's identity profile. All of those attributes that can be viewed are displayed in step 540. Those attributes that can be modified will include a "modify" button next to the attribute. Selecting a modify button will allow the user to modify the attribute (e.g. change the user's telephone number, etc.));
wherein the method is performed by one or more computing devices (Delany: [Col 30, lines 27-29], Events can be as simple as adding, modifying or deleting an object or could be as complex as a specific step within a workflow process. [Col 13, lines 42-50], Note that when the access to the data stores includes a read operation, the reporting of results will likely include the data that was read. If the access was for a write operation, the reporting of results can include a confirmation of the write operation or a reporting of the data that was written. In some embodiments, the failure to notify of an error during a write operation can be considered as reporting a successful result of the write operation).
Delany does not explicitly disclose below claim limitations, however in an analogous art, Doermann teaches:
the team node-specific set of policies for said each parent team node (Doermann: [Col 5, lines 10-18], One practical result of the resource hierarchy of FIG. 1 is that multiple permission “inheritance” paths from a leaf resource node (or other resource node) to a root node may exist, such as the sample resource traversal paths illustrated in FIGS. 3A and 3B. For example, RN8 may trace a traversal path to Resource Node 1 in three different ways: RN8.fwdarw.RN4.fwdarw.RN2.fwdarw.RN1; RN8.fwdarw.RN4.fwdarw.RN5.fwdarw.RN3.fwdarw.RN1; or RN8.fwdarw.RN5.fwdarw.RN3.fwdarw.RN1. [Col 5, lines 20-21], each resource node in the resource hierarchy may have one or more associated permission policies. [Col 5, lines 23-34], permission policies may also specify, define, or be organized in permission hierarchies. [Col 10, lines 10-13], the permissions included in the matrix data structure 500 may be provided by system administrators, supervisors, executives, etc. that determine access rights of particular accessors) and one or more boundary access policies that define rights for the one or more users of said each parent team node to access a set of child resources (Doermann: [Col 5, lines 9-15], a permission policy for RN4 may be determined from either RN2, RN5, or both. One practical result of the resource hierarchy of FIG. 1 is that multiple permission “inheritance” paths from a leaf resource node (or other resource node) to a root node may exist, such as the sample resource traversal paths illustrated in FIGS. 3A and 3B. For example, RN8 may trace a traversal path to Resource Node 1 in three different ways: RN8.fwdarw.RN4.fwdarw.RN2.fwdarw.RN1; RN8.fwdarw.RN4.fwdarw.RN5.fwdarw.RN3.fwdarw.RN1; or RN8.fwdarw.RN5.fwdarw.RN3.fwdarw.RN1. [Col 5, lines 20-28], each resource node in the resource hierarchy may have one or more associated permission policies…) comprising one or more sets of resources associated with child nodes of said each parent team node (Doermann: [Col 14, lines 46-51], (77) At block 915, the permissions system 100 accesses permission policy information for each of (1) the resource and (2) each respective parent, ancestor, and/or group resource levels with respect to the accessor. The permission policy information may be accessed for example, from the permissions data sources 170)
It would be obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to modify Delany’s method of determining the access rights of each members of each group in the hierarchically structured organization by applying Doermann’s method of determining access policies from a leaf resource node (or other resource node) to a root node. The motivation is to determine permissions and policies for resources in a complex multi-dimensional data system and provide efficient and flexible permissions analysis, determination, and management (Doermann: [Abstract]).
Regarding Claim 2, Delany in view of Doermann teaches:
The method of claim 1 (see rejection of claim 1 above),
wherein the one or more boundary access policies for a particular parent team node of the set of parent team nodes allow access to resources from multiple child team nodes of the particular parent team node (Delany: [Col 14, lines 25-26], Node 230 is the highest node (=parent team node) on the tree and represents an entity responsible for the directory structure. [Col 15, lines 20], an attribute (=resources) can be configured to be accessible (read, modify, etc.,)(=defining rights) based on a two part filter. The first component in the filter identifies a top node in the directory. The filter will only apply to those entities at or below that top node. The second component of the filter is an LDAP filter which defines who can access the attribute)).
Regarding Claim 3, Delany in view of Doermann teaches:
The method of claim 1 (see rejection of claim 1 above),
wherein: the team node tree is associated with a set of one or more child resource access rules (Delany: [Col 33, lines 40-45], This relationship is displayed as a tree on its side, with the roots on the left and the leaves on the right. The display allows the user to tunnel down from a particular group to display the groups contained in (e.g. that are a member of) that group, and so on);
and the method further comprises, for each team node in the team node tree that is associated with one or more child nodes: based, at least in part, on the set of one or more child resource access rules (Delany: [Col 33, lines 49-64], The process can be used to build a tree structure in which the nodes are groups that contain the user as a member. The leaf nodes of the tree are those groups in which the user is a static or dynamic member. All other nodes are groups in which the user is a nested member. The process of FIG. 25 assumes the following: Let u denote the target user; Let g denote a single group; Let G denote a set of groups, where the g.sub.i denotes the i.sup.th group in the set; Let G.sub.s denote the set of groups in which u is a static member; Let G.sub.d denote the set of groups in which u is a dynamic member; and Let G.sub.t denote the set of groups in which each g.sub.i has a reference to each of its containing groups),
determining one or more default boundary access policies for said each team node (Delany: [Col 9, lines 54-58], Rules specify the conditions in which access to requested resources is allowed or denied, and to which end users these conditions apply. Policy domains contain two levels of rules: first level default rules and second level rules contained in policies)
Regarding Claim 7, Delany in view of Wang teaches:
The method of claim 1 (see rejection of claim 1 above),
wherein: the particular user is associated with multiple team nodes within the graph data (Delany: [Col 2, lines 25-34], A user is a nested member of a first group if that user is a member of a second group and the second group is a member of the first group. There can be multiple levels of nesting. For example, an entity can be a nested member of a first group if that entity is a member of a second group, which is a member of a third group, which is a member of a fourth group, . . . , which is a member of the first group. The present invention can determine the groups for which the user is a static member, dynamic member or nested member);
and the method further comprises: storing, for the particular user, particular effective access policy information that comprises information from the effective access policy determined for each team node of the multiple team nodes (Delany: [Col 9,lines 55-57], Policy domains (=policy storage) contain two levels of rules: first level default rules and second level rules contained in policies. );
wherein said determining that the particular user has the right to perform the particular type of access operation on the particular resource is performed based on the stored particular effective access policy information (Delany: (Col 62, lines 52-57], one or more access rules are added to the policy domain (steps 2406 and 2408). An access rule is a rule about accessing a resource. Examples of access rules include authorization rules, authentication rules, auditing rules, and other rules, which are used during the process of attempting to access a resource).
Regarding Claim 15, this claim contains identical limitations found within that of claim 1
above albeit directed to a different statutory category (non-transitory computer readable medium). For this reason, the same grounds of rejection are applied to claim 15.
Regarding Claim 16, this claim contains identical limitations found within that of claim 2
above albeit directed to a different statutory category (non-transitory computer readable medium). For this reason, the same grounds of rejection are applied to claim 16.
Regarding Claim 17, this claim contains identical limitations found within that of claim 3
above albeit directed to a different statutory category (non-transitory computer readable medium). For this reason, the same grounds of rejection are applied to claim 17.
Claim(s) 8-9, 11 are rejected under 35 U.S.C. 103 as being unpatentable over Delany (U. S. Pat. No. 7,085,834 B2) (hereinafter “Delany”) in view of Doermann et al. (U. S. Pat. No. 9,218,502 B1) (hereinafter “Doermann”); and in further view of Wang et al (U. S. Pat. No. 11,032,287 B1) hereinafter (“Wang”);
Regarding Claim 8, Delany in view of Doermann teaches:
The method of claim 1 (see rejection of claim 1 above),
Delany in view of Doermann does not explicitly disclose below claim limitations, however, in an analogous art, Wang teaches:
wherein the information from the effective access policy for the particular team node is based on a boundary access policy that uniquely identifies the particular resource (Wang: [Col 5, lines 17-35], A permission boundary policy is a special, managed policy attachment that specifies permission boundaries for the delegated administrator. The permissions granted to users or roles created or modified by the delegated administrator will never exceed the permission boundaries specified by the original grantor (central administrator) in the permission boundary policy 147. For example, an effective permissions of a user, created or modified by a delegated administrator, will be an intersection of a permissions policy 143 and the permission boundary policy 147 attached to the user. In some cases multiple permission boundary policies may be associated with an IAM principal (IAM user, IAM role, or group of IAM users). In these cases, the multiple permission boundary policies may be the union of the access permissions, the intersection of the access permissions, or the like. In other cases, the access permissions can be prioritized in how to manage conflicts between the access permissions in the multiple permission boundary policies).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Delany in view of Doermann by applying the well-known technique as disclosed by Wang’s method of access permission within the boundary access policy, in order to set the maximum permission an identity can have, ultimately ensuring that user have the appropriate level of access while maintaining security safeguard. The motivation is to sets up controls to govern access to resources and services and gets frustrated with debugging complex permissions to figure out what will work. The customer may give up and set permissions that are too permissive for their needs (Wang: Col 1, lines 38-42]).
Regarding Claim 9, Delany in view of Doermann and Wang teaches:
The method of claim 8 (see rejection of claim 8 above),
wherein the boundary access policy grants an access privilege for a second resource, associated with the particular child team node, based on uniquely identifying the second resource within the boundary access policy (Wang: [Col 7, lines 2-7], The client permissions manager 115 receives data regarding the client request from the first web service. The data may include a user identifier, an action identifier, and a resource identifier. The client permissions manager 115 can check the permission boundary policies 147 and the permissions policies 143 for the client request),
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Delany in view of Doermann by applying the well-known technique as disclosed by Wang’s method of access permission within the boundary access policy, in order to set the maximum permission an identity can have, ultimately ensuring that user have the appropriate level of access while maintaining security safeguard. The motivation is to sets up controls to govern access to resources and services and gets frustrated with debugging complex permissions to figure out what will work. The customer may give up and set permissions that are too permissive for their needs (Wang: Col 1, lines 38-42]).
Regarding Claim 11, Delany in view of Doermann and Wang teaches:
The method of claim 1 (see rejection of claim 1 above),
wherein the information from the effective access policy for the particular team node is based on a boundary access policy that identifies the particular resource based on an identifier of a group of resources that includes the particular resource (Wang: [Col 9, lines 2-7], The client permissions manager 115 receives data regarding the client request from the first web service. The data may include a user identifier, an action identifier, and a resource identifier (=identifier of a group of resources). The client permissions manager 115 can check the permission boundary policies 147 and the permissions policies 143 for the client request).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Delany in view of Doermann by applying the well-known technique as disclosed by Wang’s method of access permission within the boundary access policy, in order to set the maximum permission an identity can have, ultimately ensuring that user have the appropriate level of access while maintaining security safeguard. The motivation is to sets up controls to govern access to resources and services and gets frustrated with debugging complex permissions to figure out what will work. The customer may give up and set permissions that are too permissive for their needs (Wang: Col 1, lines 38-42]).
Claim(s) 4, 5, 10, 12, 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Delany (U. S. Pat. No. 7,085,834 B2) (hereinafter “Delany”) in view of Doermann et al. (U. S. Pat. No. 9,218,502 B1) (hereinafter “Doermann”); and in further view of Tomlin (U. S. PGPub No. 2020/0244666 A1) (hereinafter “Tomlin”)
Regarding Claim 4, Delany in view of Doermann teaches:
The method of claim 1 (see rejection of claim 1 above),
The Delany in view of Doermann does not explicitly teaches:
detecting a second instruction, from a second user associated with the particular child team node, to perform a second access operation, of the particular type, on the particular resource;
responsive to detecting the second instruction: determining that the second user does not have the right to perform the particular type of access operation on the particular resource based on information from a team node-specific access policy associated with the particular child team node, and responsive to determining that the second user does not have the right to perform the particular type of access operation on the particular resource, denying performance of the second access operation instructed by the second instruction.
However, in an analogous art, Tomlin teaches:
detecting a second instruction, from a second user associated with the particular child team node, to perform a second access operation, of the particular type, on the particular resource (Tomlin: [0132] The assertion statement may be applied manually, or it may be applied automatically, for example by storing the statement and repeating its application to the access control list at periodic intervals, which may be user configured using software);
responsive to detecting the second instruction (Tomlin: [0052], The permissioning system evaluates user's permissions in response to access requests that may be received from any one of multiple applications hosted by servers communicatively linked (e.g., via a network) to the permissioning system. [0106], upon receiving an access request for the data resource 500, the evaluation module 204 accesses the policy object 502 from the policy database 206):
determining that the second user does not have the right to perform the particular type of access operation on the particular resource based on information from a team node-specific access policy associated with the particular child team node (Tomlin: [0132] The assertion statement may be applied manually, or it may be applied automatically, for example by storing the statement and repeating its application to the access control list at periodic intervals, which may be user configured using software), [0087], a ALLOW-ON-CHILDREN or DENY-ON-CHILDREN that apply only when inherited (e.g., instead of saying a user has (or does not have) rights on a specific node in the graph, a resource can be configured to grant (or deny) access only for child nodes)
and responsive to determining that the second user does not have the right to perform the particular type of access operation on the particular resource (Tomlin: [0051], In this manner, the permissioning system maintains an effective policy for each data resource because the data object representing the policy includes policy information for the entire hierarchical tree, and as such, the object contains all information that is needed to determine a user's access permission with respect to a particular data resource. [0085], [0085] Each policy includes one or more statements that specify particular operations that a user is authorized to perform with respect to a particular data resource. In particular, each statement includes a field for each operation (or set of operations), an action, and a condition. The operation field corresponds to an operation that a user is authorized to perform with respect to the data resource. Each operation may be globally applicable to the network-based permissioning system 104 or may be specifically related to one of the network applications 109-111);
denying performance of the second access operation instructed by the second instruction (Tomlin: [0087], an ALLOW-ON-CHILDREN or DENY-ON-CHILDREN that apply only when inherited (e.g., instead of saying a user has (or does not have) rights on a specific node in the graph, a resource can be configured to grant (or deny) access only for child nodes)).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Delany in view of Doermann by applying the well-known technique as disclosed by Tomlin of denying the access request by determine that the user does not have an access rights in order to prevent unauthorized access to the resources. The motivation is to evaluate user’s permission to access the resources (Tomlin: [0052]).
Regarding Claim 5, Delany in view of Doermann teaches:
The method of claim 4 (see rejection of claim 4 above),
The Delany in view of Doermann does not explicitly disclose:
wherein determining that the second user does not have the right to perform the particular type of access operation on the particular resource is based on an explicit denial of the particular type of access operation for the particular resource in the team node-specific access policy associated with the particular child team node.
However, Tomlin disclose:
wherein determining that the second user does not have the right to perform the particular type of access operation on the particular resource is based on an explicit denial of the particular type of access operation for the particular resource in the team node-specific access policy associated with the particular child team node (Tomlin: [0052], The policy information stored in the policy object includes policies explicitly associated with the data resource as well as policies implicitly associated with the data resource by virtue of the data resource's dependency to other data resources. The permissioning system communicates a response to the application, from which the access request was received, that includes the access permission of the user. The access permission includes one or more operations that the user is authorized to perform with respect to the data resources. In some instances, the access permissions may include operations that are specific to the application from which the access request was received. [0087], the actions may include the following: an ALLOW action that grants a specified operation to a current context if the condition evaluates to “TRUE”; a DENY action that denies a specified operation if the condition evaluates to “TRUE” a FORCE-ALLOW action that grants specified operations as a special override and causes the system to ignore all DENY and FORCE-DENY actions, if the condition evaluates to “TRUE”; a FORCE-DENY action that denies specified operations unless explicitly overridden by a FORCE-ALLOW statement; a ALLOW-ON-CHILDREN or DENY-ON-CHILDREN that apply only when inherited (e.g., instead of saying a user has (or does not have) rights on a specific node in the graph, a resource can be configured to grant (or deny) access only for child nodes)).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Delany in view of Doermann by applying the well-known technique as disclosed by Tomlin of denying the access request by determine that the user does not have an access rights in order to prevent unauthorized access to the resources. The motivation is to evaluate user’s permission to access the resources (Tomlin: [0052]).
Regarding Claim 10, Delany in view of Doermann teaches:
The method of claim 1 (see rejection of claim 1 above),
The Delany in view of Doermann does not explicitly teaches:
wherein the information from the effective access policy for the particular team node is based on a boundary access policy that identifies the particular resource based on an identifier of the particular resource matching a regular expression in the boundary access policy.
However, in an analogous art, Tomlin teaches:
wherein the information from the effective access policy for the particular team node is based on a boundary access policy that identifies the particular resource based on an identifier of the particular resource matching a regular expression in the boundary access policy (Tomlin: [0086], a DEPENDENT condition to check if the resulting operations from dependencies contain all or any of the condition specified operations; a GROUP condition to check if a user possesses all or any of the condition specified groups; a NOT condition to negate the result of another condition; an OR condition that takes two or more conditions and checks if any of them evaluate to true; an AND condition that takes two or more conditions and checks if all of them evaluate to true; a USER condition to check if the requesting user is the allowed user; and a USER TYPE condition that checks if the user is of the allowed type (e.g., user or service). It shall be understood the conditions supported by the network-based permissioning system 104 may be extensible and are thus not limited to the above referenced examples. Additionally, conditions may be combined together into arbitrary Boolean expressions. The following is an example of such a combination: “NOT(USER=X)”; “AND(USER=X, GROUP=Y)”. [0143], The verification module 803 then compares the first and second data structures; a match indicates that the assertion is TRUE, whereas any discrepancy indicates that the assertion is FALSE. Thus, use of the assertion tree builder 805 is such as to enable verification using only a fraction of the policy objects within the access control list (ACL) whilst enabling a rich and large combination of possible permissioning situations to be verified).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Delany in view of Doermann by applying the well-known technique as disclosed by Tomlin of matching of regular expressions to check or verify group conditions. The motivation is to evaluate user’s permission to access the resources (Tomlin: [0052]).
Regarding Claim 12, Tomlin in view of Doermann teaches:
The method of claim 1 (see rejection of claim 1 above),
wherein: the particular resource is an attribute of a data entity (Tomlin: [0051], In this manner, the permissioning system maintains an effective policy for each data resource because the data object representing the policy includes policy information for the entire hierarchical tree, and as such, the object contains all information that is needed to determine a user's access permission with respect to a particular data resource (=particular resource);
and the information from the effective access policy for the particular team node is based on a boundary access policy that identifies the attribute and defines one or more privileges for the attribute (Wang: [Col 5, lines 17-35], A permission boundary policy is a special, managed policy attachment that specifies permission boundaries for the delegated administrator. The permissions granted to users or roles created or modified by the delegated administrator will never exceed the permission boundaries specified by the original grantor (central administrator) in the permission boundary policy 147. For example, an effective permissions of a user, created or modified by a delegated administrator, will be an intersection of a permissions policy 143 and the permission boundary policy 147 attached to the user. In some cases multiple permission boundary policies may be associated with an IAM principal (IAM user, IAM role, or group of IAM users). In these cases, the multiple permission boundary policies may be the union of the access permissions, the intersection of the access permissions, or the like. In other cases, the access permissions can be prioritized in how to manage conflicts between the access permissions in the multiple permission boundary policies).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Delany in view of Doermann by applying the well-known technique as disclosed by Tomlin of providing boundary access policy to access resources. The motivation is to evaluate user’s permission to access the resources (Tomlin: [0052]).
Regarding Claim 18, Delany in view of Doermann teaches:
The non-transitory computer-readable media of claim 15 (see rejection of claim 15 above),
wherein the instructions further comprise instructions that, when executed by one or more processors, cause (Delany: [Col 10, lines 22-27], The computer system in FIG. 2 includes processor unit 50 and main memory 52. Processor unit 50 may contain a single microprocessor, or may contain a plurality of microprocessors for configuring the computer system as a multi-processor system. Main memory 52 stores, in part, instructions and data for execution by processor unit 50):
This claim contains identical limitations found within that of claim 4 above albeit directed to a different statutory category (non-transitory computer readable medium). For this reason, the same grounds of rejection are applied to claim 18.
Regarding Claim 19, this claim contains identical limitations found within that of claim 5 above albeit directed to a different statutory category (non-transitory computer readable medium). For this reason, the same grounds of rejection are applied to claim 19.
Claim(s) 6 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Delany (U. S. Pat. No. 7,085,834 B2) (hereinafter “Delany”) in view of Doermann et al. (U. S. Pat. No. 9,218,502 B1) (hereinafter “Doermann”); and in further view of Collins et al (U. S Pat. No. 11,308,126 B2) (hereinafter “Collins”)
Regarding Claim 6, Delany in view of Doermann teaches:
The method of claim 1 (see rejection of claim 1 above),
Daleny in view of Doermann does not explicitly disclose below claim limitations, however, in an analogous art Wang teaches:
and determining one or more adjusted effective access policies for respective one or more team nodes of the team node tree based, at least in part, on the one or more adjusted boundary access policies (Wang: [Col 8, lines 30-40], The permissions policy editor 210 can receive a request to create a new permissions policy 243 or modify an existing permissions policy 243. The permissions policy editor 210 can send an acknowledgement response when the new permissions policy 243 is created or modified. The permissions boundary policy editor 210 can receive a request to create a new permission boundary policy 245 or modify an existing permissions policy 245. The permission boundary editor 215 can send an acknowledgement response when the new permission boundary policy 245 is created or modified (=adjusted boundary policies)).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Delany in view of Doermann by applying the well-known technique as disclosed by Wang’s method of modifying existing policy. The motivation is to sets up controls to govern access to resources and services and gets frustrated with debugging complex permissions to figure out what will work. The customer may give up and set permissions that are too permissive for their needs (Wang: Col 1, lines 38-42]).
The combination of Delany in view of Doermann and Wang does not explicitly disclose:
detecting a change within the graph data for the team node tree comprising one or more of:
deletion of a team node from the team node tree, addition of a team node to the team node tree, changing one or more relationships between two or more team nodes of the team node tree, merging one or more other team node trees with the team node tree, splitting the team node tree into multiple team node trees, or changing information for a root node of the team node tree;
responsive to detecting the change within the graph data for the team node tree:
performing one or more adjustment actions for one or more boundary access policies for one or more parent team nodes of the team node tree to produce one or more adjusted boundary access policies,
However, in an analogous art, Collins teaches:
detecting a change within the graph data for the team node tree comprising one or more of: (Collins: [Col 10, lines 32-39], However, a client may wish to modify, remove, and/or add new resources attributes to the resource metadata in order to provide greater flexibility for automating various interactions within the resources utilizing resource metadata. Resource tag service 258 may lookup policies for different resources to determine which resource attributes are to be maintained for the different resources, in some embodiments.
deletion of a team node from the team node tree, addition of a team node to the team node tree (Collins: [Col 16, lines 65-67 – Col 17, lines 1-6], Client 610 may submit a request to delete a hierarchy 632 to resource management service 240. Resource management service 240 may send a request to delete the hierarchy directory (which may delete any group(s), or group(s) of groups within the hierarchy but not resource data objects or policy data objects which may only be linked to the deleted directory). Instead, the links may be removed (e.g., by hierarchical data store 360 when one of the linked nodes is deleted),
changing one or more relationships between two or more team nodes of the team node tree (Collins: [Col 18, lines 15-23], As indicated at 820, a request to modify one of the hierarchies may be received. A modification to a hierarchy may include a modification to the arrangement of a hierarchy. For example, resource data objects may be reassigned from one group to another, new groups or groups of groups may be created, groups or groups of groups may be deleted, or any other change to the relationships of resource data objects among the hierarchy may be performed, such as the requests discussed above with regard to FIG. 6.),
merging one or more other team node trees with the team node tree (Collins: [Col 12, lines 12-16], Other requests that may be submitted via interface 310 may be requests to create an organization, update an organization (e.g., by adding other resources, inviting other user accounts to join the organization. [Col 12, lines 25-37], (45) Resource management service 240 may implement organization management 320, which may handle the creation of organizations, the updates to or modifications of organizations, the delegation of access permissions to organizations, as well as the arrangement of resource data objects within hierarchies maintained for the organization. For example, upon creation an organization may include a single hierarchy providing an arrangement of resource data objects (e.g., as members of various groups and/or groups within groups, etc.). Resource management 320 may handle the various requests to create additional hierarchies, update hierarchies, or delete hierarchies, as discussed below with regard to FIG. 6.),
splitting the team node tree into multiple team node trees, or changing information for a root node of the team node tree (Collins: [Col 14, lines 63-67 Col 15, lines 1-2], FIG. 5 is a logical illustration of directory structures that may store resource data objects and hierarchies of resource data objects in a hierarchical data store, according to some embodiments. Organization data objects (including policy data objects, resource data objects, groups or groups of groups of data objects) may be maintained in one or multiple directory structures, in various embodiments. [Col 15, lines 3-17], organization 500 may utilize directory structure 502 to store the resources and policies that are part of the organization. Index node 510 may provide information for performing a lookup to determine the location of a resource data object or policy data object. Resources node 520 may group resources into various resources types 522 and 524 (e.g., user accounts, virtual compute instances, storage volumes, VPNs, load balancers, etc.) and within the resource types 522 and 524 may be found resource data objects 526 and 528 describing individual resources in the provider network. Similarly, policies node 530 may include different policy types 532 and 534 (which may be created by clients as discussed above). Individual instances of the policy types 536 and 538 may be policy instances applied to resource data objects, groups, groups of groups, or hierarchies. [Col 15, lines 52-59], Leaf nodes can have more than one parent node so that resource data objects and policy data objects can be linked to multiple hierarchies. In some embodiments, all resource data objects are linked to all hierarchies (though in different arrangements as defined by a user), whereas in other embodiments, resource data objects may be linked to only some hierarchies),
responsive to detecting the change within the graph data for the team node tree (Collins: [Col 16, lines 51-64], Client 610 may submit a request to update the hierarchy 622. Hierarchy update requests may include various requests to add a group, remove a group, add resources to a group, remove resource(s) from a group, add a group to a group, remove a group from a group, or any other arrangement modification to the hierarchy. In turn, resource management service 240 may send an update hierarchy directory request 624 to perform one or more corresponding actions, such as requests to create group sub-directories, remove group sub-directories, add resource data object link(s), or remove resource data object link(s). Upon completion or failure of the requests, resource management service 240 may acknowledge the hierarchy update 626 (which may indicate success or failure):
performing one or more adjustment actions for one or more boundary access policies for one or more parent team nodes of the team node tree to produce one or more adjusted boundary access policies (Collins: [Col 4, lines 56-59], multiple hierarchies of the same resource data objects may be maintained so that policies may be optimally applied to different arrangements of the same resource data objects. [Col 14, lines 28-35], For example, client(s) 410 may submit various organization/policy management requests 412 (e.g., to modify a hierarchy by arranging resource data objects or applying/removing policies). In turn resource management service 240 may identify the appropriate updates to organization data to be made or to be read, and send organization data updates/reads 422 to hierarchical data storage 350. [Col 14, lines 28-31], client(s) 410 may submit various organization/policy management requests 412 (e.g., to modify a hierarchy by arranging resource data objects or applying/removing policies),
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Delany in view of Doermann and Wang by applying the well-known technique as disclosed by Collins of modify, remove, and/or add new resources attributes to the resource metadata in order to provide greater flexibility for automating various interactions within the resources utilizing resource metadata. The motivation is to resource management systems have been developed to allow for the separate management of actions and behaviors that may be performed by system components (Collins: [Col 1, lines 17-20]).
Regarding Claim 20, Delany in view of Doermann teaches:
The non-transitory computer-readable media of claim 15 (see rejection of claim 15 above),
wherein the instructions further comprise instructions that, when executed by one or more processors, cause (Delany: [Col 10, lines 22-27], The computer system in FIG. 2 includes processor unit 50 and main memory 52. Processor unit 50 may contain a single microprocessor, or may contain a plurality of microprocessors for configuring the computer system as a multi-processor system. Main memory 52 stores, in part, instructions and data for execution by processor unit 50):
This claim contains identical limitations found within that of claim 6 above albeit directed to a different statutory category (non-transitory computer readable medium). For this reason, the same grounds of rejection are applied to claim 20.
Claim(s) 13 are rejected under 35 U.S.C. 103 as being unpatentable over Delany (U. S. Pat. No. 7,085,834 B2) (hereinafter “Delany”) in view of Doermann et al. (U. S. Pat. No. 9,218,502 B1) (hereinafter “Doermann”); and further in view of Childress et al (U. S. Pat. No. 10,848,498 B2) (hereinafter “Childress”).
Regarding Claim 13, Delany in view of Doermann teaches:
The method of claim 1 (see rejection of claim 1 above),
The combination of Delany in view of Doermann does not explicitly disclose:
wherein the effective access policy for the particular team node identifies resources at two or more of: a multi-segment level of granularity, a segment level of granularity, an extent level of granularity, a data block level of granularity, a multi-file level of granularity, a file-level of granularity, a data object level of granularity, or a sub-data object level of granularity.
However, in an analogous art, Childress teaches:
wherein the effective access policy for the particular team node identifies resources at two or more of: a multi-segment level of granularity, a segment level of granularity, an extent level of granularity, a data block level of granularity, a multi-file level of granularity, a file-level of granularity, a data object level of granularity, or a sub-data object level of granularity (Childress: [Col 9, 36-50], For example, the access permissions can be limited to actions taken within a specific object, component, application, program, system, or project. A user responsible for interaction with a software program can be granted permission to create, read, update, and delete granular file-level, object level, and functionality-level aspects of the software program. The user's access permissions may not extend to file-level, object-level, and functionality-levels unrelated to the software program. Another user interacting with the same software program can have more limited access permissions. The latter user's access permissions can apply only to granular file-level, object-level, and functionality-levels. The latter user's access permissions also may not extend to granular file-level, object-level, and functionality-level unrelated to the software program).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Delany in view of Doermann by applying the well-known technique as disclosed by Childress of access level of granularity in order to determine whether a request from the user interface is authorized before process the request. The motivation is to the authorization process can use access control permissions from the administrator and either a scope limited or a temporally limited access permission (Childress: [abstract]).
Claim(s) 14 is rejected under 35 U.S.C. 103 as being unpatentable over Delany (U. S. Pat. No. 7,085,834 B2) (hereinafter “Delany”) and further in view of Ferrans et al (U. S. PGPub. No. 2019/0364051 A1) (hereinafter “Ferrans”)
Regarding Claim 14, Delany teaches:
A computer-executed method for filesystem access control (Delany: [Col 6, lines 4-12], (83) FIG. 1 shows two types of resources: resource 22 and resource 24. Resource 22 is external to Web Server 18 but can be accessed through Web Server 18. Resource 24 is located on Web Server 18. A resource can be anything that is possible to address with a uniform resource locator (URL, see RFC 1738). A resource can include a web page, software application, file, database, directory, a data unit, etc. In one embodiment, a resource is anything accessible to a user on a network), comprising: maintaining graph data comprising a team node tree that comprises a plurality of team nodes and one or more hierarchical relationships between the plurality of team nodes (Delany: [col 14, line 65, (127) FIG. 5 shows a hierarchical tree), each team node of the plurality of team nodes being associated with (Delany: [Col 14, lines 21-31, (125) FIG. 5 depicts an exemplar directory tree that can be stored on Directory Server 36. Each node on the tree is an entry in the directory structure that includes an identity profile. In one embodiment, the entity can be a user, group or organization. Node 230 is the highest node on the tree and represents an entity responsible for the directory structure. In one example, an entity may set up an Extranet and grant Extranet access to many different companies. The entity setting up the Extranet is node 230. Each of the companies with Extranet access would have a node at a level below node 230. Each company may be broken up into organizations. The organizations could be departments in the company or logical groups to help manage the users):
(a) one or more users in a represented team (Delany: [Col 2, lines 1-2], (7) A user can be a member of a group by explicitly identifying that user as a member. [Col 14,lines 40-41], FIG. 5 shows organization A having two end users: employee 1 with node 250 and employee 2 with node 252),
(b) a set of resources for the represented (Delany: [Col 6, lines 4-12], (83) FIG. 1 shows two types of resources: resource 22 and resource 24. Resource 22 is external to Web Server 18 but can be accessed through Web Server 18. Resource 24 is located on Web Server 18. A resource can be anything that is possible to address with a uniform resource locator (URL, see RFC 1738). A resource can include a web page, software application, file, database, directory, a data unit, etc. In one embodiment, a resource is anything accessible to a user on a network),
(c) a team node-specific set of policies that define rights of the one or more users to access the set of resources for the represented team (Delany: [Col 9, lines 49-51], (100) Authentication and Authorization decisions are based on policy domains and policies. A policy domain is a logical grouping of Web Server host ID's, host names, URL prefixes, and rules. [Col 9, lines 54-56], Rules specify the conditions in which access to requested resources is allowed or denied, and to which end users these conditions apply. [Col 9, lines 49-52], (100) Authentication and Authorization decisions are based on policy domains and policies. A policy domain is a logical grouping of Web Server host ID's, host names, URL prefixes, and rules),
and (d) one or more other team nodes as either a parent node or child node of each of the one or more other team nodes (Delany: [Col 2, lines 25-33], A user is a nested member of a first group if that user is a member of a second group and the second group is a member of the first group. There can be multiple levels of nesting. For example, an entity can be a nested member of a first group if that entity is a member of a second group, which is a member of a third group, which is a member of a fourth group, . . . , which is a member of the first group. [Col 33, lines 40-45], This relationship is displayed as a tree on its side, with the roots on the left and the leaves on the right. The display allows the user to tunnel down from a particular group to display the groups contained in (e.g. that are a member of) that group, and so on);
Delany does not explicitly disclose:
wherein a particular team node, of the plurality of team nodes, is associated with a management access policy that define rights of the one or more users associated with the particular team node to manage graph data for a subset of the team node tree comprising one or both of: the particular team node, or one or more child nodes of the particular team node;
detecting an instruction, from a particular user that is associated with the particular team node, to perform a particular management operation on graph data for a team node in the subset of the team node tree;
responsive to detecting the instruction: determining that the particular user has the right to perform the particular management operation based, at least in part, on information from the management access policy associated with the particular team node,
and responsive to determining that the particular user has the right to perform the particular management operation, causing performance of the particular management operation.
However, in an analogous art, Ferrans teaches:
wherein a particular team node, of the plurality of team nodes, is associated with a management access policy that define rights of the one or more users associated with the particular team node to manage graph data for a subset of the team node tree comprising one or both of: the particular team node, or one or more child nodes of the particular team node (Ferrans: [0084] In one embodiment, in an organization-based access control system, organization hierarchies are maintained separately from roles, organizations are not treated as role-like entities, organization fields are exposed as user attributes, and organization subtree fields are exposed as list-valued user attributes. Such an organization-based access control system may be used in combination with any existing ABAC or hybrid RBAC/ABAC system, or as its own, standalone system)
detecting an instruction, from a particular user that is associated with the particular team node, to perform a particular management operation on graph data for a team node in the subset of the team node tree (Ferrans: [0128] Referring to FIG. 10, at block 1002 processing logic receives a request for a resource of a computer system. In one embodiment, the request is received from a client device of the computer system.);
responsive to detecting the instruction: determining that the particular user has the right to perform the particular management operation based, at least in part, on information from the management access policy associated with the particular team node (Ferrans: [0131] At block 1010, in response to receiving the request, processing logic generates, by a processing device, an access permission based on the organization hierarchy corresponding to the user and the one or more attribute names. In one embodiment, processing logic generates the access permission by replacing the one or more attribute names with the one or more attributes. The access permission may identify a resource expression, an action, and a constraint, wherein the constraint limits access to a subpart of the resource),
and responsive to determining that the particular user has the right to perform the particular management operation, causing performance of the particular management operation (Ferrans: [0132] At block 1012, processing logic provides or denies access to the resource of the computer system based on the access permission. Optionally, processing logic may generate an access policy comprising the access permission and provide the access policy to the computer system. It should be noted that the above operations may be performed in conjunction with a hybrid role and attribute-based access control system, a strictly access based control system, or any other access control system that allows for the distinct definition of organizational attributes).
It would be obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to modify Delany’s method of determining the access rights of each members of each group in the hierarchically structured organization by applying Ferrans’ method of organization based access control in order to allow for the authentication, authorization, and/or audit of client devices and user credentials. The motivation is to authorizing the users and ensure that only legitimate subjects can log on to a system (Ferrans:[0002]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Refer to PTO-892, Notice of References Cited for a listing of analogous art.
Donovan et al. (U. S. PGPub. No. 2022/0286460 A1): Methods, systems, devices, and tangible non-transitory computer readable media for generating and implementing security policies are provided. The disclosed technology can include accessing a security request associated with generating a security policy based in part on organizational data that includes one or more organizational records. The security request can include one or more rules associated with the security policy. Based at least in part on the security request, the one or more rules that are in compliance with one or more policies associated with the organizational data can be determined. Furthermore, the security policy can be generated based at least in part on the one or more rules that are in compliance with the one or more policies. Furthermore, operations associated with implementing the security policy can be performed.
Holdsworth et al. (U. S. PGPub. No. 2003/0188198 A1): Provided are methods, apparatus and computer programs for applying access controls to control operations on hierarchically organized data processing system resources. A number of different scopes of applicability can be set in association with an access control, such as an ACL, and this will determine the inheritability, non-inheritability or limited inheritability of the access control for resources in the hierarchy. When a request is received to perform an operation, the access controls for the relevant branch of the hierarchy are processed to determine an applicable access control--taking account of inheritance attributes which have been set for individual access controls. The invention is useful for controlling the application of ACLs to topics in a topic tree within a publish/subscribe message broker.
Puri et al. (U. S. Pat. No. 6,751,622 B1): A computer-implemented method of managing hierarchically related and heterogeneous data structures includes the steps of separating the data structures from hierarchical information interrelating the data structures and representing and storing the hierarchical information as a nodal tree structure. The nodal tree structure includes a first node and a plurality of second nodes, each node being in a parent-child relationship with at least one other node. The data structures are stored separately from the nodal tree structure and each of the first node and the plurality of second nodes references one of the data structures. Each of the second nodes is a child node, and each child node has a respective parent node selected from among the first node and the plurality of second nodes. Each of the second nodes includes a dependency attribute indicative of a dependency relationship of the child node with its respective parent node. Applications accessing the data structures may be configured to enforce the dependency relationships based upon the dependency attributes. In this manner, heterogeneous but related data structures such as operation sequences, scheduling and costing data may be collectively referenced by a single hierarchical structure.
/R.D./ Examiner, Art Unit 2437
/ALEXANDER LAGOR/ Supervisory Patent Examiner, Art Unit 2437