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 .
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, 13-14, and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Di Girolamo et al. (U.S. Patent No. US 20200220919 A1), hereinafter “Di Girolamo” in view of Lukanov et al. (U.S. Patent No. US 20230224304 A1), hereinafter “Lukanov” and Sadhani et al. (U.S. Patent No. US 20240028484 A1), hereinafter “Sadhani.”
With regards to Claim 1, Di Girolamo teaches:
said method comprising: creating, by an owner controller using one or more processors of a computer system, a base layer of the layering resource representation, wherein the base layer consists of a resource field tree of the entire resource (Fig. 9A, paragraph 146, “In example embodiments, a Service Layer (SL) may host a number of resources, which may be distributed across a Physical Resource Tree (PRT). During their lifetime, these resources may become part of one or more Overlay Resource Trees (ORTs). FIG. 9A illustrates an example of a PRT hosted on a server. The hierarchy of a PRT may be created “automatically” as resources are created on the server.” The physical resource tree being created automatically as resources are created on the server would include all created resources and therefore correlates to creating a base layer of the layering resource representation, wherein the base layer consists of a resource field tree of the entire resource); and
after said creating the base layer, creating, by one or more collaborator controllers using the one or more processors, respective one or more overlay layers of the layering resource representation, wherein each overlay layer consists of a sub-tree of the resource field tree (Fig. 9B and 10B, paragraphs 117, 146-147, 161, and 165, “An <overlay> resource may be created by an ORT Producer and may contain the following attributes… Overlay Resource Trees may be implemented in any feasible manner. In example embodiments, a Service Layer (SL) may host a number of resources, which may be distributed across a Physical Resource Tree (PRT). During their lifetime, these resources may become part of one or more Overlay Resource Trees (ORTs)… An <overlay> resource may define a single ORT… FIG. 9B illustrates an Overlay Resource Tree associated with the PRT of FIG. 9A that has restructured the shaded resources into three hierarchical levels. As shown in FIG. 9, the ORT does not need to account for every resource in the PRT… In a second example embodiment, illustrated in FIG. 10B as a “Link based” overlay, an ORT Host may create new stand-in overlay resources to match a desired ORT. Such overlay resources may act as replacements for physical resources and link to the actual physical resources… To implement the ORT of FIG. 9B in such an example embodiment, new resources R1′, R3′, R4′, and R5′ may be created. Each new resource may be marked as being an overlay resource, and each may link back to the original resource.” The ORT producer creating overlay resources to define an overlay resource tree based on the existing PRT correlates to creating, by one or more collaborator controllers using the one or more processors, respective one or more overlay layers of the layering resource representation after creating the base layer. The ORT not needing to account for every resource in the PRT correlates to each overlay layer consisting of a sub-tree of the resource field tree),
wherein each collaborator controller is authorized to update each field of the sub-tree created by said each collaborator controller (Paragraph 191, “An ORT may need to be updated on an ORT Host. If a requester updates the <overlay> resource or its associated <dynamicOverlayTemplate> resource, the ORT Host may need to re-form the ORT. The requester may request to remove a branch from the ORT, to add a branch to the ORT, or to change the overlay template. For each request, the ORT Host may perform the following process. The ORT Host may check if the requester has access rights to update the ORT. If the requester is the ORT Producer of the ORT, then the ORT Host may re-form the overlay and may need to update attributes and/or create resources on the PRT. For example, the ORT Host may use one of the methods described above to re-form the ORT: Attribute Based; Link Based; or Copy Based.” The ORT host checking if the requestor has access rights to update the ORT before allowing the attributes to be updated correlates to each collaborator controller being authorized to update each field of the sub-tree created by said each collaborator controller), and
wherein any field of the sub-tree that is updated by the collaborator controller that created the sub-tree replaces any previous updating of said any field by the owner controller (Paragraph 191, “An ORT may need to be updated on an ORT Host. If a requester updates the <overlay> resource or its associated <dynamicOverlayTemplate> resource, the ORT Host may need to re-form the ORT. The requester may request to remove a branch from the ORT, to add a branch to the ORT, or to change the overlay template. For each request, the ORT Host may perform the following process. The ORT Host may check if the requester has access rights to update the ORT. If the requester is the ORT Producer of the ORT, then the ORT Host may re-form the overlay and may need to update attributes and/or create resources on the PRT. For example, the ORT Host may use one of the methods described above to re-form the ORT: Attribute Based; Link Based; or Copy Based.” The ORT producer requesting attributes to be updated in the overlay resource correlates to any field of the sub-tree being updated by the collaborator controller that created the sub-tree. The re-forming of the ORT resulting in a difference between the ORT and the PRT, which causes the PRT to be updated to match the ORT, correlates to the updated field of the sub-tree replacing any previous updating of said any field by the owner controller).
Di Girolamo does not explicitly teach:
A method for generating and using a layering resource representation of resource in a container orchestration platform,
wherein each collaborator controller is not authorized to update any other field of the resource field tree,
However, Sadhani teaches:
A method for generating and using a layering resource representation of resource in a container orchestration platform (Paragraphs 31 and 38, “In some implementations, the application discovery controller 270 interacts with the API server 260 to discover Kubernetes resources of an application, and constructs a resource hierarchy of the application based on the discovered Kubernetes resources, store the resource hierarchy of the application in a data structure such as an application custom resource 240, and send the application custom resource 240 to the API server 260… The data protection service 220 can use the application custom resource 240 to render a visual representation of the resource hierarchy of the application (e.g., an application resource graph) using the user interface 230 to present to the users… FIG. 4 is a flowchart illustrating an example method 400 for automatic discovery of application resources for application backup in a container orchestration platform (e.g., a Kubernetes system), in accordance with example implementations of technology described herein.” The application discovery controller discovering application resources in a container orchestration system to construct a resource hierarchy which can be used to render a visual representation correlates to generating and using a layering resource representation of resource in a container orchestration platform),
Additionally, Lukanov teaches:
wherein each collaborator controller is not authorized to update any other field of the resource field tree (Paragraphs 28-29, “User group A can be associated with the first container (corresponding to all the resources), and user group B would be associated with the second container (corresponding to sub-tree X) … The RBAC model may provide the administrator role with permissions to perform a certain operation on a resource, e.g., delete a resource. However, based on defining access rights according to the RBAC-based model and further filtered based on the definition of containers and container membership mapping tenants to containers, an administrator of user group B is not provided with rights to delete a resource that is outside of the second container. In particular, an administrator of user group B may not be allowed to delete a root node of the resource directory tree, however, an administrator of user group A could be allowed to delete that root node of the resource directory. In practice and for example, users of user group B may be provided with read access to the root node and other preceding nodes between the root node to the root node of the sub-tree X that form a direct path between the two nodes. In that example, users of user group B may not be provided with any access to read, write, and review, among other examples, for nodes that are outside the nodes of the sub-tree X and are not part of a direct route between the root node of the tree structure of the resource directory and the root node of the sub-tree X.” The administrator of user group B being associated with sub-tree X and not being provided access to read, white, and review nodes outside of sub-tree X correlates to the collaborator controller not authorized to update any other field of the resource field tree),
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Di Girolamo with a method for generating and using a layering resource representation of resource in a container orchestration platform as taught by Sadhani because application discovery controllers can be deployed on Kubernetes clusters to perform automatic discovery of resources of an application. Additionally, they may watch over resources changes to discover all resources constituting the application workloads and build resource hierarchies to represent the application workloads along with auto-generation of the backup configuration needed to comprehensively backup the application (Sadhani: paragraph 30).
Additionally, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Di Girolamo with wherein each collaborator controller is not authorized to update any other field of the resource field tree as taught by Lukanov because access controls can be propagated to apply to child resources of a first root entity. This allows permissions provided to a root node of a sub-tree to be propagated to all child nodes in the sub-tree. Defining containers and container memberships for respective sets of resources within a resource directory maintains separation between access rights of different principals to dedicated sets of the resources (Lukanov: paragraphs 25-26).
With regards to Claims 14 and 19, the method of Claim 1 performs the same steps as the machines of Claims 14 and 19 respectively, and Claims 14 and 19 are therefore rejected using the same rationale set forth above in the rejection of Claim 1.
With regards to Claim 13, Di Girolamo in view of Lukanov and Sadhani teach the method of Claim 1 above. Sadhani further teaches:
wherein the container orchestration platform comprises a Kubernetes platform (Paragraph 64, “In some implementations, the container orchestration platform comprises a Kubernetes system, and the resources of the application comprises the pod and other Kubernetes resources of the application, wherein the other Kubernetes resources comprise one or more of a persistent volume, a custom resource definition, a custom resource, a service account, etc.” The container orchestration platform comprising a Kubernetes system correlates to the container orchestration platform comprising a Kubernetes platform).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Di Girolamo with wherein the container orchestration platform comprises a Kubernetes platform as taught by Sadhani because Kubernetes systems allow the resources of the application to comprise Kubernetes resources which can use persistent volume, custom resource definitions, custom resources, and service accounts (Sadhani: paragraph 64).
With regards to Claim 18, the method of Claim 13 performs the same steps as the machine of Claim 18, and Claim 18 is therefore rejected using the same rationale set forth above in the rejection of Claim 13.
Claim(s) 2-3, 5, 7, 10, 15-17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Di Girolamo in view of Lukanov, Sadhani and Gupta et al. (U.S. Patent No. US 20230205757 A1), hereinafter “Gupta.”
With regards to Claim 2, Di Girolamo in view of Lukanov and Sadhani teach the method of Claim 1 above. Di Girolamo further teaches:
wherein the one or more overlay layers consist of N overlay layers, wherein N is at least 1 (Paragraph 106, “An Overlay Resource Tree (ORT) may act as an “overlay” to a Physical Resource Tree (PRT)… A server with a PRT may host zero or more ORTs.” The server with a physical resource tree hosting zero or more ORTs can include 1 or more ORTs and therefore correlates to wherein the one or more overlay layers consist of N overlay layers, wherein N is at least 1),
Di Girolamo does not explicitly teach:
and wherein the method further comprises: storing, by the one or more processors, the layering resource representation of the resource in a key-value database denoted as an etcd database, said storing the layering resource representation of the resource comprising:
generating a base layer resource key that maps to the owner controller and is unique to the base layer;
storing the base layer into the etcd database, using the base layer resource key;
generating, for overlay layer n of N overlay layers, an overlay layer resource key (Kn) that maps to the collaborator controller of overlay layer n and is unique to overlay layer n (n = 1, 2, ..., N);
storing overlay layer n in the etcd database using the overlay layer resource key (Kn) (n = 1, 2, ..., N).
However, Gupta teaches:
and wherein the method further comprises: storing, by the one or more processors, the layering resource representation of the resource in a key-value database denoted as an etcd database (Paragraphs 22, 32, 41, 57-58, “In some examples, version control interface 110 overlays multiple data lakes 120 (e.g., data lake 120 and data lake 102a) … The tree data structure 210 may be stored in the data lake or in a separate storage system. That is, the objects that comprise the overlayed metadata objects do not need to be stored in the same storage system as the data itself. For example, the tree data structure 210 may be stored in a relational database or key-value store… Examples of a key-value store include ETCD (which is an open source, distributed, consistent key-value store for shared configuration, service discovery, and scheduler coordination of distributed systems or clusters of machines), or other implementations using algorithms such as PAXOS, Raft and more… Flowchart 700 commences with operation 702, which includes generating master branch 200 for data objects (e.g., objects 121-127) stored in data lake 120. Master branch 200 comprises tree data structure 210 having a plurality of leaf nodes (e.g., references 2111-2133) referencing the data objects… For each writer of a plurality of writers 130 (e.g., writers 134 and 136), operation 704 creates a private branch (e.g., private branches 400a and 400b) from a first version of master branch 200. Each private branch may be written to by its corresponding writer, but may be protected against writing by a writer different than its corresponding writer.” The master branch comprising a tree structure referencing the data objects in the multiple data lake and private branches being created from the first version of the master branch correlates to the layering resource representation of the resource. The tree data structure being stored in a ETCD key-value store correlates to storing the layering resource representation of the resource in a key-value database denoted as an ETCD database), said storing the layering resource representation of the resource comprising:
generating a base layer resource key that is unique to the base layer (Paragraph 40, “To facilitate this, a key-value store 150 has a key-value entry for each master branch, as well as key-value entries for private branches. The key-value entries are used for addressing the root nodes of branches. For example, a key-value pair 152 points to a first version of master branch 200 (or master branch snapshot 202a).” The key-value store having a key-value entry for each master branch correlates to generating a base layer resource key that is unique to the base layer);
storing the base layer into the etcd database, using the base layer resource key (Paragraphs 32 and 41, “The tree data structure 210 may be stored in the data lake or in a separate storage system. That is, the objects that comprise the overlayed metadata objects do not need to be stored in the same storage system as the data itself. For example, the tree data structure 210 may be stored in a relational database or key-value store… Examples of a key-value store include ETCD (which is an open source, distributed, consistent key-value store for shared configuration, service discovery, and scheduler coordination of distributed systems or clusters of machines), or other implementations using algorithms such as PAXOS, Raft and more.” The tree data structure being stored in a key-value store such as an ETCD key-value store correlates to storing the base layer into the etcd database using the base layer resource key);
generating, for overlay layer n of N overlay layers, an overlay layer resource key (Kn) that maps to the collaborator controller of overlay layer n and is unique to overlay layer n (n = 1, 2, ..., N) (Paragraphs 40 and 58, “To facilitate this, a key-value store 150 has a key-value entry for each master branch, as well as key-value entries for private branches. The key-value entries are used for addressing the root nodes of branches… For each writer of a plurality of writers 130 (e.g., writers 134 and 136), operation 704 creates a private branch (e.g., private branches 400a and 400b) from a first version of master branch 200. Each private branch may be written to by its corresponding writer, but may be protected against writing by a writer different than its corresponding writer.” The plurality of writers each having a private branch created from the master branch with a key-value entry correlates to generating an overlay layer resource key for the overlay layer n of N overlay layers. The private branches being protected against writes outside of its corresponding writer correlates to the overlay layer resource key mapping to the collaborator controller. The key-value store having a key-value entry for each private branch correlates to the overlay layer resource key being unique to an overlay layer n);
storing overlay layer n in the etcd database using the overlay layer resource key (Kn) (n = 1, 2, ..., N) (Paragraphs 32, 40-41, 57 and 59, “The tree data structure 210 may be stored in the data lake or in a separate storage system. That is, the objects that comprise the overlayed metadata objects do not need to be stored in the same storage system as the data itself. For example, the tree data structure 210 may be stored in a relational database or key-value store… To facilitate this, a key-value store 150 has a key-value entry for each master branch, as well as key-value entries for private branches… Examples of a key-value store include ETCD (which is an open source, distributed, consistent key-value store for shared configuration, service discovery, and scheduler coordination of distributed systems or clusters of machines) … Master branch 200 comprises tree data structure 210 having a plurality of leaf nodes (e.g., references 2111-2133) referencing the data objects... Creating a private branch is performed using operations 706 and 708, which may be performed in response to an API call. Operation 706 includes copying a root node of tree data structure 210 of master branch 200.” The master branch comprises the tree data structure which is stored in an ETCD key-value store. The private branches copying the tree data structure and being stored in the key-value store therefore correlates to storing the overlay layer into the etcd database using the overlay layer resource key).
Gupta does not explicitly teach that the base layer resource key maps to the owner controller. However, base layer resource keys mapping to the owner controller are a popular type of role management with resources as evidenced by Lukanov (Paragraph 29, 32, and 42, “The RBAC model may provide the administrator role with permissions to perform a certain operation on a resource, e.g., delete a resource. However, based on defining access rights according to the RBAC-based model and further filtered based on the definition of containers and container membership mapping tenants to containers, an administrator of user group B is not provided with rights to delete a resource that is outside of the second container. In particular, an administrator of user group B may not be allowed to delete a root node of the resource directory tree, however, an administrator of user group A could be allowed to delete that root node of the resource directory… In some implementations, the data center maps different designated groups to distinguish between users of different tenants, accounts, user roles, user group, or other criteria for differentiation between users that are provided with access to different portions of the resources of the resource directory… For example, the resource managing service 125 can receive the local token of the requesting user X 105 and can parse the token to read claims defined in the token to determine a container membership of the user X 105 for accessing resources at the directory 155.” The RBAC model defining access rights mapping tenants to resources, where an administrator of group A would be allowed to modify a root node of the resource directory tree, using a container membership defined in a token correlates to the base layer resource key mapping to the owner controller).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Di Girolamo with and wherein the method further comprises: storing, by the one or more processors, the layering resource representation of the resource in a key-value database denoted as an etcd database, said storing the layering resource representation of the resource comprising: generating a base layer resource key that maps to the owner controller and is unique to the base layer; storing the base layer into the etcd database, using the base layer resource key; generating, for overlay layer n of N overlay layers, an overlay layer resource key (Kn) that maps to the collaborator controller of overlay layer n and is unique to overlay layer n (n = 1, 2, ..., N); storing overlay layer n in the etcd database using the overlay layer resource key (Kn) (n = 1, 2, ..., N) as taught by Gupta because key-value stores use key value tagging to facilitate coordination between storing, retrieving, and managing associative arrays. Data records can be stored and retrieved using a unique key which can further include attributes of data associated with the key. ETCD databases also provide a distributed, consistent key-value store for shared configuration, service discovery, and scheduler coordination of distributed systems or clusters (Gupta: paragraph 41).
Additionally, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Di Girolamo with wherein each collaborator controller is not authorized to update any other field of the resource field tree as taught by Lukanov because access controls can be propagated to apply to child resources of a first root entity. This allows permissions provided to a root node of a sub-tree to be propagated to all child nodes in the sub-tree. Defining containers and container memberships for respective sets of resources within a resource directory maintains separation between access rights of different principals to dedicated sets of the resources. Additionally, token authentication can be used by the resource management service to determine that a user is authorized to perform operations before providing the user with access control rights for a particular resource (Lukanov: paragraphs 25-26 and 43).
With regards to Claims 15 and 20, the method of Claim 2 performs the same steps as the machines of Claims 15 and 20 respectively, and Claims 15 and 20 are therefore rejected using the same rationale set forth above in the rejection of Claim 2.
With regards to Claim 3, Di Girolamo in view of Lukanov, Sadhani and Gupta teach the method of Claim 2 above. Gupta further teaches:
wherein said storing the base layer into the etcd database is initiated by a Application Programming Interface (API) call (Paragraphs 32 and 41, “The tree data structure 210 may be stored in the data lake or in a separate storage system. That is, the objects that comprise the overlayed metadata objects do not need to be stored in the same storage system as the data itself. For example, the tree data structure 210 may be stored in a relational database or key-value store… Examples of a key-value store include ETCD (which is an open source, distributed, consistent key-value store for shared configuration, service discovery, and scheduler coordination of distributed systems or clusters of machines), or other implementations using algorithms such as PAXOS, Raft and more.” The tree data structure being stored in a key-value store such as an ETCD key-value store would require an ETCD API call and therefore correlates to storing the base layer into the etcd database by initiating an API call),
and wherein said storing the base layer into the etcd database comprises: obtaining permission, to create the resource (Paragraph 38, “New master branches are created upon merging data from a private branch. A private branch is merged with the master branch when it contains data of committed transactions (e.g., a private branch cannot be merged with the master, if it contains data of an uncommitted transaction). There may be different policies used for merging private branches to the master branch… Other merge policies may also be implemented depending on the type of a transaction or the specification of a user. Also, merging may be performed in response to an explicit merge request by a client.” The client requesting a merge of their private branch to create a new master branch correlates to obtaining permission to create the resource);
saving the resource in the etcd database as the base layer using the base layer resource key (Paragraphs 32 and 41, “The tree data structure 210 may be stored in the data lake or in a separate storage system. That is, the objects that comprise the overlayed metadata objects do not need to be stored in the same storage system as the data itself. For example, the tree data structure 210 may be stored in a relational database or key-value store… Examples of a key-value store include ETCD (which is an open source, distributed, consistent key-value store for shared configuration, service discovery, and scheduler coordination of distributed systems or clusters of machines), or other implementations using algorithms such as PAXOS, Raft and more.” The tree data structure being stored in a key-value store such as an ETCD key-value store correlates to saving the resource in the etcd database using the base layer resource key).
Gupta does not explicitly teach that the permission [is obtained] from Role-Based Access Control (RBAC), however, obtaining permission from Role-Based Access Control (RBAC) is a popular method of authentication as evidenced by below Lukanov (Paragraph 34, “The authorization server 135 can support access control restrictions based on an RBAC-based model 170. The RBAC-based model 170 can define different authorization schemes for different target groups of users to provide the users with access to at least part of the resources provided by the data center 120. The authorization server 135 can define authorization schemes 170 correspondingly for the different container memberships defined in the data center 120.” The RBAC model being used to define authorization schemes for different container memberships and target groups of users correlates to obtaining permission from RBAC).
Lukanov further teaches:
obtaining an identification of a user Service Account from an API token included in the API call (Paragraph 43, “For example, the user X 105 can request the access through a client application 110 (e.g., a browser). The user X 105 can authenticate at the client 110. The resource management service 125 can determine that the user X 105 is authorized to perform operations and can provide the user X 105 with access control rights at the resource managing services based on a token authentication.” The user requesting access through a client application based on a token authentication to authenticate the user correlates to obtaining an identification of a user Service Account from an API token included in the API call);
determining, from RBAC, that the resource can be stored by the user Service Account (Paragraphs 34, 42, “The authorization server 135 can support access control restrictions based on an RBAC-based model 170. The RBAC-based model 170 can define different authorization schemes for different target groups of users to provide the users with access to at least part of the resources provided by the data center 120. The authorization server 135 can define authorization schemes 170 correspondingly for the different container memberships defined in the data center 120… For example, the container membership may identify that the requested container for configuration is associated with users originating from domain “XYZ.” In response to obtaining the container membership information from the mappings 145, the container configuration interface 150 can store the defined container for the directory 155 by persisting such configuration information at the database 152.” The authorization server managing access control restrictions using authorization schemes for container memberships based on a RBAC model, which can be used for storing a container in the database, correlates to determining, from RBAC, that the resource can be stored by the user Service Account);
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Di Girolamo with wherein said storing the base layer into the etcd database is initiated by a Application Programming Interface (API) call, and wherein said storing the base layer into the etcd database comprises: obtaining permission to create the resource; saving the resource in the etcd database as the base layer using the base layer resource key as taught by Gupta because key-value stores use key value tagging to facilitate coordination between storing, retrieving, and managing associative arrays. Data records can be stored and retrieved using a unique key which can further include attributes of data associated with the key. ETCD databases also provide a distributed, consistent key-value store for shared configuration, service discovery, and scheduler coordination of distributed systems or clusters (Gupta: paragraph 41).
Additionally, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Di Girolamo with obtaining an identification of a user Service Account from an API token included in the API call; determining, from RBAC, that the resource can be stored by the user Service Account as taught by Lukanov because defining containers and container memberships for respective sets of resources within a resource directory through a RBAC-based model maintains separation between access rights of different principals to dedicated sets of the resources. RBAC models can also allow access to resources in a resource directory by filtering permissions propagated based on an authentication scheme mapping to different container policies. Additionally, token authentication can be used by the resource management service to determine that a user is authorized to perform operations before providing the user with access control rights for a particular resource (Lukanov: paragraphs 26 and 43).
With regards to Claim 16, the method of Claim 3 performs the same steps as the machine of Claim 16, and Claim 16 is therefore rejected using the same rationale set forth above in the rejection of Claim 3.
With regards to Claim 5, Di Girolamo in view of Lukanov, Sadhani and Gupta teach the method of Claim 2 above. Di Girolamo further teaches:
obtaining permission, to create the resource (Paragraphs 182-183, “At step 6, the ORT Producer may send a CreateOverlayRequest to the ORT Host. Such a request may comprise the overlay attributes from Step 3, above… At step 7, the ORT Host may create an <overlay> resource. If ORTs are supported, the ORT Host may proceed with the overlay creation.” The ORT producer sending a CreateOverlayRequest to the ORT host, which can be approved if ORTs are supported, correlates to obtaining permission to create the resource);
extracting a sub-tree of overlay layer n from a JavaScript Object Notation (JSON) path (Table 4, Paragraph 121 and 184-185, “staticOverlayTemplate: This may denote the structure of the resource tree for the ORT. The structure may be a representation of the resource tree and may include the root and all branching points stemming from this root. For example, this attribute may be in the form of a list that defines the root resource of the ORT, each of the branching points of the ORT, and the direct child resources of each branching point… Alternatively, the staticOverlayTemplate attribute may be represented in other formats, such as for example, a JSON format, which may include all attributes and child resources of each resource… At step 8, the ORT Host may determine if branching points needed for the overlay are available in the PRT. For example, the ORT Host may check the staticOverlayTemplate attribute or the associated <dynamicOverlayTemplate>… At step 9, the ORT Host may create the requested overlay. This generation may be performed immediately, or the ORT Host may wait for a scheduled activation time, as determined by an optional overlaySchedule attribute. While generating the overlay, the ORT Host may check for “resource consistency”… In addition, each resource may have one or more attributes that denote whether this resource may be included in ORTs. For example, a resource may have a new overlayEligible attribute. Such a resource may only be included in an ORT if overlayEligible==TRUE.” The staticOverlayTemplate being represented as a JSON format and denoting the structure of the ORT correlates to a JavaScript Object Notation (JSON) path. The ORT host creating the requested overlay using the staticOverlayTemplate and only resources with overlayEligible attributes may result in a sub-tree of the ORT and therefore correlates to extracting a sub-tree of overlay layer n from a JavaScript Object Notation (JSON) path);
Di Girolamo does not explicitly teach that the permission [is obtained] from Role-Based Access Control (RBAC), and that the path [is] defined in RBAC rules. However, obtaining permission from Role-Based Access Control (RBAC) is a popular method of authentication as evidenced by Lukanov above. Additionally, paths are a popular type of access permission managed by RBAC as evidenced by Lukanov (Paragraph 25, “In some implementations, a cloud data center manages access controls according to an authorization model based on the RBAC model. In case where the RBAC model is used for the access control for entities part of a resource directory, determined permissions for one entity (e.g., resource, file) are propagated to apply to child resources to that first root entity. Thus, permissions provided to a root node of a sub-tree of the resource directory are propagated to all child nodes in the sub-tree. In some instances, different sub-trees may be associated with different tenants, or user groups, or other criteria for determining relevant principals provided with access to resources part of relevant subtrees.” The authorization model being based on an RBAC model which controls and propagates access for sub-trees based on the root and child nodes would be based on the path of the nodes and therefore correlates to paths being defined in RBAC rules).
Gupta further teaches:
wherein said storing overlay layer n (n = 1, 2, ..., N) in the etcd database is initiated by a Application Programming Interface (API) call (Paragraphs 32 and 41 and 59, “The tree data structure 210 may be stored in the data lake or in a separate storage system. That is, the objects that comprise the overlayed metadata objects do not need to be stored in the same storage system as the data itself. For example, the tree data structure 210 may be stored in a relational database or key-value store… Examples of a key-value store include ETCD (which is an open source, distributed, consistent key-value store for shared configuration, service discovery, and scheduler coordination of distributed systems or clusters of machines), or other implementations using algorithms such as PAXOS, Raft and more… Creating a private branch is performed using operations 706 and 708, which may be performed in response to an API call. Operation 706 includes copying a root node of tree data structure 210 of master branch 200.” The private branch making a copy of the root node of the tree data structure as an API call, which is stored in a key-value store such as an ETCD key-value store, correlates to storing the overlay layer into the etcd database by initiating an API call),
and wherein said storing overlay layer into the etcd database comprises:
constructing the overlay layer resource key (Kn) for overlay layer n, using the JSON path (Paragraphs 31, 40, “Node 212, which is associated with an identifier ID212, has reference 2121, reference 2122, and reference 2123 (e.g., addresses in data lake 120) to data object 124, data object 125, and data object 126, respectively… In some examples, each node holds a component of the name space path starting from the table name (see FIG. 3). Nodes are uniquely identifiable by their hash value (e.g., identifiers ID201-ID213) … To facilitate this, a key-value store 150 has a key-value entry for each master branch, as well as key-value entries for private branches. The key-value entries are used for addressing the root nodes of branches… In operation, key-value store 150 maps versions or snapshot heads to the node ID needed to traverse that version once it was committed and flushed.” The key-value store having a key-value entry for each private branch which maps to the node ID needed to traverse the version correlates to constructing the overlay layer resource key for overlay layer n. The node ID holding a component of the name space path correlates to constructing the overlay layer resource key using the JSON path);
saving the resource sub-tree in the etcd database as overlay layer n, using the overlay layer resource key (Kn) (Paragraphs 32 and 40-41, “The tree data structure 210 may be stored in the data lake or in a separate storage system. That is, the objects that comprise the overlayed metadata objects do not need to be stored in the same storage system as the data itself. For example, the tree data structure 210 may be stored in a relational database or key-value store… To facilitate this, a key-value store 150 has a key-value entry for each master branch, as well as key-value entries for private branches. The key-value entries are used for addressing the root nodes of branches… Examples of a key-value store include ETCD (which is an open source, distributed, consistent key-value store for shared configuration, service discovery, and scheduler coordination of distributed systems or clusters of machines), or other implementations using algorithms such as PAXOS, Raft and more.” The private branch being stored in a key-value store such as an ETCD key-value store correlates to saving the resource sub-tree in the etcd database as overlay layer n, using the overlay layer resource key).
Gupta does not explicitly teach that the path [is] defined in RBAC rules. However, paths are a popular type of access permission managed by RBAC as evidenced by Lukanov above (Paragraph 25).
Lukanov further teaches:
obtaining an identification of a user Service Account from an API token included in the API call (Paragraph 43, “For example, the user X 105 can request the access through a client application 110 (e.g., a browser). The user X 105 can authenticate at the client 110. The resource management service 125 can determine that the user X 105 is authorized to perform operations and can provide the user X 105 with access control rights at the resource managing services based on a token authentication.” The user requesting access through a client application based on a token authentication to authenticate the user correlates to obtaining an identification of a user Service Account from an API token included in the API call);
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Di Girolamo with wherein said storing overlay layer n (n = 1, 2, ..., N) in the etcd database is initiated by a Application Programming Interface (API) call, and wherein said storing overlay layer n into the etcd database comprises: constructing the overlay layer resource key (Kn) for overlay layer n, using the JSON path defined in RBAC rules; saving the resource sub-tree in the etcd database as overlay layer n, using the overlay layer resource key (Kn) as taught by Gupta because key-value stores use key value tagging to facilitate coordination between storing, retrieving, and managing associative arrays. Data records can be stored and retrieved using a unique key which can further include attributes of data associated with the key. ETCD databases also provide a distributed, consistent key-value store for shared configuration, service discovery, and scheduler coordination of distributed systems or clusters (Gupta: paragraph 41).
Additionally, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Di Girolamo with obtaining an identification of a user Service Account from an API token included in the API call and obtaining permission, from Role-Based Access Control (RBAC) as taught by Lukanov because defining containers and container memberships for respective sets of resources within a resource directory through a RBAC-based model maintains separation between access rights of different principals to dedicated sets of the resources. RBAC models can also allow access to resources in a resource directory by filtering permissions propagated based on an authentication scheme mapping to different container policies. Additionally, token authentication can be used by the resource management service to determine that a user is authorized to perform operations before providing the user with access control rights for a particular resource (Lukanov: paragraphs 26 and 43).
With regards to Claim 17, the method of Claim 5 performs the same steps as the machine of Claim 17, and Claim 17 is therefore rejected using the same rationale set forth above in the rejection of Claim 5.
With regards to Claim 7, Di Girolamo in view of Lukanov, Sadhani and Gupta teach the method of Claim 2 above. Gupta further teaches:
reading, by a user Service Account, using the one or more processors, the resource from the etcd database, said reading the resource being initiated by an Application Programming Interface (API) call (Paragraphs 41-42, “The key-value store may be any discovery service. Examples of a key-value store include ETCD (which is an open source, distributed, consistent key-value store for shared configuration, service discovery, and scheduler coordination of distributed systems or clusters of machines), or other implementations using algorithms such as PAXOS, Raft and more… In some examples, to achieve global consistency for multi-table transactions, read requests from readers 140 are routed through key-value store 150, which tags them by default with the current key-value pair for master branch 200 (or the most recent master branch snapshot).” Read requests from readers being routed through the key-store such as an ETCD key-store involves an API call and therefore correlates to reading, by a user Service Account, using the one or more processors, the resource from the etcd database, said reading the resource being initiated by an Application Programming Interface (API) call) and comprising:
accessing the base layer from the etcd database using the base layer resource key (Paragraph 43, “Readers 140 are illustrated as including a reader 142, a reader 144, a reader 146, and a reader 148. Readers 142 and 144 are both reading from the most recent master branch, whereas readers 146 and 148 are reading from a prior master branch. For example, if the current master branch is the third version of master branch 200 corresponding to master branch snapshot 202c (pointed to by key-value pair 156), readers 142 and 144 use key-value pair 156 to read from data lake 120 using the third version of master branch 200 or master branch snapshot 202c.” The reader reading from the most recent master branch using key-value pairs associated with a specific version of the master branch correlates to accessing the base layer from the etcd database using the base layer resource key);
for n=1,2, ..., N: accessing overlay layer n from the etcd database using the overlay layer resource key (Kn) (Paragraphs 40, 48, “To facilitate this, a key-value store 150 has a key-value entry for each master branch, as well as key-value entries for private branches. The key-value entries are used for addressing the root nodes of branches… FIG. 5 illustrates a scenario 500 involving concurrent writing to private branches 400a and 400b by a plurality of writers (e.g., writers 134 and 136) … Writer 134, operated by a user 501, writes data object 128, thereby updating private branch 400a… Writer 136, for example operated by a user 502, writes data object 129, thereby updating private branch 400b. Writers 134 and 136 use WAL 138 for crash resistance. For example, when writers 134 and 136 check out private branches 400a and 400b from master branch 200 (by copying from snapshot 202a), objects 128 and 129 may be added by first writing to WAL 138 and then reading from WAL 138 to add objects 128 and 129 to private branches 400a and 400b, respectively.” The key-value entries being used to address the root nodes of private branches, where objects are first written to and then read from WAL, correlates to accessing overlay layer n from the etcd database using the overlay layer resource key (Kn));
merging overlay layer n with the base layer, including overriding values of sub- fields in the base layer by respective sub-field values in overlay layer n (Paragraph 52, “FIGS. 6A and 6B illustrate sequentially merging private branches 400a and 400b back into master branch 200. This is illustrated as merging private branch 400a into master branch 200, to produce a new version of master branch 200 (FIG. 6A) and then merging private branch 400b into master branch 200, to produce another new version of master branch 200 (FIG. 6B). When merging private branches, modified nodes of master branch 200 are re-written. The other nodes are overlaid from the previous version of master branch 200.” The merging of private branches back into the master branch where modified nodes of the master branch are re-written correlates to merging overlay layer n with the base layer, including overriding values of sub- fields in the base layer by respective sub-field values in overlay layer n).
Lukanov further teaches:
obtaining an identification of a user Service Account from an API token included in the API call (Paragraph 43, “For example, the user X 105 can request the access through a client application 110 (e.g., a browser). The user X 105 can authenticate at the client 110. The resource management service 125 can determine that the user X 105 is authorized to perform operations and can provide the user X 105 with access control rights at the resource managing services based on a token authentication.” The user requesting access through a client application based on a token authentication to authenticate the user correlates to obtaining an identification of a user Service Account from an API token included in the API call);
obtaining permission, from Role-Based Access Control (RBAC), to access the resource (Paragraphs 34, 42, “The authorization server 135 can support access control restrictions based on an RBAC-based model 170. The RBAC-based model 170 can define different authorization schemes for different target groups of users to provide the users with access to at least part of the resources provided by the data center 120. The authorization server 135 can define authorization schemes 170 correspondingly for the different container memberships defined in the data center 120… In some implementations, a user X 105 requests to access resources at directory 155 that are provided by the resource managing service 125. For example, the user X 105 can request the access through a client application 110 (e.g., a browser). The user X 105 can authenticate at the client 110… The authorization server 135 can determine the relevant container membership authorization scheme from the authorization schemes 170. Based on read information (e.g., claims written in the token) from the token of the user X 105, the resource management service 125 can determine which containers from the defined containers for directory 155 are associated (or available) for the user X 105.” The authorization server determining and managing access control restrictions using authorization schemes for container memberships based on a RBAC model in response to a user’s access request correlates to obtaining permission, from Role-Based Access Control (RBAC), to access the resource);
determining, from RBAC, that the resource can be accessed by the user Service Account (Paragraphs 34, 42, “The authorization server 135 can support access control restrictions based on an RBAC-based model 170. The RBAC-based model 170 can define different authorization schemes for different target groups of users to provide the users with access to at least part of the resources provided by the data center 120. The authorization server 135 can define authorization schemes 170 correspondingly for the different container memberships defined in the data center 120… In some implementations, a user X 105 requests to access resources at directory 155 that are provided by the resource managing service 125. For example, the user X 105 can request the access through a client application 110 (e.g., a browser). The user X 105 can authenticate at the client 110… The authorization server 135 can determine the relevant container membership authorization scheme from the authorization schemes 170. Based on read information (e.g., claims written in the token) from the token of the user X 105, the resource management service 125 can determine which containers from the defined containers for directory 155 are associated (or available) for the user X 105.” The resource management service determining which containers from the directory are available for the user X based on authorization schemes for container memberships and a RBAC model correlates to determining, from RBAC, that the resource can be accessed by the user Service Account);
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Di Girolamo with reading, by a user Service Account, using the one or more processors, the resource from the etcd database, said reading the resource being initiated by an Application Programming Interface (API) call and comprising: accessing the base layer from the etcd database using the base layer resource key; for n=1,2, ..., N:accessing overlay layer n from the etcd database using the overlay layer resource key (Kn); merging overlay layer n with the base layer, including overriding values of sub- fields in the base layer by respective sub-field values in overlay layer n as taught by Gupta because key-value stores use key value tagging to facilitate coordination between storing, retrieving, and managing associative arrays. Data records can be stored and retrieved using a unique key which can further include attributes of data associated with the key. ETCD databases also provide a distributed, consistent key-value store for shared configuration, service discovery, and scheduler coordination of distributed systems or clusters. Writers leveraging a write ahead log for writing and reading increases crash resistance, and combined with persistence properties of the data lake storage, assists with the durability aspects of ACID (Gupta: paragraphs 25, 41 and 48).
Additionally, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Di Girolamo with obtaining an identification of the user Service Account from an API token included in the API call; obtaining permission, from Role-Based Access Control (RBAC), to access the resource; determining, from RBAC, that the resource can be accessed by the user Service Account as taught by Lukanov because defining containers and container memberships for respective sets of resources within a resource directory through a RBAC-based model maintains separation between access rights of different principals to dedicated sets of the resources. RBAC models can also allow access to resources in a resource directory by filtering permissions propagated based on an authentication scheme mapping to different container policies. Additionally, token authentication can be used by the resource management service to determine that a user is authorized to perform operations before providing the user with access control rights for a particular resource (Lukanov: paragraphs 26 and 43).
With regards to Claim 10, Di Girolamo in view of Lukanov, Sadhani and Gupta teach the method of Claim 2 above. Di Girolamo further teaches:
wherein the one or more overlay layers consist of two or more overlay layers (Paragraph 106, “An ORT may be formed by selecting a subset of resources in a PRT and establishing parent-child relationships between those selected resources. An ORT may comprise a root resource and a number of descendent child resources. A server with a PRT may host zero or more ORTs.” The server hosting zero or more ORTs can include two or more ORTs and therefore correlates to the one or more overlay layers consisting of two or more overlay layers),
Lukanov further teaches:
and wherein the two or more overlay layers are mutually exclusive with respect to the fields in the two or more overlay layers (Paragraphs 25, 33 and 55, “In some instances, different sub-trees may be associated with different tenants, or user groups, or other criteria for determining relevant principals provided with access to resources part of relevant subtrees… In some cases, the sub-trees can be separate structure that do not overlap… The inventory 210 includes seven containers defined to restrict access rights to different subset of the resources to different target groups. The containers can be defined as nested sets. For example, container T0 includes containers T1, T5, and T6, while container T1 includes containers T2, T3, and T4. One container can be configured to map to different container memberships.” The inventory including seven containers associated with different subsets of resources correlates to two or more overlay layers. The sub-trees being separate structures that do not overlap correlates to the two or more overlay layers are mutually exclusive with respect to the fields in the two or more overlay layers).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Di Girolamo with and wherein the two or more overlay layers are mutually exclusive with respect to the fields in the two or more overlay layers as taught by Lukanov because defining containers and container memberships for respective sets of resources within a resource directory through a RBAC-based model maintains separation between access rights of different principals to dedicated sets of the resources. Multiple containers can be defined to restrict access rights to different subsets of resources for different target groups (Lukanov: paragraphs 26 and 55).
Claim(s) 4 and 6 are rejected under 35 U.S.C. 103 as being unpatentable over Di Girolamo in view of Lukanov, Sadhani, Gupta and Kumar et al. (U.S. Patent No. US 20250023714 A1), hereinafter “Kumar.”
With regards to Claim 4, Di Girolamo in view of Lukanov, Sadhani and Gupta teach the method of Claim 3 above. Di Girolamo in view of Lukanov, Sadhani and Gupta do not explicitly teach:
after said determining that the resource can be stored by the user Service Account and before said saving the resource in the etcd database as the base layer:
obtaining a field manager for the resource from resource metadata;
determining either that the field manager exists in the API call and that the field manager in the API call equals the user Service Account or that the field manager does not exist in the API call.
However, Kumar teaches:
wherein the method further comprises after said determining that the resource can be stored by the user Service Account and before said saving the resource in the database:
obtaining a field manager for the resource from resource metadata (Paragraphs 452-453, “For authenticated users to perform key operations directly from the KDS portal (317) the users must be members of the designated role-based user group (for example, in the identity provider's authentication directory service) ... After verification, the broker 144 at step 144c creates a signing key for co-signing and extends the signature manifest. At step 144b, the content loader assigns a content identifier (UUID), content timestamp, content version, content type, and content description from the KDS portal (317). The key creation at step 144c for content file signing and generation of the extended signature manifest file may be accomplished with utilities, executing on an authenticated device, that use the KDS interface (167) APIs or through the KDS Portal (317) by authenticated users… Finally, the last approver in the chain notifies the policy manager to configure an update policy to associate the content file to qualified consumers (devices) 145 managed by field managers). At step 144e, the policy manager notifies the field manager to publish the content to the devices 145… The users at the broker 144 are content loaders, content approvers, policy managers, and field managers.” The last approver notifying the policy manager to associate the content file to qualified consumers managed by particular field managers, who are members of the same role-based group identifier found in the signature manifest file, would involve obtaining information on the particular field managers and therefore correlates to obtaining a field manager for the resource from resource metadata. The device first being authenticated and the approvers verifying the content file before the field manager publishes the content correlates to the step occurring after said determining that the resource can be stored by the user Service Account and before said saving the resource in the database);
determining either that the field manager exists in the API call and that the field manager in the API call equals the user Service Account or that the field manager does not exist in the API call (Paragraphs 452-453, “For authenticated users to perform key operations directly from the KDS portal (317) the users must be members of the designated role-based user group (for example, in the identity provider's authentication directory service) ... At step 144b the broker 144 receives and verifies the content file using the signature manifest file, and at step 144c retrieves the key from the KDS 195 using the key identity hint in the signature manifest for the associated content file. After verification, the broker 144 at step 144c creates a signing key for co-signing and extends the signature manifest. At step 144b, the content loader assigns a content identifier (UUID), content timestamp, content version, content type, and content description from the KDS portal (317). The key creation at step 144c for content file signing and generation of the extended signature manifest file may be accomplished with utilities, executing on an authenticated device, that use the KDS interface (167) APIs or through the KDS Portal (317) by authenticated users… Finally, the last approver in the chain notifies the policy manager to configure an update policy to associate the content file to qualified consumers (devices) 145 managed by field managers). At step 144e, the policy manager notifies the field manager to publish the content to the devices 145… The users at the broker 144 are content loaders, content approvers, policy managers, and field managers.” The authenticated user performing key operations, where the user can be a field manager, correlates to an API call. The key identity hint in the signature manifest being used to retrieve the key for content file signing correlates to determining that the field manager exists in the API call, and in the case where the user is a field manager, additionally correlates to the field manager in the API call being equal the user Service Account. The device first being authenticated and the approvers verifying the content file before the field manager publishes the content correlates to the step occurring after said determining that the resource can be stored by the user Service Account and before said saving the resource in the database).
Kumar does not explicitly teach that the resource [is saved] in the etcd database as the base layer. However, saving the resource in etcd databases as the base layer is a popular technique for storing resource trees as evidenced by Gupta above (Paragraphs 32 and 41, “The tree data structure 210 may be stored in the data lake or in a separate storage system. That is, the objects that comprise the overlayed metadata objects do not need to be stored in the same storage system as the data itself. For example, the tree data structure 210 may be stored in a relational database or key-value store… Examples of a key-value store include ETCD (which is an open source, distributed, consistent key-value store for shared configuration, service discovery, and scheduler coordination of distributed systems or clusters of machines), or other implementations using algorithms such as PAXOS, Raft and more.” The tree data structure being stored in a key-value store such as an ETCD key-value store correlates to storing the base layer into the etcd database).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Di Girolamo with saving the resource in etcd databases as the base layer as taught by Gupta because key-value stores use key value tagging to facilitate coordination between storing, retrieving, and managing associative arrays. Data records can be stored and retrieved using a unique key which can further include attributes of data associated with the key. ETCD databases also provide a distributed, consistent key-value store for shared configuration, service discovery, and scheduler coordination of distributed systems or clusters (Gupta: paragraph 41).
Additionally, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Di Girolamo with after said determining that the resource can be stored by the user Service Account and before said saving the resource in the database: obtaining a field manager for the resource from resource metadata; determining either that the field manager exists in the API call and that the field manager in the API call equals the user Service Account or that the field manager does not exist in the API call as taught by Kumar because managed content distribution workflows allow content creators to generate content files and have the content and signature manifest files approved by multiple content approvers through various content inspection methods. Additional content approvers may use multiple different methods such as static analysis, dynamic analysis, sandboxing, anomaly detection, reputation lists based on the approver's security profile and threat model assessments. After all approvers in a chain have approved the content, the content is finally updated to associate the file with update policies, device types, and device group. This ensures that the field manager publishes inspected and approved content (Kumar: paragraph 453-454).
With regards to Claim 6, Di Girolamo in view of Lukanov, Sadhani and Gupta teach the method of Claim 5 above. Di Girolamo in view of Lukanov, Sadhani and Gupta do not explicitly teach:
wherein the method further comprises after said constructing the overlay layer resource key (Kn) for overlay layer n and before said saving the resource sub-tree in the etcd database obtaining a field manager for the resource from resource metadata;
determining either that the field manager exists in the API call and that the field manager in the API call equals the user Service Account or that the field manager does not exist in the API call.
However, Kumar teaches:
wherein the method further comprises after said constructing the resource key and before said saving the resource in the database
obtaining a field manager for the resource from resource metadata; (Paragraphs 452-453, “For authenticated users to perform key operations directly from the KDS portal (317) the users must be members of the designated role-based user group (for example, in the identity provider's authentication directory service) ... After verification, the broker 144 at step 144c creates a signing key for co-signing and extends the signature manifest. At step 144b, the content loader assigns a content identifier (UUID), content timestamp, content version, content type, and content description from the KDS portal (317). The key creation at step 144c for content file signing and generation of the extended signature manifest file may be accomplished with utilities, executing on an authenticated device, that use the KDS interface (167) APIs or through the KDS Portal (317) by authenticated users… Finally, the last approver in the chain notifies the policy manager to configure an update policy to associate the content file to qualified consumers (devices) 145 managed by field managers). At step 144e, the policy manager notifies the field manager to publish the content to the devices 145… The users at the broker 144 are content loaders, content approvers, policy managers, and field managers.” The last approver notifying the policy manager to associate the content file to qualified consumers managed by particular field managers, who are members of the same role-based group identifier found in the signature manifest file, would involve obtaining information on the particular field managers and therefore correlates to obtaining a field manager for the resource from resource metadata. The device first being authenticated and a signing key being created and the approvers verifying the content file before the field manager publishes the content correlates to the step occurring after said constructing the resource key and before said saving the resource in the database);
determining either that the field manager exists in the API call and that the field manager in the API call equals the user Service Account or that the field manager does not exist in the API call (Paragraphs 452-453, “For authenticated users to perform key operations directly from the KDS portal (317) the users must be members of the designated role-based user group (for example, in the identity provider's authentication directory service) ... At step 144b the broker 144 receives and verifies the content file using the signature manifest file, and at step 144c retrieves the key from the KDS 195 using the key identity hint in the signature manifest for the associated content file. After verification, the broker 144 at step 144c creates a signing key for co-signing and extends the signature manifest. At step 144b, the content loader assigns a content identifier (UUID), content timestamp, content version, content type, and content description from the KDS portal (317). The key creation at step 144c for content file signing and generation of the extended signature manifest file may be accomplished with utilities, executing on an authenticated device, that use the KDS interface (167) APIs or through the KDS Portal (317) by authenticated users… Finally, the last approver in the chain notifies the policy manager to configure an update policy to associate the content file to qualified consumers (devices) 145 managed by field managers). At step 144e, the policy manager notifies the field manager to publish the content to the devices 145… The users at the broker 144 are content loaders, content approvers, policy managers, and field managers.” The authenticated user performing key operations, where the user can be a field manager, correlates to an API call. The key identity hint in the signature manifest being used to retrieve the key for content file signing correlates to determining that the field manager exists in the API call, and in the case where the user is a field manager, additionally correlates to the field manager in the API call being equal the user Service Account. The device first being authenticated and the approvers verifying the content file before the field manager publishes the content correlates to the step occurring after said determining that the resource can be stored by the user Service Account and before said saving the resource in the database).
Kumar does not explicitly teach that the resource key is the overlay layer resource key (Kn) for overlay layer n and that the resource is a resource sub-tree [that is saved] in the etcd database. However, saving the resource sub-tree in the etcd database and constructing overlay layer resource key (Kn) for overlay layer n is a popular technique for storing resource trees as evidenced by Gupta above (Paragraphs 32, 40-41, 57 and 59, “The tree data structure 210 may be stored in the data lake or in a separate storage system. That is, the objects that comprise the overlayed metadata objects do not need to be stored in the same storage system as the data itself. For example, the tree data structure 210 may be stored in a relational database or key-value store… To facilitate this, a key-value store 150 has a key-value entry for each master branch, as well as key-value entries for private branches… Examples of a key-value store include ETCD (which is an open source, distributed, consistent key-value store for shared configuration, service discovery, and scheduler coordination of distributed systems or clusters of machines) … Master branch 200 comprises tree data structure 210 having a plurality of leaf nodes (e.g., references 2111-2133) referencing the data objects... Creating a private branch is performed using operations 706 and 708, which may be performed in response to an API call. Operation 706 includes copying a root node of tree data structure 210 of master branch 200.” The master branch comprises the tree data structure which is stored in an ETCD key-value store. The private branches copying the tree data structure and being stored in the key-value store therefore correlates to storing the resource sub tree into the etcd database using the overlay layer resource key).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Di Girolamo with constructing the overlay layer resource key (Kn) for overlay layer n and saving the resource sub-tree in the etcd database as taught by Gupta because key-value stores use key value tagging to facilitate coordination between storing, retrieving, and managing associative arrays. Data records can be stored and retrieved using a unique key which can further include attributes of data associated with the key. ETCD databases also provide a distributed, consistent key-value store for shared configuration, service discovery, and scheduler coordination of distributed systems or clusters (Gupta: paragraph 41).
Additionally, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Di Girolamo with wherein the method further comprises after said constructing the resource key and before said saving the resource in the database: obtaining a field manager for the resource from resource metadata; determining either that the field manager exists in the API call and that the field manager in the API call equals the user Service Account or that the field manager does not exist in the API call as taught by Kumar because managed content distribution workflows allow content creators to generate content files and have the content and signature manifest files approved by multiple content approvers through various content inspection methods. Additional content approvers may use multiple different methods such as static analysis, dynamic analysis, sandboxing, anomaly detection, reputation lists based on the approver's security profile and threat model assessments. After all approvers in a chain have approved the content, the content is finally updated to associate the file with update policies, device types, and device group. This ensures that the field manager publishes inspected and approved content (Kumar: paragraph 453-454).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Di Girolamo in view of Lukanov, Sadhani, Gupta and Tang et al. (U.S. Patent No. US 20240069976 A1), hereinafter “Tang.”
With regards to Claim 8, Di Girolamo in view of Lukanov, Sadhani and Gupta teach the method of Claim 2 above. Di Girolamo in view of Lukanov, Sadhani and Gupta do not explicitly teach:
employing, by the owner controller and the collaborator controller authorized to update the resource fields of overlay layer n using the one or more processors, an ectd Watch function to independently monitor the base layer and overlay layer n for changes in the base layer and the overlay layer n, respectively (n = 1, 2, ..., N)
However, Tang teaches:
employing, by the owner controller and the collaborator controller authorized to update the resource fields of a resource using the one or more processors, an ectd Watch function to independently monitor the resource for changes in the resource (Paragraphs 28, 30 and 51, “With a watch API, a user system opens a connection to an API server, which watches the specified data store, waiting for a repeated message from the data store server over the connection. Whenever there is a change on the data store, the user system receives a message about the change. The connection to the data store server remains alive until the application is finished. A number of watch API examples are known, including couchDB and etcd implemented examples… The client application will typically not monitor the upstream data store directly since the API server assists with client authentication and authorization, and usually, it is desirable not to disclose the underlying data store data structure and schema to the client application, or expose the data store credentials to the client application for security reasons… In one or more implementations, gateway interface 230 includes an agent to receive a watch request from user system 220 to monitor data store 240 for data change. The request can be received over open connection 221. With receipt of the watch request, gateway interface 230 invokes 231 a serverless setup service 232 implemented, in one embodiment, as a function as a service (FaaS).” The client application only monitoring authorized data store data structures and schemas correlates to the owner controller and collaborator controller authorized to update the resource fields of a resource. The user system sending an etcd watch request to monitor an etcd data store for changes correlates to employing by the owner controller and the collaborator controller authorized to update the resource fields using the one or more processors, an ectd Watch function to independently monitor the resource for changes in the resource).
Tang does not explicitly teach that the updated resource fields [are] of overlay layer n and that the resource monitored is a base layer and overlay layer n. However, base layers and overlay layers are a popular type of resource stored in etcd data stores as evidenced by Gupta above (Paragraphs 32 and 40-41, “The tree data structure 210 may be stored in the data lake or in a separate storage system. That is, the objects that comprise the overlayed metadata objects do not need to be stored in the same storage system as the data itself. For example, the tree data structure 210 may be stored in a relational database or key-value store… To facilitate this, a key-value store 150 has a key-value entry for each master branch, as well as key-value entries for private branches. The key-value entries are used for addressing the root nodes of branches… Examples of a key-value store include ETCD (which is an open source, distributed, consistent key-value store for shared configuration, service discovery, and scheduler coordination of distributed systems or clusters of machines), or other implementations using algorithms such as PAXOS, Raft and more.” The master and private branches being stored in a key-value store such as an ETCD key-value store correlates to saving the base and overlay layers in the etcd database). Additionally, resource fields in overlay layers are a popular type of resource that is updated as evidenced by Gupta above (Paragraphs 40, 48, “To facilitate this, a key-value store 150 has a key-value entry for each master branch, as well as key-value entries for private branches. The key-value entries are used for addressing the root nodes of branches… FIG. 5 illustrates a scenario 500 involving concurrent writing to private branches 400a and 400b by a plurality of writers (e.g., writers 134 and 136) … Writer 134, operated by a user 501, writes data object 128, thereby updating private branch 400a).” The writer writing data object 128 and updating the private branch correlates to updating a resource field in overlay layer n).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Di Girolamo with update the resource fields of overlay layer n using the one or more processors, and the base layer and over layer n in an etcd database as taught by Gupta because key-value stores use key value tagging to facilitate coordination between storing, retrieving, and managing associative arrays. Data records can be stored and retrieved using a unique key which can further include attributes of data associated with the key. ETCD databases also provide a distributed, consistent key-value store for shared configuration, service discovery, and scheduler coordination of distributed systems or clusters (Gupta: paragraph 41).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Di Girolamo with employing, by the owner controller and the collaborator controller authorized to update the resource fields of a resource using the one or more processors, an ectd Watch function to independently monitor the resource for changes in the resource as taught by Tang because watch APIs can be used to resolve cache invalidation issues by determining when information being displayed or cached is no longer an appropriate representation of the underlying data store. This can additionally benefit backend and frontend cache invalidation detection (Tang: paragraph 28).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Di Girolamo in view of Lukanov, Sadhani, Gupta and Durand et al. (U.S. Patent No. US 12111940 B1), hereinafter “Durand.”
With regards to Claim 9, Di Girolamo in view of Lukanov, Sadhani and Gupta teach the method of Claim 2 above. Di Girolamo in view of Lukanov, Sadhani and Gupta does not explicitly teach:
wherein a managedFields data structure includes metadata specific to the owner controller and metadata specific to the collaborator controller of overlay layer m (n = 1, 2, ..., N), and wherein the method further comprises: releasing, by the one or more processors, the collaborator controller of overlay layer m, wherein m is selected from the group consisting of 1, 2, ..., and N; and
in response to said releasing, removing, by the one or more processors, the metadata specific to the collaborator controller of overlay layer m from the managedFields data structure.
However, Durand teaches:
wherein a managedFields data structure includes metadata specific to the owner controller and metadata specific to the collaborator controller of a resource (Col. 21, lines 27-32 and Col. 23, lines 17-23, “Policy database 720 may comprise records that correspond to security policies that pertain the computing resources directly managed by a computing resource service provider, as well as those that are managed by resources within the service provider… Policy management service 818 may receive an update permission 816 request from database management system 802 and update policy database 820 to reflect the requested permission grant. For example, policy database 820 may be updated with a new record that corresponds to a security policy that can be used to grant access to securable resources 810 of database 822.” The policy database being updated with every permission grant for users, such as computing resource service providers and their resources, to securable resources in the database correlates to a managedFields data structure including metadata specific to the owner controller and metadata specific to the collaborator controller of a resource), and wherein the method further comprises: releasing, by the one or more processors, the collaborator controller of the resource m, wherein m is selected from the group consisting of 1, 2, ..., and N (Col. 23, lines 57-67, “In FIG. 9, a first user 904A of database service 902 is depicted as submitting an API request to grant a permission. A first permission grant 906A submitted by first user 904A via database service 902 may be used to modify the privileges of database users. A grant is typically used to expand a user's access privileges, whereas a revoke is typically used to reduce a user's access rights. While a first permission grant 906A is depicted in FIG. 9, techniques described herein may be similarly applicable to revocations and any other types of commands that modify users' database privileges.” The first user submitting a permission request such as a revoke request, which reduces a particular user out of the many database users access rights to a particular resource of the many resources, correlates to releasing, by the one or more processors, the collaborator controller of a resource, wherein m is selected from the group consisting of 1, 2, ..., and N); and
in response to said releasing, removing, by the one or more processors, the metadata specific to the collaborator controller of the resource from the managedFields data structure (Col. 18, lines 14-21 and Col. 24, lines 4-11, “Database grants are used to provide users of a database with various privileges on tables and views, according to various embodiments. Conversely, database revokes may be used to revoke various permission grants that may have been previously issued. Database systems may implement a deny-by-default stance whereby access to database resources is denied by default, unless there is an explicit grant of permission… When service frontend 908 detects a request to modify permissions, that request may be forward to policy management service 910. Policy management service 910, in at least one embodiment, includes a software component that is used to map the database permission grant 906A to a first policy 912A that is stored in policy database 914. First policy 912A may comprise a principal, an action, a resource, and an effect.” The request to modify permissions is forwarded to a policy management service which updates the mapping of the database permission request to a first policy stored in the policy database. The database may implement a deny-by-default stance, where permissions are denied unless there is an explicit grant of permission in the policy database. Therefore, in the case of a permission revoke request, the updating of the policy database would involve deleting the previously granted mapping of the grant of permission from the database and correlates to removing the metadata specific to the collaborator controller of the resource from the managedFields data structure in response to said releasing).
Durand does not explicitly teach that the resource is an overlay layer. However, overlay layers are a popular type of resource stored in databases as evidenced by Gupta above (Paragraphs 32 and 40-41).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Di Girolamo with overlay layers as taught by Gupta because key-value stores use key value tagging to facilitate coordination between storing, retrieving, and managing associative arrays. Data records can be stored and retrieved using a unique key which can further include attributes of data associated with the key. ETCD databases also provide a distributed, consistent key-value store for shared configuration, service discovery, and scheduler coordination of distributed systems or clusters. Writers leveraging a write ahead log for writing and reading increases crash resistance, and combined with persistence properties of the data lake storage, assists with the durability aspects of ACID (Gupta: paragraphs 25, 41 and 48).
Additionally, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Di Girolamo with wherein a managedFields data structure includes metadata specific to the owner controller and metadata specific to the collaborator controller of a resource, and wherein the method further comprises: releasing, by the one or more processors, the collaborator controller of the resource, wherein m is selected from the group consisting of 1, 2, ..., and N; and response to said releasing, removing, by the one or more processors, the metadata specific to the collaborator controller of the resource from the managedFields data structure as taught by Durand because policy databases can comprise records that correspond to security policies that pertain the computing resources directly managed by a computing resource service provider, as well as those that are managed by resources within the service provider, which can be used to perform policy evaluations on behalf of the database system. Database management systems can receive permission grants or revocations and use a policy management service to ensure the requests reflect the security policies stored in the policy database. This allows mathematically sound policy analysis to be performed on the database-related policies to ensure they accurately reflect the permission grants of the database management system (Durand: Col. 21, lines 27-32 and Col. 24, lines 37-46).
Claims 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over Di Girolamo in view of Lukanov, Sadhani, and Durand.
With regards to Claim 11, Di Girolamo in view of Lukanov and Sadhani teach the method of Claim 1 above. Di Girolamo in view of Lukanov and Sadhani does not explicitly teach:
wherein an extension to a Role-Based Access Control (RBAC) includes a field that defines each collaborator controller and authorizes each collaborator controller to update, by patching, the fields of the sub-tree that each collaborator controller creates.
However, Durund teaches:
wherein an extension to a Role-Based Access Control (RBAC) includes a field that defines each collaborator controller and authorizes each collaborator controller to update, by patching, the fields of the sub-tree that each collaborator controller creates (Col. 12, lines 39-48, Col. 39, lines 37-41, “A role may be an identity within a computing environment with permission policies that may be used to determine a set of capabilities that the role is capable of performing within the context of the computing environment. The permissions may include rights to access data resources (e.g., rights to create, read, update, and delete a file) as well as access to services (e.g., rights to make an API request and have the request fulfilled by a service) as well as other rights (e.g., administrative rights in a computer system to grant or revoke permissions to users) … Each user, group, role, or other such collection of principals may have a corresponding user definition, group definition, role definition, or other definition that defines the attributes and/or membership of that collection.” Each user having a corresponding user, group, role, or other definition defining attributes, where a role is associated with a set of capabilities and permissions, correlates to an extension to a Role-Based Access Control (RBAC) includes a field that defines each collaborator controller. The role that a user has including access rights for creating and updating resources correlates to the field authorizing each collaborator controller to update, by patching, the fields of the sub-tree that each collaborator controller creates).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Di Girolamo with wherein an extension to a Role-Based Access Control (RBAC) includes a field that defines each collaborator controller and authorizes each collaborator controller to update, by patching, the fields of the sub-tree that each collaborator controller creates as taught by Durand because database management systems can receive permission grants or revocations and use a policy management service to ensure the requests reflect the security policies stored in the policy database. This allows mathematically sound policy analysis to be performed on the database-related policies to ensure they accurately reflect the permission grants of the database management system (Durand: Col. 21, lines 27-32 and Col. 24, lines 37-46).
With regards to Claim 12, Di Girolamo in view of Lukanov, Sadhani and Durand teach the method of Claim 11 above. Lukanov further teaches:
wherein the method further comprises: role binding, by the one or more processors, a user Service Account to a controller role of one of the collaborator controllers via metadata that links the user Service Account to the controller role (Paragraphs 32, 41, and 49, “The resource managing service 125 can configure containers for the directory and mapped to container memberships. A container membership can gather a group of users (e.g., defined according to a predefined rules, for example, all users of tenant A, and all users with a role “Administrator”, among other examples) that share access rights to one or more containers defined as a set(s) of resources from the resources of the resource directory... For example, if a container defined at the directory 155 that corresponds to a sub-tree K is associated with a tenant account N, users associated with the tenant account N can have a container membership for the sub-tree K. Thus, a user of the tenant account N can be provided with permissions and privileges that correspond to their role according to the relevant authorization scheme for those resources of the resource directory that are part of the sub-tree K… The authorization server 220 can define one or more authorization schemes, where the authorization schemes can be mapped to different container memberships defined for the cloud data center 205 at the container policies 240. The authorization schemes at the authorization server 220 can support access control restrictions based on an RBAC-based model and can include roles, global permissions for the cloud data center 205, and inventory permissions for inventory objects included in the inventory 210.” The authorization schemes mapping container memberships, which define specific users of a particular role such as an administrator, correlates to role binding a user Service Account to a controller role of one of the collaborator controllers via metadata that links the user Service Account to the controller role).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Di Girolamo with wherein the method further comprises: role binding, by the one or more processors, a user Service Account to a controller role of one of the collaborator controllers via metadata that links the user Service Account to the controller role as taught by Lukanov because access controls can be propagated to apply to child resources of a first root entity. This allows permissions provided to a root node of a sub-tree to be propagated to all child nodes in the sub-tree. Defining containers and container memberships for respective sets of resources within a resource directory maintains separation between access rights of different principals to dedicated sets of the resources (Lukanov: paragraphs 25-26).
Prior Art Made of Record
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Van Os et al. (U.S. Patent No. US 20230259382 A1); teaching a method of managing a container cluster framework including a Kubernetes control plane containing an etcd distributed key-value store with discoverable Kubernetes topological and deployment details for instances of applications that are managed by Kubernetes. A containment hierarchy of application instances may also be used for application instances containing and exposing multiple services or microservices.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SELINA HU whose telephone number is (571)272-5428. The examiner can normally be reached Monday-Friday 8:30-5:30.
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, Chat Do can be reached at (571) 272-3721. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Please note that the publicPAIR and privatePair systems are no longer available. 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.
SELINA HU
Examiner
Art Unit 2193
/Chat C Do/ Supervisory Patent Examiner, Art Unit 2193