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
Claims 1, 3, 5, 6, 10-12, 14, 16, 17, and 21 are amended
Claims 1-21 are pending
Priority
This application is a continuation of U.S. Non-Provisional Application No. 17/812,909, filed July 15, 2022, which claims the benefit of U.S. Provisional Application No. 63/222,714 filed on July 16, 2021. Therefore, the effective filing date of this application is 07/16/2021.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 08/13/2026 and 09/09/2026. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements have been considered by the examiner.
Response to Arguments
Applicant’s arguments filed on 08/13/2026 have been fully considered.
With respect to the double patenting rejections. The rejection is maintained due to no terminal disclaimer has been filed.
With respect to the USC 112(b) rejection for claims 1-21, most of the rejections have been overcome. However, claims 5 and 16 are still rejected. Examiner suggests amending as suggested to overcome the rejection. With respect to the USC 112(b) rejection for claims 5 and 16. Claim 1 recites “detecting a permission between the first principal node and a resource node … and associating the plurality of principal nodes with the detected permission in the security database to indicate a grant of the detected permission to each principal represented by a corresponding principal node of the plurality of principal nodes”. Claim 1 provides antecedent basis for a permission of a first principle and a resource node. However, claims 5 and 16 recite “generating an edge in the security database indicating the permission, between each principal node of the plurality of principal nodes and the resource node”. The permission recited in claims 5 and 16 is between each principal node and the resource node. Not just the first principal node. The recitation of “each principle node” can be different from the “first principal node” recited in claim 1. Therefore, the rejection is being maintained.
With respect to the USC 101 abstract idea rejection, Applicant has argued that the rejection is improper. Examiner respectfully disagrees. Claim 1 recites detecting a plurality of principle nodes in a security database, and representation of a cloud computing environment, selecting a first principal node, detecting a permission between the first principal node and a resource node, and associating the plurality of principal nodes with the detected permission. The claim is simply performing selecting a node, detecting permission, and associating other nodes. All the limitations can be performed by a user manually. A user can manually select in a storage location (security database) a first principal node, detect permissions for the first principal node, and make an association for the plurality of principal nodes based on the detected permission. The claim does not recite any limitation to implement these limitations into a practical application. The claim recites of associating the group of principal nodes with the detected permission. However, merely associating a group of nodes with a detected permission does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea. Furthermore, a security database is a generic form of storing security data and does not include additional elements that are sufficient to amount to significantly more than the judicial exception. Therefore, the USC 101 abstract rejection is being maintained.
With respect to the USC 103 rejection, Applicant has argued that WUEST-MAOR fail to teach the claimed sequence of: (i) selecting, from a plurality of principal nodes, a first principal node that represents all principal nodes of the plurality; (ii) detecting a permission between that representative node and a resource node; and (iii) associating the plurality with the detected permission to indicate that every represented principal has the permission. Examiner respectfully disagrees. MAOR teaches the limitation of “wherein the first principal node is representative of all of the principal nodes of the plurality of principal nodes” ([MAOR, para. 0033] “Turning to FIG. 2, there is shown an exemplary LMP graph 200. The LMP graph 200 is a directed acyclic graph containing one or more nodes connected by edges where the edges have a direction from a source node to a sink node … A node represents entities, such as a … a group … and an edge represents a relationship between the two connected entities. A group may be a group of user accounts, a group of administrators, and a group of devices.”) The teaching of a group node by MAOR is analogous to the first principal node being representative of all of the principal nodes. As seen in para. 0033 of MAOR the group can be of user accounts, a group of administrators, and a group of devices. Therefore, MAOR teaches this limitation. Furthermore, WUEST teaches selecting a first principal node from the plurality of principal nodes, ([WUEST, para. 0074] “Moreover, it is also known that identities can be centralized to one provider or account, and this provides the ability of a particular identity to assume roles in other accounts or clouds.”) As seen from this citation WEUST teaches identities can be centralized to one provider or account. This is similar to the grouping performed by MAOR. WUEST further teaches detecting permissions between the first principal node and a resource node ([WUEST, para. 0078] “FIG. 14 depicts how the cloud intelligence data model and framework previously described is augmented with a least privilege and access framework according to this disclosure. … An effective permissions framework 1410 provides a means to analyze collected permissions as represented in the cloud intelligence model 1404 in conjunction with the audit data to provide an effective permissions model 1412.”) ([WUEST, para. 0078] “FIG. 14 depicts how the cloud intelligence data model and framework previously described is augmented with a least privilege and access framework according to this disclosure. … An effective permissions framework 1410 provides a means to analyze collected permissions as represented in the cloud intelligence model 1404 in conjunction with the audit data to provide an effective permissions model 1412.”). The limitation currently recited of “first principal node is representative of all of the principal nodes” is broad. Being representative of all is taught by the grouping performed by MAOR. Examiner suggests further clarifying the claim language to help better differentiate from the cited prior arts.
Applicant has further argued that any such motivation to combine WUEST-MAOR is moot. Examiner respectfully disagrees. Both references relate to monitoring permissions and associations within a network. Furthermore, MAOR recognizes the need to detect threats ([MAOR, para. 0001] “If a lateral movement is not detected, a global intrusion may result with catastrophic consequences. Often the real time detection of a lateral movement attack may not be caught in time to prevent such catastrophic consequences”) ([MAOR, para. 0014] “The subject matter pertains to the detection of a risky edge in a lateral movement graph that represents a tenant of a cloud service.”). Therefore, the combination of WUEST-MAOR is proper and the rejection is maintained. The same reasoning applies for independent claims 11 and 12.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 5, 11, 12, and 16 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 and 2 of U.S. Patent No. US 12452293 B1. Although the claims at issue are not identical, they are not patentably distinct from each other because the corresponding claims further recite similar/same limitation of the same subject matter.
Current application 19/068,817
U.S. Patent No. US 12452293 B1
1. A method for detecting effective permissions of a principal in a cloud computing environment, comprising: detecting in a security database a plurality of principal nodes, each principal node representing a principal of the cloud computing environment, wherein the security database further includes a representation of the cloud computing environment; selecting a first principal node from the plurality of principal nodes, wherein the first principal node is representative of every principal node of the plurality of principal nodes; detecting a permission between the first principal node and a resource node, wherein the resource node represents a resource deployed in the cloud computing environment; and associating the plurality of principal nodes with the detected permission in the security database to indicate a grant of the detected permission to each principal represented by a corresponding principal node of the plurality of principal nodes.
1. A method for detecting underutilized objects in a cloud computing environment, comprising:
detecting a plurality of resources deployed in a cloud computing environment;
generating for each resource a representation in a security database, the security database including a representation of the cloud computing environment;
generating for each resource a state, based at least on a detected utilization of a respective resource;
detecting, based on the state, a resource of the plurality of resources which is an underutilized resource; and
initiating a mitigation action to disable a permission associated with a principal of the resource on the underutilized resource.
5. The method of claim 1, further comprising:
generating an edge in the security database indicating the permission, between each principal node of the plurality of principal nodes and the resource node.
2. The method of claim 1, further comprising:
generating in the security database an edge connecting a first representation to a second representation, based on at least a detected permission.
Claims 11, 12, and 16 are parallel to claims 1 and 5. Therefore, they are also rejected in a similar manner.
Claims 1-21 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-6, 8, 9, and 20 of U.S. Patent No. US 12278819 B1. Although the claims at issue are not identical, they are not patentably distinct from each other because the corresponding claims further recite similar/same limitation of the same subject matter.
Current application 19/068,817
U.S. Patent No. US 12278819 B1
1. A method for detecting effective permissions of a principal in a cloud computing environment, comprising: detecting in a security database a plurality of principal nodes, each principal node representing a principal of the cloud computing environment, wherein the security database further includes a representation of the cloud computing environment; selecting a first principal node from the plurality of principal nodes, wherein the first principal node is representative of every principal node of the plurality of principal nodes; detecting a permission between the first principal node and a resource node, wherein the resource node represents a resource deployed in the cloud computing environment; and associating the plurality of principal nodes with the detected permission in the security database to indicate a grant of the detected permission to each principal represented by a corresponding principal node of the plurality of principal nodes.
1. A method for detecting effective permissions of a principal in a cloud computing environment, comprising:
detecting a group of principal nodes, each principal node representing a principal in a cloud computing environment, in a security graph, the security graph storing therein a representation of the cloud computing environment;
selecting a first principal node from the group of principal nodes, wherein the first principal node is representative of all of the principal nodes of the group;
determining a permission between the first principal node and a resource node, wherein the resource node represents a resource deployed in the cloud computing environment; and
associating the group of principal nodes with the determined permission thereby representing a grant of the determined permission to each principal node of the group of principal nodes.
2. The method of claim 1, further comprising:
generating the plurality of principal nodes by applying maximal biclique detection on the security database.
4. The method of claim 1, further comprising:
generating the group of principal nodes by applying maximal biclique detection on the security graph.
3. The method of claim 1, further comprising:
receiving at least one of, related to the principal represented by the first principal node: a permission set, an access rule, and an access policy.
5. The method of claim 1, further comprising:
receiving at least one of: a permission set, an access rule, and an access policy.
4. The method of claim 3, further comprising:
detecting the permission between the first principal node and the resource node based on the received at least one of: the permission set, the access rule, and the access policy.
6. The method of claim 5, wherein the permission is determined based on the received at least one of: the permission set, the access rule, and the access policy.
5. The method of claim 1, further comprising:
generating an edge in the security database indicating the permission, between each principal node of the plurality of principal nodes and the resource node.
8. The method of claim 1, further comprising:
generating principal group node representing the group of principal nodes; and
generating an edge between the resource node and the principal group node, wherein the edge represents the determined permission.
6. The method of claim 1, further comprising:
generating in the security database a principal group node representing the plurality of principal nodes; and
generating in the security database an edge between the resource node and the principal group node, wherein the edge represents the detected permission.
8. The method of claim 1, further comprising:
generating principal group node representing the group of principal nodes; and
generating an edge between the resource node and the principal group node, wherein the edge represents the determined permission.
7. The method of claim 6, further comprising:
generating an edge in the security database between each principal node of the plurality of principal nodes and the principal group node.
9. The method of claim 8, further comprising:
generating an edge between each principal node of the group of principal nodes and the principal group node.
8. The method of claim 1, wherein the first principal node represents at least one of:
a user account, a service account, and a role.
2. The method of claim 1, wherein the first principal node represents at least one of: a user account, a service account, and a role.
9. The method of claim 1, wherein the resource node represents at least one of: a virtual machine, a container, a serverless function, and an application.
3. The method of claim 1, wherein the resource node represents at least one of: a virtual machine, a container, a serverless function, and an application.
10. The method of claim 1, wherein the plurality of principal nodes includes at least a first principal node representing a first principal of a first cloud computing environment and a second principal node representing a principal of a second cloud computing environment.
20. The method of claim 1, wherein the group of principal nodes includes at least a first principal node representing a first principal of a first cloud computing environment and a second principal node representing a principal of a second cloud computing environment.
Claims 11-21 are parallel to claims 1-10. Therefore, claims 11-21 are also rejected in a similar manner.
Claims 1, 8-12, and 19-21 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-3, and 9 of U.S. Patent No. US 12278840 B1. Although the claims at issue are not identical, they are not patentably distinct from each other because the corresponding claims further recite similar/same limitation of the same subject matter.
Current application 19/068,817
U.S. Patent No. US 12278840 B1
1. A method for detecting effective permissions of a principal in a cloud computing environment, comprising: detecting in a security database a plurality of principal nodes, each principal node representing a principal of the cloud computing environment, wherein the security database further includes a representation of the cloud computing environment; selecting a first principal node from the plurality of principal nodes, wherein the first principal node is representative of every principal node of the plurality of principal nodes; detecting a permission between the first principal node and a resource node, wherein the resource node represents a resource deployed in the cloud computing environment; and associating the plurality of principal nodes with the detected permission in the security database to indicate a grant of the detected permission to each principal represented by a corresponding principal node of the plurality of principal nodes.
1. A method for generating a security graph utilizing a unified model based on multiple cloud computing environments, comprising:
receiving data from a first cloud computing environment pertaining to: a plurality of resources, a plurality of principals, and a plurality of permissions;
generating for each resource of the plurality of resources a corresponding resource node in the security graph based on the unified model, the corresponding resource node including an identifier of the resource, wherein the resource is a cloud entity deployed in the first cloud computing environment;
generating for each principal of the plurality of principals a corresponding principal node in the security graph based on the unified model, the corresponding principal node including an identifier of the principal, wherein the principal is a cloud entity in the first cloud computing environment that generates a request for an operation in the first cloud computing environment; and
generating a connection between at least a principal node and at least a resource node in the security graph based on the unified model, in response to detecting a permission indicating that a principal corresponding to the at least a principal node can access a resource corresponding to the at least a resource node.
8. The method of claim 1, wherein the first principal node represents at least one of:
a user account, a service account, and a role.
2. The method of claim 1, wherein a principal the plurality of principals is any one of: a user account, a service account, and a role.
9. The method of claim 1, wherein the resource node represents at least one of: a virtual machine, a container, a serverless function, and an application.
3. The method of claim 1, wherein a resource of the plurality of resources is any one of: a virtual machine, a container, and a serverless function.
10. The method of claim 1, wherein the plurality of principal nodes includes at least a first principal node representing a first principal of a first cloud computing environment and a second principal node representing a principal of a second cloud computing environment.
9. The method of claim 6, further comprising:
generating an entity node in the security graph;
connecting a first principal node from the first cloud computing environment to the entity node; and
connecting a second principal node from the second cloud computing environment to the entity node, in response to determining that the first principal node and the second principal node represent a single entity.
Claims 11, 12, and 19-21 are parallel to claims 1, 8-10. Therefore, claims 11, 12, and 19-21 are also rejected in a similar manner.
Claims 1, 8, 10-12, 19, and 21 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 and 4 of U.S. Application No. 17/812,918. Although the claims at issue are not identical, they are not patentably distinct from each other because the corresponding claims further recite similar/same limitation of the same subject matter.
A Notice of Allowance has been issued for application 17/812,918. However, a patent number has not been issued at the time of this office action.
Current application 19/068,817
U.S. Application No. 17/812,918
1. A method for detecting effective permissions of a principal in a cloud computing environment, comprising: detecting in a security database a plurality of principal nodes, each principal node representing a principal of the cloud computing environment, wherein the security database further includes a representation of the cloud computing environment; selecting a first principal node from the plurality of principal nodes, wherein the first principal node is representative of every principal node of the plurality of principal nodes; detecting a permission between the first principal node and a resource node, wherein the resource node represents a resource deployed in the cloud computing environment; and associating the plurality of principal nodes with the detected permission in the security database to indicate a grant of the detected permission to each principal represented by a corresponding principal node of the plurality of principal nodes.
1. A method for detecting a permission escalation event, comprising: detecting that a second principal node, representing a second principal, has a permission to assume a first principal, represented by a first principal node, wherein the first principal node and the second principal node are each nodes of a security graph that is a representation of a combination of a first cloud computing environment and at least a second cloud computing environment, the security graph using a unified model so that each principal of the first cloud computing environment and each principal of the second cloud computing environment are represented in the security graph in a standardized way, the first principal being deployed in one of the first cloud computing environment and the second cloud computing environment and second principal being deployed in one of the first cloud computing environment and the second cloud computing environment, the detecting being performed by querying the security graph to detect principal nodes that are connected to the first principal node; determining that another permission is a dangerous permission; determining that the first principal node has access to the another permission which is not accessible by the second principal node; generating a dangerous permission event, in response to determining that the first principal node is associated with the dangerous permission; and generating a permission escalation event alert.
8. The method of claim 1, wherein the first principal node represents at least one of: a user account, a service account, and a role.
4. The method of claim 1, wherein the first principal node is any one of: a user account, a service account, and a role.
10.) 10. The method of claim 1, wherein the plurality of principal nodes includes at least a first principal node representing a first principal of a first cloud computing environment and a second principal node representing a principal of a second cloud computing environment.
1. … wherein the first principal node and the second principal node are each nodes of a security graph that is a representation of a combination of a first cloud computing environment and at least a second cloud computing environment …
Claims 11, 12, 19, and 21 are parallel to claims 1, 8, and 10. Therefore, claims 11, 12, 19, and 21 are also rejected in a similar manner.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 5 and 16 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 5 and 16 recite the limitation “indicating the permission, between each principal node of the group of principal nodes and the resource node.”. There is insufficient antecedent basis for this limitation in the claim. For the purpose of examination Examiner is interpreting this limitation as “indicating a permission, between each principal node of the group of principal nodes and the resource node”. The principle recited in claim 1 states “detecting a permission between the first principal node and a resource node”. The principle for the first principle node can be different for the other principle nodes. Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-21 are rejected under 35 U.S.C. 101 because they directed to an abstract idea.
Claim 1 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites a judicial exception (an abstract idea) that is not integrated into a practical application.
Step 1: Statutory Category
Claim 1 satisfieds the statutory category requirement because it is directed to a method claim under 35 U.S.C. 101(a).
Step 2A, Prong 1 – Judicial Exception (Abstract Area)
The claim recites a method for detecting effective permissions of a principal in a cloud computing environment, comprising: detecting in a security database a plurality of principal nodes, each principal node representing a principal of the cloud computing environment, wherein the security database further includes a representation of the cloud computing environment; selecting a first principal node from the plurality of principal nodes, wherein the first principal node is representative of every principal node of the plurality of principal nodes; detecting a permission between the first principal node and a resource node, wherein the resource node represents a resource deployed in the cloud computing environment; and associating the plurality of principal nodes with the detected permission in the security database to indicate a grant of the detected permission to each principal represented by a corresponding principal node of the plurality of principal nodes.
The limitation of detecting effective permissions of a principal in a cloud computing environment, comprising: detecting in a security database a plurality of principal nodes, each principal node representing a principal of the cloud computing environment, wherein the security database further includes a representation of the cloud computing environment, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can be performed in the mind. A user can manually detect in a security database a plurality of principal nodes.
The limitation of electing a first principal node from the plurality of principal nodes, wherein the first principal node is representative of every principal node of the plurality of principal nodes, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can be performed in the mind. A user can manually select a first principal node from the plurality of principal nodes.
The limitation of detecting a permission between the first principal node and a resource node, wherein the resource node represents a resource deployed in the cloud computing environment, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can be performed in the mind. A user can manually detect a permission between the first principal node and a resource node.
The limitation of associating the plurality of principal nodes with the detected permission in the security database to indicate a grant of the detected permission to each principal represented by a corresponding principal node of the plurality of principal nodes, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can be performed in the mind. A user can manually associate the group of principal nodes with the detected permission in the security database to indicate a grant of the detected permission to each principal represented by a principal node of the plurality of principal nodes.
Step 2A, Prong 2 – Integration into a practical Application
This judicial exception is not integrated into a practical application. The claim recites of detecting a plurality of principal nodes, selecting a principal node, detecting a permission, and associating the group of principal nodes with the detected permission. The claim does not recite any limitation to implement these limitations into a practical application. The claim recites of associating the group of principal nodes with the detected permission. However, merely associating a group of nodes with a detected permission does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
Step 2B- “Significantly More” (Inventive concept)
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. The claim recites of a “security database”. However, a security database recited at a high-level of generality amounts to no than a generic database or data structure storing data. The claim is not patent eligible.
Claim 2 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of generating the plurality of principal nodes by applying maximal biclique detection on the security database. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually generate plurality of principal nodes by applying maximal biclique detection.
Claim 3 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of receiving at least one of, related to a first principal represented by the first principal node: a permission set, an access rule, and an access policy. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually receive a permission set, an access rule, or an access policy.
Claim 4 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of detecting the permission between the first principal node and the resource node based on the received at least one of: the permission set, the access rule, and the access policy. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually detect the permission between the first principal node and the resource node.
Claim 5 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of generating an edge in the security database indicating the permission, between each principal node of the plurality of principal nodes and the resource node. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually generate an edge in the security database indicating the permission, between each principal node of the group of principal nodes and the resource node.
Claim 6 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of generating in the security database a principal group node representing the plurality of principal nodes; and generating in the security database an edge between the resource node and the principal group node, wherein the edge represents the detected permission. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually generate in the security database a principal group node representing the group of principal nodes and generate in the security database an edge between the resource node and the principal group node, wherein the edge represents the detected permission.
Claim 7 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of generating an edge in the security database between each principal node of the plurality of principal nodes and the principal group node. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually generate an edge in the security database between each principal node of the plurality of principal nodes and the principal group node.
Claim 8 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of herein the first principal node represents at least one of: a user account, a service account, and a role. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually determine a first principal node represents a user account, a service account, or a role.
Claim 9 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of wherein the resource node represents at least one of: a virtual machine, a container, a serverless function, and an application. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually determine a resource node represents at least one of: a virtual machine, a container, a serverless function, and an application.
Claim 10 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of wherein the plurality of principal nodes includes at least the first principal node representing a first principal of the cloud computing environment and a second principal node representing a principal of a second cloud computing environment. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually determine a first principal node representing a first principal of a first cloud computing environment and a second principal node representing a principal of a second cloud computing environment.
Claim 11 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites a judicial exception (an abstract idea) that is not integrated into a practical application.
Step 1: Statutory Category
Claim 11 satisfied the statutory category requirement because it is directed to a non-transitory computer-readable medium storing a set of instructions which are executed by one or more processors claim under 35 U.S.C. 101(a).
Step 2A, Prong 1 – Judicial Exception (Abstract Area)
The same Step 2A, Prong 1 analysis as seen in the rejection of claim 1 applies.
Step 2A, Prong 2 – Integration into a practical Application
The same Step 2A, Prong 2 analysis as seen in the rejection of claim 1 applies.
Step 2B- “Significantly More” (Inventive concept)
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. In particular, the claim only recites one additional element of “one or more processors of a device” recited at a high-level of generality (i.e., as a generic processor implementing the instructions) such that it amounts no more than mere instructions to apply the exception using a generic processor. Mere instructions to apply an exception using a generic processor cannot provide an inventive concept. The claim is not patent eligible.
Claim 12 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites a judicial exception (an abstract idea) that is not integrated into a practical application.
Step 1: Statutory Category
Claim 12 satisfied the statutory category requirement because it is directed to a system comprising memory and a processing circuitry under 35 U.S.C. 101(a).
Step 2A, Prong 1 – Judicial Exception (Abstract Area)
The same Step 2A, Prong 1 analysis as seen in the rejection of claim 1 applies.
Step 2A, Prong 2 – Integration into a practical Application
The same Step 2A, Prong 2 analysis as seen in the rejection of claim 1 applies.
Step 2B- “Significantly More” (Inventive concept)
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. In particular, the claim only recites one additional element of “processing circuitry” recited at a high-level of generality (i.e., as a generic processor implementing the instructions) such that it amounts no more than mere instructions to apply the exception using a generic processor circuitry. Mere instructions to apply an exception using a generic processor circuitry cannot provide an inventive concept. The claim is not patent eligible.
Claims 13-21 are recite similar features to that of claims 2-10. Therefore, claims 13-21 are rejected in a similar manner.
The dependent claims 2-10, and 13-21 are directed to abstract ideas and do not include additional elements that are sufficient to amount to significantly more than the judicial exception. This judicial exception is not integrated into a practical application. Therefore, the claims are not patent eligible.
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.
Claims 1, 3, 4, 8-12, 14, 15, and 19-21 are rejected under 35 U.S.C. 103 as being unpatentable over WUEST (US-20200336489-A1) in view of MAOR (US-20210203684-A1), hereinafter WUEST-MAOR.
Regarding claim 1, WUEST teaches “A method for detecting effective permissions of a principal in a cloud computing environment, comprising: ([WUEST, para. 0038] “The cloud intelligence model 100 is central to the framework, as it enables the CDC service to provide a subscriber a view of all identity and data activity in the enterprise's cloud accounts. … As will be described, this solution provides a unified approach to modelling data, identity, infrastructure and protection. Preferably, the model 100 comprises an object model (e.g., all cloud entities and their corresponding properties, the allowed connections between and among cloud entities, and multi-level interfaces for the cloud entities), storage properties (e.g., index, types, etc.) for all or some of the above, and query properties of the object model.”) ([WUEST, para. 0079] “The cloud intelligence and data model framework 1400 provides for cloud intelligence (data) ingestion, normalization and storage. As previously explained, this framework provides a mechanism for resources and their associated permissions to be collected and normalized across multiple cloud providers and accounts. … The model also enables the effective permissions framework 1410 to roll-up all “permissions” and “identity chains” associated with a given “originating identity.” The model also facilitates providing the data access mapping framework 1414 to map data resources to identities through the determined effective permissions.”) ([WUEST, para. 0067] “FIG. 11 depicts an example of how a relation of an Identity (Bob) is determined to have WRITE access to a Resource (Files). In this example, Identity 1100 is a member of a Group 1102. The Identity 1100 has an attached Policy 1104, which in this example is also attached to the Group 1102. The Policy 1104 has a PolicyVersion 1106 that has a PolicyEntry 1108. The PolicyEntry 1108 has an associated PermissionList 1110 comprising permissions.”) [Examiner’s note: Examiner is interpreting an Identity as a principal.] detecting in a security database a plurality of principal nodes, each principal node representing a principal of the cloud computing environment, wherein the security database further includes a representation of the cloud computing environment; ([WUEST, para. 0078] “The effective permissions model 1412 is read by a data access mapping framework 1414, and frameworks 1414 distills what data identities have access to, as well as whether those identities have access that data; this produces an identity-to-data mapping 1416 (what identities have access to what data). As also depicted, and as will be further described below, a least privilege and access framework 1418”) ([WUEST, para. 0038] “The cloud intelligence model 100 is central to the framework, as it enables the CDC service to provide a subscriber a view of all identity and data activity in the enterprise's cloud accounts. … In a representative, but non-limiting embodiment, the model 100 is a cloud environment data model for a particular subscriber that is based on observed patterns across multiple cloud environments. As will be described, this solution provides a unified approach to modelling data, identity, infrastructure and protection. Preferably, the model 100 comprises an object model (e.g., all cloud entities and their corresponding properties, the allowed connections between and among cloud entities, and multi-level interfaces for the cloud entities), storage properties (e.g., index, types, etc.) for all or some of the above, and query properties of the object model.”) ([WUEST, para. 0039] “The intelligence bundle 115 includes the information about the cloud accounts, resources, etc. that the subscriber has provisioned in or is other using in each such cloud compute deployment. … a bundle is associated with an enterprise subscriber and encapsulates the subscriber's data (e.g., identity and data activity, etc.) retrieved from each cloud deployment being used by the subscriber. “) selecting a first principal node from the plurality of principal nodes, … ; ([WUEST, para. 0074] “Moreover, it is also known that identities can be centralized to one provider or account, and this provides the ability of a particular identity to assume roles in other accounts or clouds.”) ([WUEST, para. 0080] “In this example (which also further elaborates on the example in FIG. 13), the originating identity 1500 (e.g., provided by an identity provider 1501) is the actual identity that performs the action. Thus, if user “Bob” 1500 in Account A 1502 assumes Role 1504 in Account B 1506 and performs a certain action (e.g., a ListBuckets command), the originating identity is user “Bob.” In this example, (user Bob in Account A assuming Role Developer in Account B), the identity chain represented is then “User Bob, Role Developer.” More formally, the identity chain is a list of identifies (including the originating identity) that are used to gain the permissions. As also previously described, permissions in dynamic cloud environments often come from a number of places (e.g., on the identity, through a group, through an account or organization, from a policy on another resource, etc.) The effective permissions for a given identify are then the actual intersection of all the permissions associated with the identity into one set (the effective permissions), which represent the one truth on what that identity actually has permission to do.”) detecting a permission between the first principal node and a resource node, wherein the resource node represents a resource deployed in the cloud computing environment; and ([WUEST, para. 0078] “FIG. 14 depicts how the cloud intelligence data model and framework previously described is augmented with a least privilege and access framework according to this disclosure. … An effective permissions framework 1410 provides a means to analyze collected permissions as represented in the cloud intelligence model 1404 in conjunction with the audit data to provide an effective permissions model 1412.”) ([WUEST, para. 0074] “understanding the exact permission set for a given identity (this is due to the complexity in the number of ways an identity can be granted permissions to cloud services and resources”) ([WUEST, para. 0093] “The least privilege/access framework 1904 queries the cloud intelligence model 1921 and (through its analytical framework 1905) calculates the optimal identity and data policies 1907 for the monitored resources.”) ([WUEST, para. 0080] “if user “Bob” 1500 in Account A 1502 assumes Role 1504 in Account B 1506 and performs a certain action (e.g., a ListBuckets command), the originating identity is user “Bob.” … permissions in dynamic cloud environments often come from a number of places (e.g., on the identity, through a group, through an account or organization, from a policy on another resource, etc.)”) associating the plurality of principal nodes with the detected permission in the security database to indicate a grant of the detected permission to each principal represented by a corresponding principal node of the plurality of principal nodes. ([WUEST, para. 0079] “Further, and as also previously described, the cloud intelligence model provides several advantages: it enables the originating user resolution framework 1408 (described below) that understands a current state of identities and their associated access keys. The model also enables the effective permissions framework 1410 to roll-up all “permissions” and “identity chains” associated with a given “originating identity.” The model also facilitates providing the data access mapping framework 1414 to map data resources to identities through the determined effective permissions.”) ([WUEST, para. 0080] “the identity chain is a list of identifies (including the originating identity) that are used to gain the permissions. As also previously described, permissions in dynamic cloud environments often come from a number of places (e.g., on the identity, through a group, through an account or organization, from a policy on another resource, etc.) The effective permissions for a given identify are then the actual intersection of all the permissions associated with the identity into one set (the effective permissions), which represent the one truth on what that identity actually has permission to do.”)
However, WUEST does not teach “… wherein the first principal node is representative of every principal node of the plurality of principal nodes … “
In analogous teaching MAOR teaches “… wherein the first principal node is representative of all of the principal nodes of the plurality of principal nodes …” ([MAOR, para. 0033] “Turning to FIG. 2, there is shown an exemplary LMP graph 200. The LMP graph 200 is a directed acyclic graph containing one or more nodes connected by edges where the edges have a direction from a source node to a sink node … A node represents entities, such as a … a group … and an edge represents a relationship between the two connected entities. A group may be a group of user accounts, a group of administrators, and a group of devices.”) ([MAOR, para. 0036] “The LMP graph 200 also associates a label to each node that indicates whether a node is sensitive or non-sensitive. A sensitive node represents a device, user account or group that has permissions, privileges, and/or credentials to highly-sensitive data. A sensitive designation may be applied to administrators, power users, account operators, domain administrators, domain controllers, group policy creator owners, and so forth.”) [Examiner’s note: Examiner is interpreting a group node as the first principal node representing all the plurality of other principals such as user accounts.]
Thus, given the teaching of MAOR, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine the teaching of the first principal node is representative of all of the principal nodes by MAOR into the teaching of detecting permissions and utilizing a security database by WUEST. One of ordinary skill in the art would have been motivated to do so because MAOR recognizes the need to detect threats ([MAOR, para. 0001] “If a lateral movement is not detected, a global intrusion may result with catastrophic consequences. Often the real time detection of a lateral movement attack may not be caught in time to prevent such catastrophic consequences”) ([MAOR, para. 0014] “The subject matter pertains to the detection of a risky edge in a lateral movement graph that represents a tenant of a cloud service.”).
Regarding claim 11, this claim recites of a non-transitory computer-readable medium storing a set of instructions which once executed by a processor performs the steps of method claim 1. Therefore, claim 11 is rejected in a similar manner as in the rejection of claim 1.
Regarding claim 12, this claim recites of a system that performs the features of method claim 1. Therefore, claim 12 is rejected in a similar manner as in the rejection of claim 1.
Regarding claims 3 and 14, WUEST-MAOR teach all limitations of claims 1 and 12. WUEST further teaches “receiving at least one of, related to a first principal represented by the first principal node: a permission set, an access rule, and an access policy. ([WUEST, para. 0066] “In FIG. 7, which is an example, Identity 702 is performed on an Action 704, which in turn is performed with respect to a Resource 706 that is part of a Service 708. Service 708 is part of an Account 710, which in turn is an account that is provisioned by a cloud provider 712. … the unified classification model ties to a permission model in a cloud intelligence model. In this example, Policy 800 has a PolicyVersion 802, which in turn has a PolicyEntry 804. The PolicyEntry 804 has a PermissionList 806 that allows or denies individual Permissions, which of which is represented as Permission 808. The Permission 808 has an associated ServiceType 810 and ActionType 812, with these types having associated Service- and Action- Classifications 814 and 816.”) ([WUEST, para. 0067] “The Policy 1104 manages one or more resources, such as Resource 1120. Within the collected data there are many paths (several are displayed here) which can identify that “BOB” has “WRITE” access to the Resource “FILES.””) ([WUEST, para. 0077] “The notion of “least privilege” refers to the notion of determining a set of minimum permissions that are associated to a given identity; the notion of “least access” refers to determining a minimal set of persons that need to have access to given piece data.”)
Regarding claims 4 and 15, WUEST-MAOR teach all limitations of claims 3 and 14. WUEST further teaches “detecting the permission between the first principal node and the resource node based on the received at least one of: the permission set, the access rule, and the access policy. ([WUEST, para. 0066] “In FIG. 7, which is an example, Identity 702 is performed on an Action 704, which in turn is performed with respect to a Resource 706 that is part of a Service 708. Service 708 is part of an Account 710, which in turn is an account that is provisioned by a cloud provider 712. … the unified classification model ties to a permission model in a cloud intelligence model. In this example, Policy 800 has a PolicyVersion 802, which in turn has a PolicyEntry 804. The PolicyEntry 804 has a PermissionList 806 that allows or denies individual Permissions, which of which is represented as Permission 808. The Permission 808 has an associated ServiceType 810 and ActionType 812, with these types having associated Service- and Action- Classifications 814 and 816.”) ([WUEST, para. 0067] “The Policy 1104 manages one or more resources, such as Resource 1120. Within the collected data there are many paths (several are displayed here) which can identify that “BOB” has “WRITE” access to the Resource “FILES.””)
Regarding claims 8 and 19, WUEST-MAOR teach all limitations of claims 1 and 12. WUEST further teaches “wherein the first principal node represents at least one of: a user account, a service account, and a role. ([WUEST, para. 0078] “As also depicted, an originating user resolution framework 1408 provides a means to associate normalized cloud audit data (provided by the ingestion pipeline 1402 with actual originating identity.”) ([WUEST, para. 0080] “ In this example (which also further elaborates on the example in FIG. 13), the originating identity 1500 (e.g., provided by an identity provider 1501) is the actual identity that performs the action. Thus, if user “Bob” 1500 in Account A 1502 assumes Role 1504 in Account B 1506 and performs a certain action (e.g., a ListBuckets command), the originating identity is user “Bob.””)
Regarding claims 9 and 20, WUEST-MAOR teach all limitations of claims 1 and 12. WUEST further teaches “wherein the resource node represents at least one of: a virtual machine, a container, a serverless function, and an application. ([WUEST, para. 0029] “As described, cloud computing is a model of service delivery for enabling on-demand network access to a shared pool of configurable computing resources (e.g. networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services)”)
Regarding claims 10 and 21, WUEST-MAOR teach all limitations of claims 1 and 12. WUEST further teaches “wherein the plurality of principal nodes includes at least a first principal node representing the first principal of the cloud computing environment and a second principal node representing a principal of a second cloud computing environment. ([WUEST, para. 0071] “The approach provides an enterprise with a total view of all identity and data activity in its cloud accounts. The system enables cloud provider management models to be normalized with centralized analytics and views across large numbers of cloud accounts (e.g., AWS/GCP accounts, Azure subscriptions/resource groups, etc.)”) ([WUEST, para. 0074] “in enterprise environments the “architecture” of identity can vary greatly. Distinct identity models may exist within the major cloud providers (e.g., Amazon® AWS® Identity Access & Management (TAM)), Microsoft® Azure® Active Directory, Google® Identity Access & Management (IAM))”) ([WUEST, para. 0077] “the least privilege and access framework enables the cloud data control system to apply least privilege and access policies to cloud identities and data across a dynamic cloud environment that spans multiple cloud providers and accounts.”)
Claims 2 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over WUEST-MAOR in view of TURNER (US-9607104-B1).
Regarding claims 2 and 13, WUEST-MAOR teach all limitations of claims 1 and 12. However, WUEST-MAOR does not teach “generating the plurality of principal nodes by applying maximal biclique detection on the security database.”
In analogous teaching TURNER teaches “generating the plurality of principal nodes by applying maximal biclique detection on the security database. ([TURNER, col. 9 lines 11-19] “FIG. 1 may be configured to execute queries corresponding to logical operations that are performed when determining “quasi-maximal” bicliques (e.g., bicliques that are maximal, near-maximal, or sufficiently large to be of interest). When a bigraph links user profiles to attribute tiles, as in FIG. 2, determining bicliques or maximal bicliques can be useful to identify groups of seemingly unrelated users (profiles) that all share common attributes (tiles).”).
Thus, given the teaching of TURNER, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine the teaching of biclique detection by TURNER into the teaching of detecting permissions and utilizing a security database by WUEST-MAOR. One of ordinary skill in the art would have been motivated to do so because TURNER recognizes the benefits of using biclique detection ([TURNER, col. 2 lines 4-18] “Determining bicliques and maximal bicliques is a computationally expensive N-P hard problem to which there is no known polynomial time solution, due to how much larger the search space becomes when even a single additional node is added to either side of a bigraph. … The systems and methods of the present disclosure enable determining bicliques on large data sets by leveraging an in-memory (e.g., in random access memory (RAM)) bitmap index that represents the large data set, or at least a subset thereof, and by distributing computation across an arbitrary number of computing devices.”).
Claims 5, 6, 16, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over WUEST-MAOR in view of BARGURY (US-20210243190-A1).
Regarding claims 5 and 16, WUEST-MAOR teach all limitations of claims 1 and 12. However, WUEST-MAOR does not teach “generating an edge in the security database indicating the permission, between each principal node of the plurality of principal nodes and the resource node.”
In analogous teaching BARGURY teaches “generating an edge in the security database indicating the permission, between each principal node of the plurality of principal nodes and the resource node. ([BARGURY, para. 0004] “The graph includes nodes that represent an identity, a permission or a resource and edges that identify the assigned permissions to a resource and the usage activity of a resource by an identity.”) ([BARGURY, para. 0037] “An identity-resource-permission graph is a directed acyclic graph having nodes connected to edges. There are three types of nodes. A first node type (type 1) represents an identity which may be a user account, an application, process, or a user group. A second node type (type 2) represents one or more permissions and the third node type (type 3) represents a resource. There are two types of edges. The first edge type represents the assignment relationship between the two connected nodes. The second edge type represents the usage activity associated with the two connected nodes.”)
Thus, given the teaching of BARGURY, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine the teaching of generating an edge in the security database indicating the permission by BARGURY into the teaching of detecting permissions and utilizing a security database by WUEST-MAOR. One of ordinary skill in the art would have been motivated to do so because BARGURY recognizes the need to prevent broad permissions ([BARGURY, para. 0001] “One such security vulnerability is created when broad permissions are granted to a user account, application or process that exceeds the permissions needed to perform legitimate, intended tasks. The assignment of broad permissions may lead to unintentional and malicious changes and data leaks.”) ([BARGURY, para. 0015] “Aspects of the present invention address the identification of the bare minimum permission needed for an identity (e.g., user account, process, user group, and application) to accomplish a legitimate task in a computing environment.”)
Regarding claims 6 and 17, WUEST-MAOR teach all limitations of claims 1 and 12. However, WUEST-MAOR does not teach “generating in the security database a principal group node representing the plurality of principal nodes; and generating in the security database an edge between the resource node and the principal group node, wherein the edge represents the detected permission.”
In analogous teaching BARGURY teaches “generating in the security database a principal group node representing the plurality of principal nodes; and ([BARGURY, para. 0037] “A first node type (type 1) represents an identity which may be a user account, an application, process, or a user group.”) ([BARGURY, para. 0034] “An organization chart 122 identifies the peers of a user or user account within an entity or organization that utilize the resources of the cloud service 102. Alternatively, the organization chart 122 may be a listing of related groups of users working on a same project.”) generating in the security database an edge between the resource node and the principal group node, wherein the edge represents the detected permission. ([BARGURY, para. 0038] “As shown in FIG. 2A, graph 200 has nodes 202, 204, 206 and edges 208, 210. Node 202 is a type 1 node that represents a user account, an application, or user group. Node 204 is a type 2 node which represents one or more permissions and node 206 is a type 3 node which represents resources. Edges 208, 210 are assignment edges. Edge 208 represents that user account A is assigned a read permission and edge 210 represents that the read permission is to resource B.”) ([BARGURY, para. 0042] “The permission management engine 132 obtains the user accounts, applications, processes, and user groups that are configured with a permission to access a resource in a particular tenant.”)
The same motivation to modify WUEST-MAOR with BARGURY as in the rejection of claim 5 applies.
Claims 7 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over WUEST-MAOR-BARGURY in view of BELLINGER (US-20220284362-A1)
Regarding claims 7 and 18, WUEST-MAOR-BARGURY teach all limitations of claims 6 and 17. However, WUEST-MAOR-BARGURY does not teach “generating an edge in the security database between each principal node of the plurality of principal nodes and the principal group node.”
In analogous teaching BELLINGER teaches “generating an edge in the security database between each principal node of the plurality of principal nodes and the principal group node. ([BELLINGER, para. 0028] “An organizational graph service may maintain an organizational graph for an organization. The organizational graph may be comprised of user nodes and group nodes. The user nodes may represent members (e.g., employees) of the organization, and the group nodes may represent teams, projects, clients, positions, or other organizational relationship types. Each node in the organizational graph may include at least one edge. As described herein, an edge defines a relationship type between users and/or groups in an organization. Each edge in a node may be traversable to at least one other node in the organizational graph. For example, an edge of a first user node that defines a specific team of an organization may be traversable to an edge of a second user node that also defines that specific team of the organization. Similarly, an edge of a user node that defines a project for a specific client of an organization may be traversable to an edge of a group node corresponding to that specific client, as well as to an edge of a group node corresponding to that project.”).
Thus, given the teaching of BELLINGER, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine the teaching of nodes connected to a group node by BELLINGER into the teaching of detecting permissions and utilizing security database by WUEST-MAOR-BARGURY. One of ordinary skill in the art would have been motivated to do so because BELLINGER recognizes the benefits of viewing graphs ([BELLINGER, para. 0001] “It is useful for large organizations to have the ability to view their employees and employees' relationships with one another in a diagramed form via computer programs and graphical user interfaces. These types of diagrams are generally called “organizational charts”.”).
Pertinent Art
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
MUKKARA (US-20120297183-A1): This prior art teaches storage in cloud or shared storage environments are provided. A unique signature is generated within a cloud or shared storage environment for each file of the storage tenant that accesses the cloud or shared storage environment. Each signature is stored as part of the file system and every time a file is accessed that signature is verified. When a file is updated, the signature is updated as well to reflect the file update.
KROEHLING (US-20170222997-A1): This prior art teaches of a method performed by a computing system includes receiving from a client component of an enterprise application, a request destined for a service component of the enterprise application, the request comprising authentication data and request data, the authentication data being associated with a current user of the client component, the user associated with an organization. The method further includes performing an authentication process to create principal data and role data associated with the request, the principal data identifying a user. The method further includes using the authentication data and request data, determining a current tenant of the client component. The method further includes replacing the principal data with updated principal data, the updated principal data identifying the organization. The method further includes updating the role data associated with the request to create updated role data that indicates roles of the user within the organization.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AFAQ ALI whose telephone number is (571)272-1571. The examiner can normally be reached Mon - Fri 7:30am - 5:30pm EST.
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, ALI SHAYANFAR can be reached at (571) 270-1050. 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.
/A.A./
09/18/2026
/AFAQ ALI/Examiner, Art Unit 2434
/NOURA ZOUBAIR/Primary Examiner, Art Unit 2434
Prosecution Insights