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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on May 18, 2023 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Drawings
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(4) because:
Reference character “202” has been used to designate both “IDEM service circuitry” and “example bus”.
Reference character “304” has been used to designate both “block” and “message queue”.
Reference character “310” has been used to designate both “block” and “cloud provider”.
Reference character “324” has been used to designate both “block” and “EBS”.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(5) because they include the following reference character(s) not mentioned in the description: “508”. Corrected drawing sheets in compliance with 37 CFR 1.121(d), or amendment to the specification to add the reference character(s) in the description in compliance with 37 CFR 1.121(b) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
The disclosure is objected to because of the following informalities:
Reference character “304” in paragraph [0070] and [0071] designates “first plugin” which is not supported by the drawings.
Reference character “306” in paragraph [0070] and [0071] designates “second plugin” and “third plugin” which is not supported by the drawings.
Appropriate correction is required.
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Claim Objections
Claims 16-20 are objected to under 37 CFR 1.75 as being a substantial duplicate of claims 2-6, respectively. When two claims in an application are duplicates or else are so close in content that they both cover the same thing, despite a slight difference in wording, it is proper after allowing one claim to object to the other as being a substantial duplicate of the allowed claim. See MPEP § 608.01(m).
Claims 2, 6, 9, 13, 16, and 20 are objected to because of the following informalities:
First occurrence (“API”) in the claims should be spelled out (--application programming interface (API)--).
Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claims 1-7 and 16-20 are directed to a machine, claims 8-14 are directed to an article of manufacture, and claims 15 is directed to a process.
Claim 1, 8, and 15 recite:
retrieve metadata associated with a plugin for a cloud resource platform, the plugin to provide a capability to provision a cloud resource of the cloud resource platform;
perform a first transformation of the metadata from a first format associated with the plugin to a second format associated with a blueprint service;
register the capability into the blueprint service;
generate a blueprint including instructions to provision the cloud resource;
transform the blueprint from the second format to a third format, the third format at least partially defined by the first format; and
provision the cloud resource based on the transformed blueprint.
Step 2A, Prong I: Does the claim recite an abstract idea, law of nature, or natural phenomenon?
Yes, abstract ideas.
The “transform” limitations above, as claimed and under broadest reasonable interpretation (BRI), are mental processes that covers performance of the limitation in the mind. For example, “transform” in the context of this claim encompasses the person making an evaluation.
The “generate” limitation above, as claimed and under broadest reasonable interpretation (BRI), is a mental process that covers performance of the limitation in the mind. For example, “generate” in the context of this claim encompasses the person making an evaluation.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The “retrieve” limitation above, as claimed and under (BRI), is an additional element that is insignificant extra-solution activity. For example, “retrieve” in the context of this claim encompasses mere data gathering. See MPEP 2106.05(g).
The “register” limitation above, as claimed and under (BRI), is an additional element that is insignificant extra-solution activity. For example, “register” in the context of this claim encompasses storing data. See MPEP 2106.05(g).
The “provision” limitation above, as claimed and under BRI, is an additional element that is mere instructions to apply an exception. For example, “provision” in the context of this claim encompasses provisioning the cloud resources as a result of the transformation. See MPEP 2106.05(f).
Additionally, one or more of the claims recite the following additional elements:
interface circuitry (claim 1)
programmable circuity (claims 1 and 8)
instructions (claims 1 and 8)
a non-transitory computer readable storage medium
an instruction (claim 15)
processor circuitry (claim 15)
the metadata (claims 1, 8, and 15)
the plugin (claims 1, 8, and 15)
the cloud resource (claims 1, 8, and 15)
These additional elements are recited at a high level of generality (i.e., as generic computer components) such that they amount to no more than linking the judicial exception to a technological environment. Accordingly, these additional elements do not integrate the abstract idea(s) into a practical application because they do not impose any meaningful limits on practicing the abstract idea(s).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
With regard to the “retrieve” limitation above, per MPEP 2106.05(d)(II), the courts have recognized the following computer function as well-understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity:
i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) ("Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result‐‐a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink." (emphasis added)).
With regard to the “register” limitation above, per MPEP 2106.05(d)(II), the courts have recognized the following computer function as well-understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity:
iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93.
With regard to the “provision” limitation above, per MPEP 2106.05(f)(1) the recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not integrate a judicial exception into a practical application or provide significantly more because this type of recitation is equivalent to the words "apply it".
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than employing generic computer functions to execute an abstract idea, even when limiting the use of the idea to one particular environment. Mere linking the judicial exception to a technological environment using generic computer components cannot provide an inventive concept.
Claims 2, 9, and 16 recite:
wherein the programmable circuitry is to retrieve the metadata via an API call at periodic intervals to obtain new versions of the plugin.
Step 2A, Prong I: Does the claim recite an abstract idea, law of nature, or natural phenomenon?
Yes, the abstract ideas of claims 1, 8, and 1, respectively.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The “retrieve” limitation above, as claimed and under (BRI), is an additional element that is insignificant extra-solution activity. For example, “retrieve” in the context of this claim encompasses mere data gathering. See MPEP 2106.05(g).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
With regard to the “retrieve” limitation above, per MPEP 2106.05(d)(II), the courts have recognized the following computer function as well-understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity:
i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) ("Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result‐‐a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink." (emphasis added)).
Claims 3, 10, and 17 recite:
wherein the first transformation is a javascript object notation (JSON) to JSON transformation.
Step 2A, Prong I: Does the claim recite an abstract idea, law of nature, or natural phenomenon?
Yes, the abstract ideas of claims 1, 8, and 1, respectively.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
One or more of the claims recite the following additional elements:
a javascript object notation (JSON)
These additional elements are recited at a high level of generality (i.e., as generic computer components) such that they amount to no more than linking the judicial exception to a technological environment. Accordingly, these additional elements do not integrate the abstract idea(s) into a practical application because they do not impose any meaningful limits on practicing the abstract idea(s).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than employing generic computer functions to execute an abstract idea, even when limiting the use of the idea to one particular environment. Mere linking the judicial exception to a technological environment using generic computer components cannot provide an inventive concept.
Claims 4, 11, and 18 recite:
wherein the cloud resource appears in a graphical blueprint canvas that allows for drag and drop creation of the blueprint.
Step 2A, Prong I: Does the claim recite an abstract idea, law of nature, or natural phenomenon?
Yes, the abstract ideas of claims 1, 8, and 1, respectively.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The limitation above further describes the technological environment of the limitations from claims 1, 8, and 1, respectively. “Limitations that amount to merely indicating a field of use or technological environment in which to apply a judicial exception do not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application.” See MPEP 2106.05(h).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
The limitation above further describes the technological environment of the limitations from claims 1, 8, and 1, respectively. “Limitations that amount to merely indicating a field of use or technological environment in which to apply a judicial exception do not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application.” See MPEP 2106.05(h).
Claims 5, 12, and 19 recite:
wherein the programmable circuitry is to receive a provisioning request from the blueprint service to provision the cloud resource.
Step 2A, Prong I: Does the claim recite an abstract idea, law of nature, or natural phenomenon?
Yes, the abstract ideas of claims 1, 8, and 1, respectively.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The “receive” limitation above, as claimed and under (BRI), is an additional element that is insignificant extra-solution activity. For example, “receive” in the context of this claim encompasses receiving a request. See MPEP 2106.05(g).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
With regard to the “receive” limitation above, receiving a request is well-understood, routine, and conventional in the art to as taught by Jain (U.S. Patent Application Publication No. US 20210243191 A1) “Conventional resource distribution processing systems receive requests for resource distribution”, [para 0051].
Claims 6, 13, and 20 recite:
wherein the programmable circuitry is to expose an API for entry of new resource capabilities in the first format.
Step 2A, Prong I: Does the claim recite an abstract idea, law of nature, or natural phenomenon?
Yes, the abstract ideas of claims 1, 8, and 1, respectively.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
The “expose” limitation above, as claimed and under (BRI), is an additional element that is insignificant extra-solution activity. For example, “expose” in the context of this claim encompasses making an API available. See MPEP 2106.05(g).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
With regard to the “expose” limitation above, making an API available is well-understood, routine, and conventional in the art to as taught by Johnson (U.S. Patent Application Publication No. US 20100273610 A1) “conventional application programming interfaces (APIs) used to detect and process input from input devices”, [para 0089].
Claims 7 and 14 recite:
wherein the metadata includes a schema for the cloud resource.
Step 2A, Prong I: Does the claim recite an abstract idea, law of nature, or natural phenomenon?
Yes, the abstract ideas of claims 1, 8, and 1, respectively.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
One or more of the claims recite the following additional elements:
the metadata (claims 7 and 14)
a schema (claims 7 and 14)
the cloud resource (claims 7 and 14)
These additional elements are recited at a high level of generality (i.e., as generic computer components) such that they amount to no more than linking the judicial exception to a technological environment. Accordingly, these additional elements do not integrate the abstract idea(s) into a practical application because they do not impose any meaningful limits on practicing the abstract idea(s).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
As discussed above with respect to integration of the abstract idea(s) into a practical application, the aforementioned additional elements amount to no more than employing generic computer functions to execute an abstract idea, even when limiting the use of the idea to one particular environment. Mere linking the judicial exception to a technological environment using generic computer components cannot provide an inventive concept.
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.
Claims 1, 5, 6, 7, 8, 12, 13, 14, 15, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Asthana et al. ("A declarative approach for service enablement on hybrid cloud orchestration engines," NOMS 2018 - 2018 IEEE/IFIP Network Operations and Management Symposium, hereinafter “Asthana”) in view of Asthana et al (U.S. Patent Application Publication No. US 20190122156 A1, hereinafter “Asthana ‘156”), and Ferguson et al. ("Service-oriented architecture: Programming model and product architecture," in IBM Systems Journal, hereinafter “Ferguson”).
With regard to claim 1, Asthana discloses:
retrieve metadata associated with a plugin for a cloud resource platform (“The metadata within the Service Registry details the catalog of service templates available for consumption. The Service Registry exposes a user interface and a rich API for creating, reading, updating, and deleting the metadata.”, page 3, right column, para 1, “The Plugin Code Generator builds plugins from service metadata modeled in the Service Registry.”, page 3, right column, para 2), the plugin to provide a capability to provision a cloud resource of the cloud resource platform (“The plugin implementation performs the actions for creating, configuring, destroying, and importing resources.”, page 3, left column, para 2, “The Plugin Code Generator leverages metadata from the Service Registry to dynamically build plugins for extensible Orchestration Engines.”, page 1, right column, para 1);
register the capability into the blueprint service (“A Service Registry is a repository that is populated with metadata that represents Providers, ServiceTypes, ResourceTypes, and Actions defined in our data model, described in Section V. The metadata within the Service Registry details the catalog of service templates available for consumption. The Service Registry exposes a user interface and a rich API for creating, reading, updating, and deleting the metadata. Service providers are able to on-board, modify, and delete managed services’ definitions on the platform for a wide range of public and private cloud offerings. Our implementation persists the metadata inside of a graph database which was chosen because of the inherent connections between services, resources, and actions. The Service Registry also introspects Swagger specifications and dynamically populates API actions into the repository for simplified service authoring.”, page 3, right column, para 1);
generate a blueprint including instructions to provision the cloud resource (“After plugins are built and deployed to an extensible Orchestration Engine, blueprints can be authored with managed services.”, page 3, right column, para 3, “representing managed services as code within reusable blueprints in order to accelerate service deployments and ease management activities”, page 1, left column, abstract, “Blueprints have the following characteristics and benefits: Defines one or more resource(s). Creation of a resource instance is handled by an Orchestration Engine plugin. Defines the relationships and dependencies between the resources specified in the blueprint, ensuring that resources are created in the correct order. Each named resource in the blueprint has its property values explicitly set to a value or implicitly set via a reference to a property from a different named resource in the blueprint or implicitly set in the blueprint via a reference to an input parameter.”, page 2, right column, para 2);
provision the cloud resource based on the transformed blueprint (“An Orchestration Engine creates, configures, and destroys resources declared in a blueprint. An Orchestration Engine interprets a blueprint and automatically determines resource dependencies within a blueprint. Based on resource dependencies, the engine automatically establishes optimal execution paths for the instantiation of the described workload.”, page 2, right column, para 5).
Asthana does not disclose:
A system comprising:
interface circuitry;
programmable circuitry; and
instructions to program the programmable circuitry to
perform a first transformation of the metadata from a first format associated with the plugin to a second format associated with a blueprint service;
transform the blueprint from the second format to a third format, the third format at least partially defined by the first format.
However, Asthana ‘156 discloses:
A system (“systems and methods of assigning computing resources of a cloud by an orchestration engine”, para [0019]) comprising:
interface circuitry (“a communication interface 816”, para [0089]);
programmable circuitry (“a central processing unit (CPU) 804”, para [0089]); and
instructions to program the programmable circuitry to (“instructions that, when executed by one or more processors”, para [0057]):
Both the systems of Asthana and Asthana ‘156 deal with resource provisioning. It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine Asthana in view of Asthana ‘156 to automate resource distribution.
Ferguson discloses:
transform the metadata from a first format associated with the plugin to a second format associated with a blueprint service (“Calls the transformation artifact, for example, a generated Java transformation class, to convert from the XML input message to the back-end system’s binary format, for example, a byte array overlay for a C structure”, page 8, left column, para 3. Examiner’s note: Blueprint service is interpreted as “Additionally or alternatively, the blueprint service circuitry 206 may be instantiated by any other combination of hardware, software, and/or firmware.”, para [0060]. Plugin is interpreted as “a plugin (e.g., a data file, an Idem doc file, etc.)”, para [0028].);
transform the blueprint from the second format to a third format, the third format at least partially defined by the first format (“invokes a transformation artifact to convert from the back-end message format to the XML (or Java) format”, page 8, left column, page 3); and
Both the systems of Asthana and Ferguson deal with templates. It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine Asthana in view of Ferguson to increase interoperability, “The main benefits are interoperability and simplification.” (Ferguson, page 20, right column, paragraph 4).
With regard to claim 5, Asthana as modified discloses the system of claim 1.
Asthana does not disclose however, Asthana ‘156 discloses:
wherein the programmable circuitry is to receive a provisioning request from the blueprint service to provision the cloud resource (“A computing device (e.g., 102(1)) provides a workload request 103(1), sometimes referred to herein as a business request, to the orchestration engine 103, which is a software program running on the orchestration server 116. Each workload includes a blueprint, which is a declarative representation of the workload that is both human and machine readable. It describes the relevant resources and the properties thereof. Blueprints provide an architectural overview of a platform that is later virtualized on the cloud by way of the orchestration engine 103. For example, a blueprint allows the specification of desired resources, without the requirement of detailed programming commands that describe the creation of those resources.”, para [0026], “FIG. 8 illustrates a network or host computer platform 800, as may be used to implement a server, such as the orchestration server 116 of FIG. 1.”, para [0088]. “The computer platform 800 may include a central processing unit (CPU) 804, a hard disk drive (HDD) 806, random access memory (RAM) and/or read only memory (ROM) 808, a keyboard 810, a mouse 812, a display 814, and a communication interface 816, which are connected to a system bus 802.”, para [0089], fig 1, fig 8. Examiner’s note: Blueprint service is interpreted as “Additionally or alternatively, the blueprint service circuitry 206 may be instantiated by any other combination of hardware, software, and/or firmware.”, para [0060].)
Both the systems of Asthana and Asthana ‘156 deal with resource provisioning. It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine Asthana as modified in view of Asthana ‘156 to automate provisioning resources.
With regard to claim 6, Asthana as modified discloses the system of claim 1.
Asthana further discloses:
wherein (“The Service Registry exposes a user interface and a rich API for creating, reading, updating, and deleting the metadata.”, page 3, right column, para 1).
Asthana does not disclose however, Asthana ‘156 discloses:
the programmable circuitry (“instructions that, when executed by one or more processors”, para [0057])
Both the systems of Asthana and Asthana ‘156 deal with resource provisioning. It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine Asthana in view of Asthana ‘156 to automate resource distribution.
With regard to claim 7, Asthana as modified discloses the system of claim 1.
Asthana further discloses:
wherein the metadata includes a schema for the cloud resource (“Our data model is a domain specific representation of service metadata.”, page 4, left column, para 2, “ResourceType is a uniquely named entity for a resource representation. Each ResourceType describes a component that may be instantiated from an Orchestration Engine blueprint and viewed from an instance management portal. Each Re-sourceType has a single ResourceSchema and defines multiple ResourceActions.”, page 4, right column, para 2).
With regard to claim 8, Asthana discloses:
retrieve metadata associated with a plugin for a cloud resource platform (“The metadata within the Service Registry details the catalog of service templates available for consumption. The Service Registry exposes a user interface and a rich API for creating, reading, updating, and deleting the metadata.”, page 3, right column, para 1, “The Plugin Code Generator builds plugins from service metadata modeled in the Service Registry.”, page 3, right column, para 2), the plugin to provide a capability to provision a cloud resource of the cloud resource platform (“The plugin implementation performs the actions for creating, configuring, destroying, and importing resources.”, page 3, left column, para 2, “The Plugin Code Generator leverages metadata from the Service Registry to dynamically build plugins for extensible Orchestration Engines.”, page 1, right column, para 1);
register the capability into the blueprint service (“A Service Registry is a repository that is populated with metadata that represents Providers, ServiceTypes, ResourceTypes, and Actions defined in our data model, described in Section V. The metadata within the Service Registry details the catalog of service templates available for consumption. The Service Registry exposes a user interface and a rich API for creating, reading, updating, and deleting the metadata. Service providers are able to on-board, modify, and delete managed services’ definitions on the platform for a wide range of public and private cloud offerings. Our implementation persists the metadata inside of a graph database which was chosen because of the inherent connections between services, resources, and actions. The Service Registry also introspects Swagger specifications and dynamically populates API actions into the repository for simplified service authoring.”, page 3, right column, para 1);
generate a blueprint including instructions to provision the cloud resource (“After plugins are built and deployed to an extensible Orchestration Engine, blueprints can be authored with managed services.”, page 3, right column, para 3, “representing managed services as code within reusable blueprints in order to accelerate service deployments and ease management activities”, page 1, left column, abstract, “Blueprints have the following characteristics and benefits: Defines one or more resource(s). Creation of a resource instance is handled by an Orchestration Engine plugin. Defines the relationships and dependencies between the resources specified in the blueprint, ensuring that resources are created in the correct order. Each named resource in the blueprint has its property values explicitly set to a value or implicitly set via a reference to a property from a different named resource in the blueprint or implicitly set in the blueprint via a reference to an input parameter.”, page 2, right column, para 2);
provision the cloud resource based on the transformed blueprint (“An Orchestration Engine creates, configures, and destroys resources declared in a blueprint. An Orchestration Engine interprets a blueprint and automatically determines resource dependencies within a blueprint. Based on resource dependencies, the engine automatically establishes optimal execution paths for the instantiation of the described workload.”, page 2, right column, para 5).
Asthana does not disclose:
A non-transitory computer readable storage medium comprising instructions which, when executed by programmable circuitry, cause the programmable circuitry to:
perform a first transformation of the metadata from a first format associated with the plugin to a second format associated with a blueprint service;
transform the blueprint from the second format to a third format, the third format at least partially defined by the first format.
However, Asthana ‘156 discloses:
A non-transitory computer readable storage medium comprising instructions (“a non-transitory computer readable storage medium”, para [0004], “computer readable program instructions may also be stored in a computer readable storage medium”, para [0104]) which, when executed by programmable circuitry, cause the programmable circuitry (“instructions that, when executed by one or more processors, perform the recited operations”, para [0057]) to:
Both the systems of Asthana and Asthana ‘156 deal with resource provisioning. It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine Asthana in view of Asthana ‘156 to automate resource distribution.
Ferguson discloses:
transform the metadata from a first format associated with the plugin to a second format associated with a blueprint service (“Calls the transformation artifact, for example, a generated Java transformation class, to convert from the XML input message to the back-end system’s binary format, for example, a byte array overlay for a C structure”, page 8, left column, para 3. Examiner’s note: Blueprint service is interpreted as “Additionally or alternatively, the blueprint service circuitry 206 may be instantiated by any other combination of hardware, software, and/or firmware.”, para [0060]. Plugin is interpreted as “a plugin (e.g., a data file, an Idem doc file, etc.)”, para [0028].);
transform the blueprint from the second format to a third format, the third format at least partially defined by the first format (“invokes a transformation artifact to convert from the back-end message format to the XML (or Java) format”, page 8, left column, page 3); and
Both the systems of Asthana and Ferguson deal with templates. It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine Asthana view of Ferguson to increase interoperability, “The main benefits are interoperability and simplification.” (Ferguson, page 20, right column, paragraph 4).
With regard to claim 12, Asthana as modified discloses non-transitory computer readable storage medium of claim 8.
Asthana does not disclose however, Asthana ‘156 discloses:
wherein the programmable circuitry is to receive a provisioning request from the blueprint service to provision the cloud resource (“A computing device (e.g., 102(1)) provides a workload request 103(1), sometimes referred to herein as a business request, to the orchestration engine 103, which is a software program running on the orchestration server 116. Each workload includes a blueprint, which is a declarative representation of the workload that is both human and machine readable. It describes the relevant resources and the properties thereof. Blueprints provide an architectural overview of a platform that is later virtualized on the cloud by way of the orchestration engine 103. For example, a blueprint allows the specification of desired resources, without the requirement of detailed programming commands that describe the creation of those resources.”, para [0026], “FIG. 8 illustrates a network or host computer platform 800, as may be used to implement a server, such as the orchestration server 116 of FIG. 1.”, para [0088]. “The computer platform 800 may include a central processing unit (CPU) 804, a hard disk drive (HDD) 806, random access memory (RAM) and/or read only memory (ROM) 808, a keyboard 810, a mouse 812, a display 814, and a communication interface 816, which are connected to a system bus 802.”, para [0089], fig 1, fig 8. Examiner’s note: Blueprint service is interpreted as “Additionally or alternatively, the blueprint service circuitry 206 may be instantiated by any other combination of hardware, software, and/or firmware.”, para [0060].)
Both the systems of Asthana and Asthana ‘156 deal with resource provisioning. It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine Asthana as modified in view of Asthana ‘156 to automate provisioning resources.
With regard to claim 13, Asthana as modified discloses non-transitory computer readable storage medium of claim 8.
Asthana further discloses:
wherein (“The Service Registry exposes a user interface and a rich API for creating, reading, updating, and deleting the metadata.”, page 3, right column, para 1).
Asthana does not disclose however, Asthana ‘156 discloses:
the programmable circuitry (“instructions that, when executed by one or more processors”, para [0057])
Both the systems of Asthana and Asthana ‘156 deal with resource provisioning. It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine Asthana in view of Asthana ‘156 to automate resource distribution.
With regard to claim 14, Asthana as modified discloses the non-transitory computer readable storage medium of claim 8.
Asthana further discloses:
wherein the metadata includes a schema for the cloud resource (“Our data model is a domain specific representation of service metadata.”, page 4, left column, para 2, “ResourceType is a uniquely named entity for a resource representation. Each ResourceType describes a component that may be instantiated from an Orchestration Engine blueprint and viewed from an instance management portal. Each Re-sourceType has a single ResourceSchema and defines multiple ResourceActions.”, page 4, right column, para 2).
With regard to claim 15, Asthana discloses:
retrieving, (“The metadata within the Service Registry details the catalog of service templates available for consumption. The Service Registry exposes a user interface and a rich API for creating, reading, updating, and deleting the metadata.”, page 3, right column, para 1, “The Plugin Code Generator builds plugins from service metadata modeled in the Service Registry.”, page 3, right column, para 2), the plugin to provide a capability to provision a cloud resource of the cloud resource platform; (“The plugin implementation performs the actions for creating, configuring, destroying, and importing resources.”, page 3, left column, para 2, “The Plugin Code Generator leverages metadata from the Service Registry to dynamically build plugins for extensible Orchestration Engines.”, page 1, right column, para 1);
registering, (“A Service Registry is a repository that is populated with metadata that represents Providers, ServiceTypes, ResourceTypes, and Actions defined in our data model, described in Section V. The metadata within the Service Registry details the catalog of service templates available for consumption. The Service Registry exposes a user interface and a rich API for creating, reading, updating, and deleting the metadata. Service providers are able to on-board, modify, and delete managed services’ definitions on the platform for a wide range of public and private cloud offerings. Our implementation persists the metadata inside of a graph database which was chosen because of the inherent connections between services, resources, and actions. The Service Registry also introspects Swagger specifications and dynamically populates API actions into the repository for simplified service authoring.”, page 3, right column, para 1);
generating, (“After plugins are built and deployed to an extensible Orchestration Engine, blueprints can be authored with managed services.”, page 3, right column, para 3, “representing managed services as code within reusable blueprints in order to accelerate service deployments and ease management activities”, page 1, left column, abstract, “Blueprints have the following characteristics and benefits: Defines one or more resource(s). Creation of a resource instance is handled by an Orchestration Engine plugin. Defines the relationships and dependencies between the resources specified in the blueprint, ensuring that resources are created in the correct order. Each named resource in the blueprint has its property values explicitly set to a value or implicitly set via a reference to a property from a different named resource in the blueprint or implicitly set in the blueprint via a reference to an input parameter.”, page 2, right column, para 2);
provisioning, (“An Orchestration Engine creates, configures, and destroys resources declared in a blueprint. An Orchestration Engine interprets a blueprint and automatically determines resource dependencies within a blueprint. Based on resource dependencies, the engine automatically establishes optimal execution paths for the instantiation of the described workload.”, page 2, right column, para 5).
Asthana does not disclose:
A method comprising:
executing an instruction with processor circuitry
performing, by executing an instruction with the processor circuitry, a first transformation of the metadata from a first format associated with the plugin to a second format associated with a blueprint service;
transforming, by executing an instruction with the processor circuitry, the blueprint from the second format to a third format, the third format at least partially defined by the first format.
However, Asthana ‘156 discloses:
A method comprising (“systems and methods of assigning computing resources of a cloud by an orchestration engine”, para [0019]):
by executing an instruction with processor circuitry (“instructions that, when executed by one or more processors, perform the recited operations”, para [0057]),
Both the systems of Asthana and Asthana ‘156 deal with resource provisioning. It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine Asthana in view of Asthana ‘156 to automate resource distribution.
Ferguson discloses:
performing, (“Calls the transformation artifact, for example, a generated Java transformation class, to convert from the XML input message to the back-end system’s binary format, for example, a byte array overlay for a C structure”, page 8, left column, para 3. Examiner’s note: Blueprint service is interpreted as “Additionally or alternatively, the blueprint service circuitry 206 may be instantiated by any other combination of hardware, software, and/or firmware.”, para [0060]. Plugin is interpreted as “a plugin (e.g., a data file, an Idem doc file, etc.)”, para [0028].);
transforming, (“invokes a transformation artifact to convert from the back-end message format to the XML (or Java) format”, page 8, left column, page 3); and
Both the systems of Asthana and Ferguson deal with templates. It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine Asthana view of Ferguson to increase interoperability, “The main benefits are interoperability and simplification.” (Ferguson, page 20, right column, paragraph 4).
With regard to claim 19, Asthana as modified discloses the system of claim 1.
Asthana does not disclose however, Asthana ‘156 discloses:
wherein the programmable circuitry is to receive a provisioning request from the blueprint service to provision the cloud resource (“A computing device (e.g., 102(1)) provides a workload request 103(1), sometimes referred to herein as a business request, to the orchestration engine 103, which is a software program running on the orchestration server 116. Each workload includes a blueprint, which is a declarative representation of the workload that is both human and machine readable. It describes the relevant resources and the properties thereof. Blueprints provide an architectural overview of a platform that is later virtualized on the cloud by way of the orchestration engine 103. For example, a blueprint allows the specification of desired resources, without the requirement of detailed programming commands that describe the creation of those resources.”, para [0026], “FIG. 8 illustrates a network or host computer platform 800, as may be used to implement a server, such as the orchestration server 116 of FIG. 1.”, para [0088]. “The computer platform 800 may include a central processing unit (CPU) 804, a hard disk drive (HDD) 806, random access memory (RAM) and/or read only memory (ROM) 808, a keyboard 810, a mouse 812, a display 814, and a communication interface 816, which are connected to a system bus 802.”, para [0089], fig 1, fig 8. Examiner’s note: Blueprint service is interpreted as “Additionally or alternatively, the blueprint service circuitry 206 may be instantiated by any other combination of hardware, software, and/or firmware.”, para [0060].)
Both the systems of Asthana and Asthana ‘156 deal with resource provisioning. It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine Asthana as modified in view of Asthana ‘156 to automate provisioning resources.
With regard to claim 20, Asthana as modified discloses the system of claim 1.
Asthana further discloses:
wherein (“The Service Registry exposes a user interface and a rich API for creating, reading, updating, and deleting the metadata.”, page 3, right column, para 1).
Asthana does not disclose however, Asthana’156 discloses:
the programmable circuitry (“instructions that, when executed by one or more processors”, para [0057])
Both the systems of Asthana and Asthana ‘156 deal with resource provisioning. It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine Asthana in view of Asthana ‘156 to automate resource distribution.
Claims 2, 9, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Asthana, Asthana ‘156, and Ferguson as applied to claims 1 and 8 above, and further in view of Zahra et al. (U.S. Patent Application Publication No. US 20240086266 A1, hereinafter “Zahra”).
With regard to claim 2, Asthana as modified discloses the system of claim 1.
Asthana further discloses:
wherein the programmable circuitry is to retrieve the metadata via an API call (“The Service Registry exposes a user interface and a rich API for creating, reading, updating, and deleting the metadata.”, page 3, right column, para 1).
Asthana as modified does not disclose however, Zahra discloses:
an API call at periodic intervals (“a metadata API from which metadata can be periodically retrieved”, para [0050])
Both the systems of Asthana and Zahra deal with APIs. It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine Asthana as modified in view of Zahra to improve efficiency.
With regard to claim 9, Asthana as modified discloses the non-transitory computer readable storage medium of claim 8.
Asthana further discloses:
wherein the programmable circuitry is to retrieve the metadata via an API call (“The Service Registry exposes a user interface and a rich API for creating, reading, updating, and deleting the metadata.”, page 3, right column, para 1).
Asthana as modified does not disclose however, Zahra discloses:
an API call at periodic intervals (“a metadata API from which metadata can be periodically retrieved”, para [0050])
Both the systems of Asthana and Zahra deal with APIs. It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine Asthana as modified in view of Zahra to improve efficiency.
With regard to claim 16, Asthana as modified discloses the system of claim 1.
Asthana further discloses:
wherein the programmable circuitry is to retrieve the metadata via an API call (“The Service Registry exposes a user interface and a rich API for creating, reading, updating, and deleting the metadata.”, page 3, right column, para 1).
Asthana as modified does not disclose however, Zahra discloses:
an API call at periodic intervals (“a metadata API from which metad