DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to application filed on 6/6/2024, wherein claims 1-20 are pending, and claims 1, 7 and 14 are independent claims
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 8, 10-11 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The following claim terms lack antecedent basis:
As for Claim 8, which recites the limitation "resource management system", claim 7 from which claim 8 depends, recites only “a resource management engine” it is unclear if the two claimed objects are the same or different, and whether the resource management system refers to the IHS itself, or another unclaimed system. For the purpose of examination, it is assumed the system is referring to the resource management engine of claim 7. Correction is required.
As for claim 10, it is unclear what is meant by “first resource capability information” because claim 7 upon which it depends only claims “respective resource capability information” with no “first” resource capability information. For the purpose of examination Examiner assume it refers to an instance of respective resource capability information. Correction is required.
As for claim 11: it is unclear what is meant by “the resource/workload configuration file” because claim 7 upon which it depends claims a “first resource/workload configuration file” while another dependent claim 13 claims “second resource/workload configuration file”, thus it is unclear what configuration file is “the resource/workload configuration file” referring to. For the purpose of examination, Examiner assume it can be any configuration file and not limited to the first one in claim 7. Correction is required.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-5, 7-11, 13-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Dawkins et al. (US PGPUB 2022/0179702), in view of Aftab et al. (US PGPUB 2017/0289060).
As for claim 1, Dawkins teaches a workload provisioning system (paragraph 155), comprising:
a plurality of resource devices (paragraph 45, “…any number of information handling systems…any number of external resources…”);
a client device (paragraph 28, “clients…may request that the computer implemented services be provided…”); and
a resource management system that is coupled to the client device and each of the plurality of resource devices (paragraph 146, in view paragraph 33), wherein the resource management system is configured to:
retrieve, from each of the plurality of resource devices, respective resource capability information (paragraph 41, 93, 152. “…provide telemetry data regarding the computing resources of an information handling system…manager …may monitor the utilization and/or health of computing resources for providing computer implemented services…” “…inventory the components of the information handling system…include….the type and model of each hardware component, versions of firmware or other code executing on the hardware components and/or information regarding hardware components of the information handling system that maybe allocated to form composed information handling systems…” and “aggregate this data in a telemetry data map …used to identify resources of any number of information handling systems and/or external resources to satisfy composition and/or recomposition requests….”) ;
receive, from the client device, a workload intent that requests performance of a workload and that includes at least one workload intent tag that defines a respective workload capability desired for the workload (paragraph 33, “…obtaining composition requests for composed information handling systems from...the clients…service the composition requests by ….in accordance with the requests…”, paragraph 95, “…using an intend based model…the resource requests may ….specify that a composed information handling system is to be instantiated having predetermined characteristics, ….perform certain workloads or execute certain applications…and/or ….be able to perform one or more predetermined functionalities…”);
identify, using the at least one workload intent tag and the respective resource capability information retrieved from each of the plurality of resource devices, a first subset of the plurality of resource devices that are configured to provide each of the respective workload capabilities defined by the at least one workload intent tag (paragraph 148, “….employ an intent based model that translates an intent expressed in a composition request to one or more allocation of computing resources….match an express intent to resources to be allocated to satisfy that intent…a lookup table may specify the type, quantity, method of management, and/or other information regarding any number of computing resources that when aggregated will be able to satisfy a corresponding intent…identify resources for allocation to satisfy composition requests ….” And paragraph 152, “…obtain telemetry data regarding the computing resources of any number of information handling systems and/or external resources that are available for allocation….aggregate this data in a telemetry data map which maybe subsequently used to identify resources of any number of information handling systems and/or external resources to satisfy composition and/or recomposition requests…”); and
configure the first subset of the plurality of resource devices to provide a logically composed system (LCS) [composed information handling system] that performs the workload (paragraph 20 “…computing resources from multiple information handling systems may be allocated to a composed information handling system thereby enabling a composed information handling system to utilize computing resources from any number of information handling system for performance of corresponding computer implemented services…”, paragraph 153, “communicate….to implement the identified allocation….for example…notify a system control processor of a control resource set that portions of a hardware resource set are to be allocated to a compute resource set to instantiate a composed information handling system…”, paragraphs 92 and 97, “…obtain composition/recomposition requests….based on…requests, prepare and present resources to the compute resource sets…instantiate applications in composed information handling systems…to provide services…” and “…in addition to specifying resource allocations, …..applications …hosted….security models …employed…place the composed information handling systems into states in which the composed information handling systems provide desired computer implemented services….”).
Dawkins does not explicitly teach retrieving a configuration template or filling the templates with resource capabilities retrieved from each of the subset of resource devices or to combine the first resource/workload configuration information to provide a first resource/workload configuration file and configure using the first resource/workload configuration file the first subset of the plurality of resource devices.
However, Aftab teaches a known method of request-driven provisioning of cloud/composable computing infrastructure including retrieve respective resource/workload configuration template (paragraph 25, “TOSCA service model…created from individual resources in a proprietary service design and creation tool…resources each have their own capabilities, requirements, properties, attributes and lifecycle management operations…the recipe for a service is created and sent to the MSO in the form of a TOSCA blueprint.”, and paragraph 66, “…re-uses…pre-defined resources, services, and products, described in TOSCA, from a service design and composition catalog 425 in order to construct a composite service/application…” Examiner note, as claimed in dependent claim 3, the template is provided as a TOSCA-based resource/workload recipe.);
fill, based on the respective resource capability information retrieved from each of the first subset of the plurality of resource devices, the respective resource/workload configuration template retrieved from each of the first subset of the plurality of resource devices to provide respective first resource/workload configuration information (paragraph 66, “…assigns deployment policies, such as healing and scaling policies and the configuration files for the application components – the TOSCA node types…” , paragraph 45, “…the artifacts include application topology (node properties plus dependency), scaling and healing policy and config files…packaged together in an archive file called a cloud service archive…” and paragraph 42-43, “….graph 200 …is used in representing application topology and dependency between components in a TOSCA template…nodes properties are stored in the dependency graph 200, and are represented in normal typeface….virtual machine…has a certain number of …CPUs….memory….attributes of each node are also stored in the dependency graph…IP addresses of the virtual machine…”);
combine the respective first resource/workload configuration information to provide a first resource/workload configuration file (paragraph 45, “…the artifacts are packaged together in an archive file called a Cloud Service Archive…” in view of paragraph 41, “…TOSCA template is packaged together in a zipped archive file called a Cloud Services Archive File…”); and
configure, using the first resource/workload configuration file, the first subset of the plurality of resource devices to provide a Logically Composed System (LCS) that performs the workload (paragraph 25, “…MSO is a TOSCA interpreter that parses the TOSCA specification and eventually instructs the controllers to perform their corresponding functions…include at least …creation of VMs by the infrastructure controller….creation of networks and subnets by the SDN controller….deployment and configuration of application components….” And paragraph 112, “…master service orchestrator then orchestrates …a cloud platform orchestrator, a software defined network controller and an application controller to create, install, connect, configure and start virtual service components and to bring the entire service to a state of operational readiness…”). This known technique is applicable to the system of Dawkins as they both share characteristics and capabilities, namely, they are directed to request-driven provisioning of cloud/composable computing infrastructure.
One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Aftab would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Aftab to the teachings of Dawkins would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such provisioning methods into similar systems. Further, applying retrieving a configuration template from each resource device or filling the templates with resource capabilities retrieved from each of the subset of resource devices or to combine the first resource/workload configuration information to provide a first resource/workload configuration file and configure using the first resource/workload configuration file the first subset of the plurality of resource devices to Dawkins with device sourced device related data and use of capability data of the nodes to determine allocation stored accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow deployment plan to better meet deployment requirements and deployed in a fast and automated manner with cost savings. (Aftab, paragraph 122).
As for claim 7 and 14, they contain similar limitations as claim 1 above. Thus, they are rejected under the same rationales.
In addition, Dawkin also teaches an information handling system, comprising: a processing system; and a memory system that is coupled to the processing system and that includes instructions that, when executed by the processing system cause the processing system to provide a resource management engine (Paragraph 155, and Fig. 3)
As for claim 2, Dawkins also teaches the respective resource capability information retrieved from each of the plurality of resource devices identifies functionality available from the operation of that resource device (paragraph 93, “…inventory the components….include the type and model of each hardware component, versions of firmware or other code….”)
Aftab also teaches the resource capability information retrieved identifies functionality dependencies required for the operation of that resource device, and is configured for use by the resource management system to identify software that enables the functionality available from the operation of that resource device according to the functionality dependencies required for the operation of that resource device.
(paragraph 13, “topology model describes the components of the application, and the relationship (or dependencies) between these components…” paragraph 25, “…the resources ….capabilities, requirements, properties, attributes and lifecycle management operations…” paragraph 89, “…downloads and installs the application components….from the appropriate …repositories…” As such, the prior art discloses capabilities/requirements are used to identify the software that enables the resource’s functionality in accordance with its dependencies.). Rationale to combine same as claim 1 above.
As for claim 8 and 15, they contain similar limitations as claim 2 above. Thus, they are rejected under the same rationales.
As for claim 3, Dawkins teaches resource/workload data from each of the plurality of resource devices (paragraph 41, 93, 152);
Aftab also teaches the respective resource/workload configuration template retrieved is provided by a Topology and Orchestration Specification for Cloud Applications (TOSCA)-based resource/workload template (paragraph 13, 25, and 66). Rationale to combine same as claim 1 above.
As for claim 9 and 16, they contain similar limitations as claim 3 above. Thus, they are rejected under the same rationales.
As for claim 4, Aftab also teaches deriving, based on the respective first resource capability information retrieved from each of the first subset of the plurality of resource devices, at least one software dependency for the first subset of the plurality of resource devices (paragraph 13, “…the topology model describes the components of the application, and the relationship (or dependencies) between those components, such as if one component depends upon the availability of another component, or is required to be hosted on another component…” and paragraph 106, “…APP-C retrieves the A-DG from the runtime inventory, in order to find the dependency between …components, which is used to determine the sequence in which the components are configured…”); and
filling the respective resource/workload configuration template retrieved from each of the first subset of the plurality of resource devices to provide respective first resource/workload configuration information that addresses the at least one software dependency (paragraph 74, “Configuration Files- are the configurations that are applied to the applications components after deployment and before startup”, and paragraph 90, “Set-up/configure the ports required by the application(s) that would run in the VM …required by the application/VNF to talk to the backend DB Server…”). Rationale to combine same as claim 1 above.
As for claim 10 and 17, they contain similar limitations as claim 4 above. Thus, they are rejected under the same rationales.
As for claim 5, Aftab also teaches validate, prior to configuring the first subset of the plurality of resource devices to provide the LCS that performs the workload, the resource/workload configuration file (paragraph 67, “The service designer…validates the composite design and produces a topology template of the composite service/application….” Paragraph 23, “…those tools include TOSCA editors and service composers and validators….”, and paragraph 74, “specifically after the completed design is validated and the necessary artifacts described above have been generated and stored….send the order ID of the completed/validated order to the OCX/OMX…” teaching before deploying, the system must validate the configuration to be deployed.).
As for claim 11 and 18, they contain similar limitations as claim 5 above. Thus, they are rejected under the same rationales.
As for claim 13, Dawkins also teaches identify, using the at least one workload intent tag and the respective resource capability information retrieved from each of the plurality of resource devices, a second subset of the plurality of resource devices that are configured to provide each of the respective workload capabilities defined by the at least one workload intent tag (paragraphs 34-35, “monitor…the states of computing resources allocated…determine …computing resources…should be … recomposed … identify replacement computing resources for all or a portion of the hardware devices providing the computing resources in the compromised state…” and paragraph 178, “….monitoring may indicate a compromised state…unlikely to provide computing resources to a composed information handling system, entirely or in part, in the future or currently…” teaching the identification of need to recompose based on capability information whether replacement resources are needed for the currently allocated computing resource, thus, in at least one embodiment, the recomposition and identification of second subset of resource devices are for the same workload as the first subset of plurality of resource devices, in view of paragraphs 33, 95 and 148 teaching workload requirements associated with workload intent tag.);
modify, based on the respective resource capability information retrieved from each of the second subset of the plurality of resource devices, resource assignment information from each of the second subset of the plurality of resource devices to provide respective second resource/workload configuration information (paragraph 200, “match maybe performed using, for example, a telemetry data map…”, paragraph 152, “for ….recomposition purposes, the infrastructure manager (4002) may obtain telemetry data regarding the computing resources of any number of information handling systems and/or external resources that are available for allocation…” and paragraph 149, “…recompose composed …system, the infrastructure manager (402) may add or remove resources from existing composed information handling system or instantiate new composed information handling systems and transfer…”);
configure, using the second resource/workload configuration, the second subset of the plurality of resource devices to provide the LCS that performs the workload (paragraph 152, “…identify resources of any number of information handling systems and/or external resources to satisfy…recomposition…modify resource allocations …”).
In addition, Aftab also teaches the respective resource/workload configuration template retrieved to provide respective second resource/workload configuration information (paragraph 25, “TOSCA service model…created from individual resources in a proprietary service design and creation tool…resources each have their own capabilities, requirements, properties, attributes and lifecycle management operations…the recipe for a service is created and sent to the MSO in the form of a TOSCA blueprint.”, and paragraph 66, “…re-uses…pre-defined resources, services, and products, described in TOSCA, from a service design and composition catalog 425 in order to construct a composite service/application…”);
combine the respective second resource/workload configuration information to provide a second resource/workload configuration file (paragraph 45, “…the artifacts are packaged together in an archive file called a Cloud Service Archive…” in view of paragraph 41, “…TOSCA template is packaged together in a zipped archive file called a Cloud Services Archive File…”); and
configure, using the second resource/workload configuration file, the second subset of the plurality of resource devices to provide the LCS that performs the workload (paragraph 25, “…MSO is a TOSCA interpreter that parses the TOSCA specification and eventually instructs the controllers to perform their corresponding functions…include at least …creation of VMs by the infrastructure controller….creation of networks and subnets by the SDN controller….deployment and configuration of application components….” And paragraph 112, “…master service orchestrator then orchestrates …a cloud platform orchestrator, a software defined network controller and an application controller to create, install, connect, configure and start virtual service components and to bring the entire service to a state of operational readiness…”). Rationale to combine same as claim 7 above.
As for claim 20, it contains similar limitations as claim 13 above. Thus, it is rejected under the same rationales.
Claims 6, 12 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Dawkins et al. (US PGPUB 2022/0179702), in view of Aftab et al. (US PGPUB 2017/0289060), further in view of Unknown Author (“Kubernetes – Labels and Selectors”, kubernetes.io/docs/concepts/overview/working-with-objects/labels/, retrieved via wayback machine, record dated Jun 3, 2023) (hereafter as “Kubernetes Labels”)
As for claim 6, Examiner note tagging of workloads and resources with hierarchical, readable attributes using Fully Qualified Domain Name, which is merely every label in the DNS hierarchy, from the specific host to the DNS root, is known and conventional practice that would be a simple substitution of one known, human-readable hierarchical naming convention for the tag syntax. Nevertheless, in the interest of compact prosecution, Dawkins and Aftab do not explicitly teach the at least one workload intent tag is provided in a fully qualified domain name format.
However, Kubernetes Labels teaches a known method of tagging deployment objects in a deployment environment including tagging the deployment object with a label using a Fully Qualified Domain Name (FQDN) format (Section – Syntax and character set, “…an optional prefix ….if specified, the prefix must be a DNS subdomain: a series of DNS labels separated by dots (.) …” – i.e., a name in FQDN format. See Examiner search result on “what is FQDN”, searched on 9/22/2026, results limited to before 6/1/2024, teaching it is well known in the art that FQDN can be the address of an internet host or computer. Here, Label Selectors identifies a set of objects carrying a tag where one use case is to constrain the set of nodes onto which a pod can schedule. See, e.g., Section – Selecting sets of nodes.). This known technique is applicable to the system of Dawkins and Aftab as they both share characteristics and capabilities, namely, they are directed to deployment of objects to a provisioning/deployment system in networked environment .
One of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique of Kubernetes Labels would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Kubernetes Labels to the teachings of Dawkins and Aftab would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such object deployment features into similar systems. Further, applying tagging the deployment object with a label using a Fully Qualified Domain Name (FQDN) format to Dawkins and Aftab with intent tag stored accordingly, would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow efficient queries of the resource/workload objects. (Kubernetes Labels, Pg. 1).
Claims 12 and 19 contain similar limitations as claim 6 above. Thus, they are rejected under the same rationales..
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KEVIN X LU whose telephone number is (571)270-1233. The examiner can normally be reached M-F 10am-6pm.
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, Lewis Bullock can be reached on 5712723759. 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.
/KEVIN X LU/Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
