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
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-11 and 13-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kavadimatti (US 20210028993 A1) in view of Bahl (US 20210019194 A1).
Regarding claim 1, Kavadimatti teaches a method of modeling a deployed system infrastructure of a cloud computing environment, the method comprising: (Fig. 1 and Abstract)
generating, by one or more processors, an abstract system model comprising one or more model elements corresponding to one or more infrastructure elements of the deployed system infrastructure, ([0029]: a configuration model determiner to, after deployment of a blueprint in a hybrid cloud environment, generate a first model including first relationships of a first plurality of resources corresponding to the blueprint, the blueprint including a plurality of properties in which at least one of the plurality of properties is agnostic of type. Fig. 6 and Fig. 7
building, by the one or more processors, an inventory of the one or more infrastructure elements; ([0029]: an inventory model determiner to generate a second model including second relationships of a second plurality of resources as deployed in the hybrid cloud environment based on the blueprint
for at least one model element of the one or more model elements, identifying, by the one or more processors, the at least one infrastructure element of the inventory associated with the at least one model element as indicated by the respective one or more selectors of the at least one model element; ([0031]-[0032]: the inventory model is represented as a model of the state of resources(s) currently running in the deployment when the inventory model is generated. Inventory model is an undirected graph representative of a single resource and/or plurality of resources corresponding to the resource(s) and/or relationships in the blueprint model as deployed in any of the private cloud, the hybrid cloud, and/or the public cloud.)
generating, by the one or more processors, a bound system model comprising one or more associations between the one or more model elements of the abstract system model and the inventory of the one or more infrastructure elements, wherein the one or more associations are determined based at least in part on the identified at least one infrastructure element of the inventory associated with the at least one model element; and ([0029]: a drift determiner to determine a drift value based on the first relationships and the second relationships, the drift value representative of a difference between the first relationships and the second relationships. [0032]: the drift detector 102 is operable to generate an example drift report 130 representative of a drift value associated with the single and/or plurality of resources previously modeled (e.g., the resource(s) modeled in the blueprint model 126 and/or the inventory model 128).)
outputting, by the one or more processors, data indicative of a status of the deployed system infrastructure, an incident occurring within the deployed system infrastructure, or both, the data generated using the bound system model. (Fig. 6-7. [0024]: drift is defined as the deviation of the real-world state of an infrastructure from the state defined in the configuration (e.g., the blueprint). A drift value in a deployment may occur when one or more resources defined in a blueprint are not actually instantiated have been terminated and/or have failed (e.g., broken, etc.). [0032]: the drift detector 102 is operable to generate an example drift report 130 (e.g. data indicative) representative of a drift value (e.g., a status) associated with the single and/or plurality of resources previously modeled (e.g., the resource(s) modeled in the blueprint model 126 and/or the inventory model 128).)
Kavadimatti does not explicitly disclose wherein: each model element of the one or more model elements specifies one or more selectors, and for each model element of the one or more model elements, each selector of the respective one or more selectors of the model element includes an indication of at least one infrastructure element, from the one or more infrastructure elements, that is associated with the model element.
However, Bahl teaches wherein: each model element of the one or more model elements specifies one or more selectors, and for each model element of the one or more model elements, each selector of the respective one or more selectors of the model element includes an indication of at least one infrastructure element, from the one or more infrastructure elements, that is associated with the model element. ([0050]-[0052]: the container orchestrator can support labels (also sometimes referred to as tags, metadata, and the like) and selectors. Label selectors can be used to select objects based on their labels, and may include equality-based selectors and set-based selectors. The set of pods targeted by a Kubernetes® service can be determined by a label selector.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include above limitation into Kavadimatti. One would have been motivated to do so because it is desirable for user be able to select an element/resource in the system model for refined display, such as to isolate, highlight, or display detailed properties of specific element/resource.
Regarding claim 2, Kavadimatti and Bahl teach the method of claim 1.
Kavadimatti teaches wherein the one or more infrastructure elements comprise: one or more physical elements of the deployed system infrastructure, one or more virtual elements of the deployed system infrastructure, or a combination thereof. ([0019]: Cloud computing is based on the deployment of many physical resources across a network, virtualizing the physical resources into virtual resources, and provisioning the virtual resources to perform cloud computing, services and applications.)
Regarding claim 3, Kavadimatti and Bahl teach the method of claim 1.
Kavadimatti teaches wherein building the inventory of the one or more infrastructure elements comprises obtaining information regarding the one or more infrastructure elements from: a service hosting the deployed system infrastructure, an application programming interface (API), or a combination thereof. ([0071]: The inventory of cloud endpoints (e.g., the private cloud 118, the hybrid cloud 120, and/or the public cloud 122) can be collected frequently (e.g., every ten minutes) to reconcile the real state with the inventory of the deployment. At every frequency (e.g., every ten minutes), all the relevant resources and their properties are queried via the cloud provider 116 of FIG. 1 and the model 700 of the deployment 132 is updated with latest state.)
Regarding claim 4, Kavadimatti and Bahl teach the method of claim 1.
Bahl teaches wherein the respective one or more selectors of the at least one model element include, in the indication of the at least one infrastructure element associated with the at least one model element, one or more aspects of an ancestor element, the one or more aspect of the ancestor element used to determine the one or more associations between the one or more model elements of the abstract system model and the inventory of the one or more infrastructure elements. ([0050]-[0052]. [0101]: the multi-cloud service mesh orchestration platform can tag a microservice configuration object with information associating the microservice container with the service mesh application, such as the role of the microservice container (e.g., a Directed Acyclic Graph (DAG) graph representing the service mesh application with each node representing a microservice container and each edge indicating the flow of the application), the microservice container's dependencies and other microservice containers dependent upon the microservice container, and so forth. In some cases, a microservice configuration object may be tagged with multiple labels relating to its role if a microservice container forms a part of multiple applications.)
Regarding claim 5, Kavadimatti and Bahl teach the method of claim 4.
Bahl teaches wherein the one or more aspects of the ancestor element comprise: a label of the ancestor element, a property of the ancestor element, or a combination thereof. ([0050]-[0052]: the container orchestrator can support labels (also sometimes referred to as tags, metadata, and the like) and selectors. [0101]: the multi-cloud service mesh orchestration platform can tag a microservice configuration object with information associating the microservice container with the service mesh application, such as the role of the microservice container (e.g., a Directed Acyclic Graph (DAG) graph representing the service mesh application with each node representing a microservice container and each edge indicating the flow of the application), the microservice container's dependencies and other microservice containers dependent upon the microservice container, and so forth. In some cases, a microservice configuration object may be tagged with multiple labels relating to its role if a microservice container forms a part of multiple applications.)
Regarding claim 6, Kavadimatti and Bahl teach the method of claim 4.
Kavadimatti teaches wherein identifying the at least one infrastructure element of the inventory associated with the at least one model element comprises: (i) evaluating a first portion of the respective one or more selectors of the at least one model element that do not reference to the ancestor element, (ii) subsequent to operation (i), evaluating a second portion of the respective one or more selectors of the at least one model element that reference the ancestor element, and (Fig. 6 and 7. [0045]: the resource parser parses the resource(s) contained in the blueprint and in the deployment. After parsing the resource(s) contained in the blueprint, the resource parser then identifies the corresponding resource, as deployed, in the deployment. After parsing and identifying an individual resource in the blueprint, and identifying the corresponding resource as deployed in the deployment, the resource parser then determines whether an additional resource is available. If an additional resource is available, then the resource parser parses the additional resource contained in the blueprint and the corresponding resource, as deployed, in the deployment.)
(iii) repeating operations (i) and (ii) until all of the respective one or more selectors of the at least one model element are evaluated. ([0046]-[0047]: The resource drift determiner determines the drill of the identified resource(s). In examples disclosed herein, the resource drift determiner determines the blueprint model of FIG. 1 for the identified resource based on the identified resource and the corresponding relationships as included in the blueprint. In addition, the example drift determiner determines the inventory model for the identified resource based on the identified resource and the corresponding relationships as included in the deployment.)
Regarding claim 7, Kavadimatti and Bahl teach the method of claim 4.
Bahl teaches wherein identifying the at least one infrastructure element of the inventory associated with the at least one model element comprises using: a label-based match, a query, a heuristic, or a combination thereof. ([0050]: the container orchestrator can support labels (also sometimes referred to as tags, metadata, and the like) and selectors. Labels can be key-value pairs used to group together sets of objects, such as pods. Labels can also specify attributes of objects that may be meaningful and relevant to network users.)
Regarding claim 8, Kavadimatti and Bahl teach the method of claim 1.
Bahl teaches wherein the respective one or more selectors of the at least one model element include, in the indication of the at least one infrastructure element associated with the at least one model element, one or more variables to substitute for one or more aspects of an ancestor element of the at least one model element. ([0050]: the container orchestrator can support labels (also sometimes referred to as tags, metadata, and the like) and selectors. Labels can be key-value pairs used to group together sets of objects, such as pods. Labels can also specify attributes of objects that may be meaningful and relevant to network users. There can be an N×N relationship between objects and labels. That is, each object can have multiple labels, and each label may be applied to different objects. The label key can include a prefix and a name.)
Regarding claim 9, Kavadimatti and Bahl teach the method of claim 1.
Bahl teaches wherein the at least one model element comprises a stream of telemetry associated with an ancestor element, the stream of telemetry comprising: a metric, a log, an event trace, or a combination thereof. ([0058]: collect telemetry data from the pods 226A, 226B, and 226C. The policy and telemetry hub 310 can communicate with adapters 312A and 312B (collectively, 312) to interface with a specific infrastructure backend for metrics, logs, and so forth.)
Regarding claim 10, Kavadimatti and Bahl teach the method of claim 1.
Kavadimatti teaches wherein a child element comprises a relationship between abstract system model elements and/or inventory elements. ([0029]: a drift determiner to determine a drift value based on the first relationships and the second relationships, the drift value representative of a difference between the first relationships and the second relationships.)
Regarding claim 11, Kavadimatti and Bahl teach the method of claim 1.
Kavadimatti teaches further comprising updating the bound system model in response to a detected change in the inventory of the one or more infrastructure elements. ([0027]: drift detection ability for deployments to detect a drift associated with a resource in which alterations (e.g., infrastructure changes, resource changes, configuration changes, etc.) have been made outside of a cloud-based provisioning service (e.g., VMware Cloud Assembly). Once drift detection of a resource is complete, examples disclosed herein include generating a report showing the result of the drift detection. For example, if a resource in a deployment and/or infrastructure is altered, the report includes a representation of the deviation (e.g., drift) from the blueprint.)
Same rationales apply to claim 13 (system) and claim 17 (CRM) because they are substantially similar to claim 1 (method).
Same rationales apply to claim 14 (system) and claim 18 (CRM) because they are substantially similar to claim 2 (method).
Same rationales apply to claim 15 (system) and claim 19 (CRM) because they are substantially similar to claim 3 (method).
Same rationales apply to claim 16 (system) and claim 20 (CRM) because they are substantially similar to claim 4 (method).
Claim(s) 12 is rejected under 35 U.S.C. 103 as being unpatentable over Kavadimatti (US 20210028993 A1) in view of Bahl (US 20210019194 A1), and in view of Avery (US 20140280204 A1).
Regarding claim 12, Kavadimatti and Bahl teach the method of claim 11.
Kavadimatti and Bahl do not explicitly disclose maintaining a history indicative of times at which the bound system model is updated.
However, Avery teaches maintaining a history indicative of times at which the bound system model is updated. ([0033]: Serving as a central repository, the CMS typically increases the version level of new updates to an already existing file (e.g., the CMS has the ability to collect and track data for content in the CMS, which may include authors, change dates and file versions, as well a document change metrics).)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include above limitation into Kavadimatti and Bahl. One would have been motivated to do so because it is common practice in a document or content management system (CMS), to track changes between versions of a document. As taught by Avery, [0004].
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZI YE whose telephone number is (571)270-1039. The examiner can normally be reached Monday - Friday, 8:00am - 4:00pm.
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, Emmanuel Moise can be reached at 5712723865. 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.
/ZI YE/Primary Examiner, Art Unit 2455