DETAILED ACTION
This office action is in response to application filed on 10/19/2023.
Claims 1 – 23 are pending.
Priority is claimed to Indian application IN202341049244 (filed on 7/21/2023)
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, 4, 5, 7, 9 – 12, 15, 16, 18, and 20 – 23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dubrovsky et al (US 20240354426, hereinafter Dubrovsky), in view of Islam et al (US 20150120939, hereinafter Islam).
As per claim 1, Dubrovsky discloses: A method for pre-deployment evaluation of a package comprising a plurality of files comprising a plurality of resource definitions of a plurality of resources for deployment in a container cluster, comprising:
receiving a request to evaluate the package; (Dubrovsky [0079]: “Operation 404 depicts identifying that computer-executable code for a microservice has been created or modified, wherein the microservice is part of a group of microservices that are configured to be executed in a containerized environment.”)
generating, for each of the plurality of resources, a role-based access control (RBAC) rule based on the one or more attributes of the associated resource type of the resource and the corresponding resource definition of the resource; and generating a collection of RBAC rules including the generated RBAC rule for each of the plurality of resources. (Dubrovsky [0085]: “Operation 408 depicts generating an access policy based on the policy access rules according to a first format of a first target system type, wherein there is a configuration to generate access policies according to a group of formats that comprise the first format… A system that implements process flow 400 can be configured to generate access policies according to a group of formats, such as those that correspond to multiple types of products that support microservice architectures. Here, the access policies can be generated in a first format that corresponds to an architecture of the target system on which an instance of the microservice will be deployed.”)
Dubrovsky did not explicitly disclose:
determining, for each of one or more resource types, one or more attributes of the resource type including a kind of the resource type;
determining, for each of the plurality of resources, an associated resource type of the one or more resource types, based on a match between the kind of the associated resource type and a kind of the resource as defined in a corresponding resource definition of the plurality of resource definitions;
Islam teaches:
determining, for each of one or more resource types, one or more attributes of the resource type including a kind of the resource type; (Islam [0062]: “a service resource can be provided using a provider type and a provider SME. A service definition package (SDP) for the service can specify a dependency on a provider, and include association rules that define actions to be taken with regard to a runtime of the provider. When the service is provisioned, a service resource type which is derived from a provider SDP can be associated with the service. As a result of the association, a service resource can be automatically created from the service resource type in accordance with the association rules, to provide resources for consumption by the application.”)
determining, for each of the plurality of resources, an associated resource type of the one or more resource types, based on a match between the kind of the associated resource type and a kind of the resource as defined in a corresponding resource definition of the plurality of resource definitions; (Islam [0008]: “A service definition package (SDP) for the service can specify a dependency on a provider, and include association rules that define actions to be taken with regard to a runtime of the provider. When the service is provisioned, a service resource type which is derived from a provider SDP can be associated with the service. As a result of the association, a service resource can be automatically created from the service resource type in accordance with the association rules, to provide resources for consumption by the application. In accordance with an embodiment, the provider SDP can include a plurality of feature sets associated with different sets of configurable properties, which allows different provider types or service resource types to be created.”)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Islam into that of Dubrovsky in order to determine, for each of one or more resource types, one or more attributes of the resource type including a kind of the resource type; and determining, for each of the plurality of resources, an associated resource type of the one or more resource types, based on a match between the kind of the associated resource type and a kind of the resource as defined in a corresponding resource definition of the plurality of resource definitions. Islam [0008] teaches doing so would allow creation of different service resource types for fast deployment. Adding identification and matching of the resource type with definition would produce a predictable result of fast creating and selecting appropriate service resource to deploy the service, and would enhance the overall appeals of all references and is therefore rejected under 35 USC 103.
As per claim 4, the combination of Dubrovsky and Islam further teach:
The method of claim 1, wherein the one or more attributes of the resource type further include a group of the resource type, and wherein determining the associated resource type is further based on a match between the group of the associated resource type and a group of the resource as defined in the corresponding resource definition. (Islam [0008])
As per claim 5, the combination of Dubrovsky and Islam further teach:
The method of claim 4, wherein generating, for each of the plurality of resources, the RBAC rule comprises: inserting the group of the resource as defined in the corresponding resource definition; inserting a name of the resource as defined in the one or more attributes of the associated resource type of the resource; and inserting one or more verbs of the resource as defined in the one or more attributes of the associated resource type of the resource. (Dubrovsky [0065] – [0069])
As per claim 7, the combination of Dubrovsky and Islam further teach:
The method of claim 1, wherein determining, for each of the one or more resource types, the one or more attributes of the resource type comprises querying the container cluster for the one or more attributes. (Dubrovsky [0048])
As per claim 9, the combination of Dubrovsky and Islam further teach:
The method of claim 1, wherein the collection of RBAC rules further includes one or more RBAC rules defined in the package. (Dubrovksy [0085])
As per claim 10, the combination of Dubrovsky and Islam further teach:
The method of claim 1, wherein generating the collection of RBAC rules comprises merging a first generated RBAC rule for a first resource with a second generated RBAC rule for a second resource. (Dubrovksy [0085])
As per claim 11, the combination of Dubrovsky and Islam further teach:
The method of claim 1, further comprising: applying the collection of RBAC rules to the container cluster; and deploying the package to the container cluster. (Dubrovksy [0087])
As per claim 12, it is the system variant of claim 1 and is therefore rejected under the same rationale. (Dubrovsky figure 12)
As per claim 15, it is the system variant of claim 4 and is therefore rejected under the same rationale.
As per claim 16, it is the system variant of claim 5 and is therefore rejected under the same rationale.
As per claim 18, it is the system variant of claim 7 and is therefore rejected under the same rationale.
As per claim 20, it is the system variant of claim 9 and is therefore rejected under the same rationale.
As per claim 21, it is the system variant of claim 10 and is therefore rejected under the same rationale.
As per claim 22, it is the system variant of claim 11 and is therefore rejected under the same rationale.
As per claim 23, it is the non-transitory computer-readable media variant of claim 1 and is therefore rejected under the same rationale. (Dubrovsky [0157] – [0158]: CRM.)
Claim(s) 2, 3, 13 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dubrovsky and Islam, and further in view of Zhou et al (US 20210312392, hereinafter Zhou).
As per claim 2, the combination of Dubrovsky and Islam did not teach:
The method of claim 1, wherein the collection of RBAC rules includes a role including the generated RBAC rule for each of one or more of the plurality of resources that are namespaced in a same namespace.
However, Zhou teaches:
The method of claim 1, wherein the collection of RBAC rules includes a role including the generated RBAC rule for each of one or more of the plurality of resources that are namespaced in a same namespace. (Zhou [0002]: “The development of such an application (referred to herein as a “multi-cluster application”) involves, among other things, the creation of a namespace for the application in each target cluster (which provides a unique resource/object scope for the application within that cluster), and the setting of certain policies on those namespaces (which allows, for example, the application's development team members to access the namespaces and deploy their application objects therein).”; [0041]: “MCM system 102 can synchronize the access policy to the member namespaces of the workspace by translating the access policy into a native format understood by Kubernetes (e.g., a role-based access control (RBAC) policy) and transmitting the native policy to each cluster of organization 106 that includes a member namespace of the workspace.”)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Zhou into that of Dubrovsky and Islam in order to have the collection of RBAC rules includes a role including the generated RBAC rule for each of one or more of the plurality of resources that are namespaced in a same namespace. Zhou [0041] teaches RBAC rules can be applied and synchronized to member namespaces of the workspace. Creating RBAC rules for all resource in a same namespace would allow the rule be synchronized to all members of the namespace and would ensure the configuration conformity of the resources, such combination would results in a predictable results of better resource control using RBAC and is therefore rejected under 35 USC 103.
As per claim 3, the combination of Dubrovsky and Islam did not teach:
The method of claim 1, wherein the collection of RBAC rules includes a Cluster Role including the generated RBAC rule for each of one or more of the plurality of resources that are not namespaced.
However, Zhou teaches:
The method of claim 1, wherein the collection of RBAC rules includes a Cluster Role including the generated RBAC rule for each of one or more of the plurality of resources that are not namespaced. (Zhou [0002]: “The development of such an application (referred to herein as a “multi-cluster application”) involves, among other things, the creation of a namespace for the application in each target cluster (which provides a unique resource/object scope for the application within that cluster), and the setting of certain policies on those namespaces (which allows, for example, the application's development team members to access the namespaces and deploy their application objects therein).”; [0041]: “MCM system 102 can synchronize the access policy to the member namespaces of the workspace by translating the access policy into a native format understood by Kubernetes (e.g., a role-based access control (RBAC) policy) and transmitting the native policy to each cluster of organization 106 that includes a member namespace of the workspace.”)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Zhou into that of Dubrovsky and Islam in order to have the collection of RBAC rules includes a Cluster Role including the generated RBAC rule for each of one or more of the plurality of resources that are not namespaced. Zhou [0041] teaches RBAC rules can be applied and synchronized to member namespaces of the workspace. Creating RBAC rules for all resource in a same namespace would allow the rule be synchronized to all members of the namespace and would ensure the configuration conformity of the resources, such combination would results in a predictable results of better resource control using RBAC and is therefore rejected under 35 USC 103.
As per claim 13, it is the system variant of claim 2 and is therefore rejected under the same rationale.
As per claim 14, it is the system variant of claim 3 and is therefore rejected under the same rationale.
Claim(s) 6 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dubrovsky and Islam, and further in view of Poddar et al (US 20220350642, hereinafter Poddar).
As per claim 6, the combination of Dubrovsky and Islam did not teach:
The method of claim 1, wherein the package comprises a Helm chart.
However, Poddar teaches:
The method of claim 1, wherein the package comprises a Helm chart. (Poddar [0015])
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Poddar into that of Dubrovsky and Islam in order to have the package comprises a Helm chart. Dubrovsky [0053] teaches analyze microservices network dependencies by analyzing RBAC defined rules in an expression markup language. Poddar [0015] teaches such dependencies are commonly known to be represented using helm chart, thus applicant have merely claimed the combination of known parts in the field to achieve the predictable results of representing dependencies using a known technique and is therefore rejected under 35 USC 103.
As per claim 18, it is the system variant of claim 7 and is therefore rejected under the same rationale.
Claim(s) 8 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dubrovsky and Islam, and further in view of Poddar et al (US 20220350642, hereinafter Poddar).
As per claim 8, the combination of Dubrovsky and Islam did not teach:
The method of claim 1, wherein determining, for each of the one or more resource types, the one or more attributes of the resource type comprises extracting the one or more attributes for one or more custom resource types from the package.
However, Poddar teaches:
The method of claim 1, wherein determining, for each of the one or more resource types, the one or more attributes of the resource type comprises extracting the one or more attributes for one or more custom resource types from the package. (McPherson [0060])
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of McPherson into that of Dubrovsky and Islam in order to determine for each of the one or more resource types, the one or more attributes of the resource type comprises extracting the one or more attributes for one or more custom resource types from the package. McPherson [0060] teaches the advantage of doing so is to aid in the fast deployment of the package. Thus it would have been obvious for one of ordinary skill in the art to adapt the teaching of McPherson into that of the existing prior art in order to achieve a predictable result of improved package deployment, using known methods, and is therefore rejected under 35 USC 103.
As per claim 19, it is the system variant of claim 8 and is therefore rejected under the same rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Doshi et al (US 20230340166) teaches “A method of controlling access to resource objects in a cloud-based storage system, and application server therefor, includes defining role-based access scopes and user-based virtual scopes for resources in the cloud-based storage system. A role-based access scope is used to define actions that may be performed with a requested resource based on a role of the user making the request. A virtual scope is used to define actions that may be performed with a requested resource based on the user making the request. The virtual scope is used to restrict access to a resource to one or more of the members assigned to a role.”;
Mosko (US 20230086475) teaches “During operation, the system determines a Windows domain model including: user-specified desired effective permissions as capability assignments of principals on resources, wherein a respective capability assignment comprises a permission of a respective principal to a respective resource and wherein a respective principal comprises a user or a group of users; and user-specified policies and rules for relationships between principals, groups, and resources. The system creates a domain graph and an access control graph based on the Windows domain model. The domain graph maps paths between nodes representing users, groups, and resources based on the policies and rules. The access control graph allows for calculation of actual permissions of principals on resources based on the desired effective permissions. The system determines a set of optimal policy-conformant configurations based on the domain graph and the access control graph.”;
Shipkovenski et al (US 20220053001) teaches “identifying, in response to creation of a containerized computing namespace, a user account that is to be granted access to a containerized computing namespace, creating a service account, the service account representing the user account for the containerized computing namespace creating a role within the containerized computing namespace, and assigning a role binding between the role and the service account.”;
Matthew et al (USPAT 11200157) teaches “A user makes requests to a build service provided by the computing resource service provider which automates building and testing of program code for software modules and software projects including such modules. The build service receives the requests and allocates physical computing resources, such as usage of processors, memory, storage drives, computer network interfaces, and other components of hardware computing devices within a virtual computing environment to attempt to build the software modules and report results of tests performed during the build attempts. The user may supply program code to be built without otherwise needing to manage the virtual computing resources allocated to complete the requested tasks.”.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLES M SWIFT whose telephone number is (571)270-7756. The examiner can normally be reached Monday - Friday: 9:30 AM - 7PM.
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, April Blair can be reached at 5712701014. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/CHARLES M SWIFT/Primary Examiner, Art Unit 2196