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 .
This Office Action is in response to claims filed 8/7/2023.
Claims 1-20 are pending.
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Nadar et al. US 20180316552 A1 in view of Fildebrandt et al. US 20180032329 A1.
Regarding claim 1, Nadar teaches the invention substantially as claimed including:
A computer-implemented method for capability orchestration in a cloud-native environment ([0033] Techniques described herein provide a provisioning framework through which cloud services may be flexibly defined, updated, and deployed. In one or more embodiments, the provisioning framework defines cloud services using service schematics. A service schematic represents a blueprint for one or more versions of a cloud service), comprising:
generating, by one or more processing units, one or more new combined capability definitions (Fig 2 and 3; [0063] FIG. 2 illustrates an example set of operations for generating a cloud service schematic), based on existing capability definitions and a combined capability manifest ([0035] a service schematic defines associations for one or more versions of a cloud service. An association in this context refers to a relationship between the cloud service that is the subject of the service blueprint (herein referred to as the “primary service”) and another cloud service (herein referred to as a “secondary service”). The service schematic may associate the primary cloud service with one or more secondary services),
receiving, by the one or more processing units, a capability request directed to one or more capabilities, wherein the one or more capabilities correspond to one or more capability definitions in the hierarchy of capability definitions ([0052] Service schematic editor 132 may save service schematics for one or more cloud services in data repository 120; [0087] The compilation process may be triggered upon request by a user. In response, the service schematic compiler may be invoked to compile the service schematic that the user is currently viewing (e.g., via a GUI). In other cases, the compiler may be invoked automatically in response to a triggering event, such as detecting that a service schematic has been updated or that resources in a cloud environment have changed; Examiner notes: users are able to request capabilities by updating old/creating new service schematics in saved service schematics which declare services to include upon provisioning);
determining, by the one or more processing units, the one or more capability definitions corresponding to the one or more capabilities from the hierarchy of capability definitions based on the capability request ([0052] Service schematic editor 132 may save service schematics for one or more cloud services in data repository 120; [0087] a user may submit a request that a service schematic be compiled from a service schematic editor. In response, the service schematic compiler may be invoked to compile the service schematic that the user is currently viewing (e.g., via a GUI); See also Fig 6 Process; Examiner notes: the user may determine a service schematic representing requested capabilities to request out of stored service schematics via the GUI);
deriving, by the one or more processing units, deployable resources based on the determined one or more capability definitions ([0088] During the compilation process, service schematic compiler 132 parses the service schematic to identify resource dependencies and associations defined therein (Operation 420) … Service schematic compiler 132 may parse schematic element 308 to identify the resource dependencies and associated parameters, if any. Service schematic compiler 132 may parse schematic element 310 to identify if the cloud resource is compatible with any secondary service.; See also Fig 6 Process); and
generating, by the one or more processing units, the one or more capabilities based on the derived deployable resources ([0089] Based on the dependencies and/or associations identified from the service schematic, service schematic compiler 132 generates a set of one or more configuration files for provisioning cloud resources 102 (Operation 430); [0106] During a provisioning operation, provisioning engine 133 may execute a configuration file generated by service schematic compiler 132 to configure a VM for a tenant; [0107] Topology information may be captured by a service schematic and included in the compiled configuration files. During provisioning, provisioning engine 133 may connect interdependent cloud resources based on the configuration files; See also Fig 6 Process).
While Nadar discloses there being multiple service schematics saved at once [0052], Nadar does not explicitly teach the schematics are generated to form a hierarchy of capability definitions including the one or more new combined capability definitions and the existing capability definitions.
However, Fildebrandt teaches to form a hierarchy of capability definitions including the one or more new combined capability definitions and the existing capability definitions (Fig 1A; [0004] FIG. 1A illustrates an example of hierarchical information for specifying a customized runtime environment; [0018] a profile, such as a cloud integration profile 104-1, a financial services network (FSN) profile 104-N, and the like (collectively known as profiles 104 herein), specify the capabilities utilized by the corresponding user service, use case, and the like. The profiles 104 may be defined in an XML file. Each profile 104 may identify, for example, a number of capabilities (e.g., capability files) where each capability specifies the runtime bundle(s) needed to implement the corresponding capability/capabilities);
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Fildebrandt’s hierarchy profiles including multiple capabilities with the existing system. A person of ordinary skill in the art would have been motivated to make this combination to provide the resulting system with the advantage of providing cloud users with capability customization as well as reducing unnecessary resource use (see Fildebrandt [0015] Different users, however, may have different processing requirements; each individual user does not typically need the full set of functionality, and therefore does not need the full runtime stack. Thus, use of the full runtime stack may waste processing resources and storage resources, and may lead to excessive startup times for the runtime environment. This may be especially pronounced in cloud environments where the costs for hardware and resource consumption should be minimized to provide a cost-effective environment.).
Regarding claim 2, Nadar and Fildebrandt teach the computer-implemented method of claim 1.
Nadar further teaches the combined capability manifest comprises a list of capabilities to be combined, together with a version constraint for one or more of the capabilities to be combined and dependencies among the capabilities to be combined (Fig 3 schematic definitions with versioning and multiple resource/capability dependencies); and
the generating the one or more new combined capability definitions takes one or more of the version constraint and the dependencies into consideration ([0033] A service schematic represents a blueprint for one or more versions of a cloud service; [0034] resource dependencies are captured by service schematics).
Regarding claim 3, Nadar and Fildebrandt teach the computer-implemented method of claim 1.
Nadar further teaches each capability definition in the hierarchy of capability definitions defines a set of deployable resources for a corresponding capability ([0035] a service schematic defines associations for one or more versions of a cloud service. An association in this context refers to a relationship between the cloud service that is the subject of the service blueprint (herein referred to as the “primary service”) and another cloud service (herein referred to as a “secondary service”). The service schematic may associate the primary cloud service with one or more secondary services. For example, a platform as a service (PaaS) may be compatible with other cloud services, including, but not limited to, software as a service (SaaS), middleware as a service (MWaaS), and/or database as a service (DBaaS) instances), together with readiness of one or more deployable resources in the set of deployable resources and dependencies between two or more deployable resources in the set of deployable resources ([0034] resource dependencies are captured by service schematics. During provisioning, resources are allocated based, in part on the resource dependencies defined in the service schematic. If the schematic indicates that the cloud resource is dependent on a particular application, for instance, then an instance of the application may be assigned to a particular tenant to handle incoming requests. Additionally or alternatively, other types of resources may be provisioned for an instance of the cloud service in accordance with the service schematic; [0035] During provisioning, resources may be allocated based on the availability of the secondary services. If a secondary service is available, then a provisioning engine may bind the secondary service to the primary service such that the secondary service is integrated into an instance of the primary service. If the secondary service is unavailable (e.g., the tenant has not subscribed or otherwise does not have access to the secondary service), then the provisioning engine may proceed without binding the secondary service).
Regarding claim 4, Nadar and Fildebrandt teach the computer-implemented method of claim 3.
Nadar further teaches wherein the deriving the deployable resources is conducted in an order based on the readiness and the dependencies ([0088] During the compilation process, service schematic compiler 132 parses the service schematic to identify resource dependencies and associations defined therein (Operation 420). In the context of an XML schematic, for example, service schematic compiler 132 may comprise an XML parser for identifying schematic elements (e.g., schematic elements 308 and 310), corresponding to dependency and association definitions. Service schematic compiler 132 may parse schematic element 308 to identify the resource dependencies and associated parameters, if any. Service schematic compiler 132 may parse schematic element 310 to identify if the cloud resource is compatible with any secondary service.).
Regarding claim 5, Nadar and Fildebrandt teach the computer-implemented method of claim 1.
Nadar further teaches one or more capability definitions in the hierarchy of capability definitions define one or more parameters to be customized ([0033] A service schematic may define a cloud service in a manner that is decoupled from environment-specific parameters, which may vary between different cloud environments; [0060] Service schematics 121 may be ported to a different environment where one or more of these resources (e.g., host operating systems, storage servers, etc. may be from different providers and configured differently). Service schematics 121 may be used to provision cloud service instances (e.g., PaaS instances, DBaaS instances) in the new environment even though the set of cloud resources may not completely overlap; [0063] A global service attribute is a property or parameter of a service that is independent of and applicable to all versions of a service. Example global service attributes may include, but are not limited to (a) a name and/or unique identifier for the cloud service;” (b) an indication of whether the service is managed (e.g., the cloud provider maintains software resources) or unmanaged (e.g., the tenant is responsible for maintaining software resources; and (c) high-level parameter declarations (e.g., declarations of services and/or other resources that may be integrated into the primary cloud service)); and
the capability request comprises one or more values for instantiation of the one or more parameters ([0087] a user may submit a request that a service schematic be compiled from a service schematic editor. In response, the service schematic compiler may be invoked to compile the service schematic that the user is currently viewing (e.g., via a GUI); [0088] Service schematic compiler 132 may parse schematic element 308 to identify the resource dependencies and associated parameters, if any; Examiner notes: parameters may be edited in service schematic editor 131 [0052]).
Regarding claim 6, Nadar and Fildebrandt teach the computer-implemented method of claim 1.
Nadar further teaches wherein the existing capability definitions comprises one or more primary capability definitions (Fig 3 dependencies; [0072] Schematic element 308 may be used to define resource dependencies associated with the base version of a cloud service (e.g., “Version 1.1”) Each dependency is defined by a resource type (e.g., <resource type=“Java Cloud Service (JCS)”>, <resource type=“Database Server”> etc.)) and one or more existing combined capability definitions ([0036] Service schematics may define multiple versions of a cloud service. For example, a service schematic may define a base version of a cloud service that includes a base set of resource dependencies and/or associations. The service schematic may further define additional versions (herein referred to as “derived versions”) of the service with different resource dependencies and/or associations. A derived version may (a) add, (b) replace, and/or (c) otherwise modify resource dependencies and/or associations of other versions of the cloud service, including the base version and other derived versions).
Regarding claim 7, Nadar and Fildebrandt teach the computer-implemented method of claim 6.
Nadar further teaches wherein primary capabilities corresponding to the primary capability definitions are from at least one of a same cloud-native application and different cloud-native applications ([0035] An association in this context refers to a relationship between the cloud service that is the subject of the service blueprint (herein referred to as the “primary service”) and another cloud service (herein referred to as a “secondary service”). The service schematic may associate the primary cloud service with one or more secondary services. For example, a platform as a service (PaaS) may be compatible with other cloud services, including, but not limited to, software as a service (SaaS), middleware as a service (MWaaS), and/or database as a service (DBaaS) instances; [0048] Binding interfaces 112 integrate secondary services 104 with cloud services instances 110. For example, a tenant of a PaaS may wish to connect the PaaS instance with an SaaS and/or a DBaaS from another provider rather than developing a similar application directly in the cloud environment).
Regarding claim 8, Nadar and Fildebrandt teach the computer-implemented method of claim 1.
Nadar further teaches wherein the capability definitions are written in a markup language ([0061] service schematics 121 define cloud services using a declarative syntax. The declarative syntax that is used may describe what resources should be allocated for an instance of a cloud service but may not describe how to allocate the resources. Example declarative languages include, but are not limited to, the extensible markup language (XML) and JavaScript Object Notation (JSON). By using a declarative syntax, the determination of how resources are allocated may be left to provisioning engines executing in different environments).
Regarding claim 9, Nadar and Fildebrandt teach the computer-implemented method of claim 1.
Nadar further teaches wherein the generated one or more capabilities form a cloud-native application ([0033] A service schematic represents a blueprint for one or more versions of a cloud service).
Regarding claims 10-18, they are the systems of claims 1-9 respectively. Therefore, they are rejected for the same reasons as claims 1-9 respectively.
Regarding claims 19-20 they are the computer program product of claims 1-2 respectively. Therefore, they are rejected for the same reasons as claims 1-2 respectively.
Nadar further teaches a computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a processor to cause the processor to ([0141] Such instructions may be read into main memory 1006 from another storage medium, such as storage device 1010. Execution of the sequences of instructions contained in main memory 1006 causes processor 1004 to perform the process steps described herein).
Conclusion
Any inquiry concerning this communication or earlier communications from the
examiner should be directed to HARRISON LI whose telephone number is (703) 756-1469. The
examiner can normally be reached Monday-Friday 9:00am-5:30pm ET.
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, Aimee Li can be reached on (571) 272-4169. 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.
/H.L./
Examiner, Art Unit 2195
/PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198
Prosecution Insights