DETAILED ACTION
The Office Action is in response to Amendments filed 10/31/2025.
Claims 1, 9, 17, and 19 are currently amended.
The rejection of claim 19 under 35 U.S.C. 112(b) has been withdrawn in view of applicant’s amendment to claim 19.
The rejections of claims 1-20 under 35 U.S.C. 101 have been withdrawn in view of applicant’s amendments to claims 1, 9, and 17.
Claims 1-20 are pending.
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 .
Specification
The disclosure is objected to because of the following informalities:
Paragraph 15 recites the following specification “The consuming system can query this information and build an instance of the software application that is then
The specification includes a redundant paragraph [0021]. This paragraph does not provide any content. Applicant is recommended to amend any following paragraph numbers accordingly.
Appropriate correction is required.
Claim Objections
Claims 2, are objected to because of the following informality:
Claims 2, 10, and 18 contains a minor grammatical error. The claim recites the limitation “which is previously shipped to the computing device”. Applicant is recommended to amend as follows: “which was previously shipped to the computing device”.
Appropriate correction is required.
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 3 and 5 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.
Claim 3 recites the limitation "a most-recent version of the blueprint" in line 2. It is unclear if “a most-recent version of the blueprint” refers to previously stated “a most-recent version of the blueprint” in claim 1 or to something else entirely. Thus, the claim is rejected for being vague and indefinite.
Claim 5 recites the limitation “to generate an instance of the software application” in line 2. It is unclear if “an instance” refers to previously stated build “instance” in claim 1 or to something else entirely. Thus, the claim is rejected for being vague and indefinite.
Appropriate 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-2, 5, 9-10, and 13 are rejected under 35 U.S.C. 103 as being unpatentable over US 20190243665 A1 hereinafter “Bolik” in view of US 20160132805 A1 hereinafter “Delacourt” and further in view of US 11099907 B1 hereinafter “Karve”.
With regards to claim 1, Bolik teaches
a storage configured to store multiple versions of a blueprint of a software application, wherein each version of the blueprint comprises different code dependencies between code modules of the software application; (Bolik [0065-67], "a configuration object schema may include sequence information for the attributes or dependencies within it. Sequence information may indicate an order of preference or a hierarchy of the attributes or dependencies. For example, such an order of preference or hierarchy may be used as the order in which to perform an action on the attributes or dependencies [code dependencies between code modules of the software application]. A configuration object schema may have more than one set of sequence information for separate sets of attributes or dependencies within the configuration object schema; such sequences may overlap with which attributes or dependencies they reference. Sequence information may be derived from dependencies, or may be independent of dependencies. If a configuration object schema is changed, such as to add new configuration attributes or remove obsolete attributes, a new configuration object schema may be created with a new version number, based on the changed configuration object schema [each version of the blueprint comprises different]. A configuration object schema may define the configuration attributes needed for an application to run [of a software application]. The configuration object schema may be stored by the configuration service. Further, the configuration service may store each version of a given configuration object schema [a storage configured to store multiple versions of a blueprint], thereby having a history of the versions of a given configuration object schema. The configuration service may make the historical versions of a given configuration object schema available for use as needed, such as to roll-back an update in a system or to use a more compatible version in a different system.") and
a processor configured to: Bolik [0179], “he processing units 810, 815 execute computer-executable instructions, such as for implementing components of the processes of FIGS. 4, 5A-C, 6A-B, or 7A-C, or the systems of FIGS. 2A-B or 3A-C, or the configuration models and artifacts of FIGS. 1A-C. A processing unit can be a general-purpose central processing unit (CPU), processor in an application-specific integrated circuit (ASIC), or any other type of processor.”)
Bolik does not teach: receive a request to run the software application from a computing device,
build an instance of the software application on the computing device, the instance of the software application comprising the one or more code modules received via the transfer, and
execute the instance of the software application on the computing device.
However, in an analogous art Delacourt teaches to receive a request to run the software application from a computing device, (Delacourt [0089], “For example, end users 134 may log into desktop application management module 128 in order to request delivery of, to subscribe to, to unsubscribe from, to install, to uninstall, to launch, or to otherwise manage a particular desktop application [to receive a request to run the software application] ( one that may or may not be included in a catalog to which the end user currently has access), or may log into resource stack management service console 130 in order to construct a resource stack instance from a resource stack template ( on service provider resources), or request access to a service provided by a resource stack instance that has been constructed (on service provider resources) from a corresponding resource stack template ( a service that the end user may or may not currently be authorized to launch). In some embodiments, when requests are received from end users 134 for desktop applications or services that are managed by the enterprise catalog service, they may initiate various workflows of enterprise catalog service platform 108, desktop application fulfilment platform 126 and/or resource stack management service 13 2 that may or may not result in the end users 134 receiving the requested product access [from a computing device]”)
build an instance of the software application on the computing device, the instance of the software application comprising the one or more code modules received via the transfer, and
execute the instance of the software application on the computing device. (Delacourt [0122-123], “As illustrated in this example, a client of a service provider system 530 may provide a resource stack template 510 that defines the resources 514 that will be used to execute a server application (e.g., a server product) on behalf of an end user of a service provider customer and a set of metadata 512 for the resource stack. For example, the resources may include one or more compute node instance (or other modules) that will be used to execute the server application, a set of database instances that will store the data processed by the server, load balancers for distributing request traffic or other resources, and the metadata may include configuration files (which may contain the identities and/or setting for various resources of the resource stack), connectivity/dependencies, user identity and/or permissions information, alarms, tags, or other information [the instance of the software application comprising the one or more code modules received via the transfer] … In some embodiments, in response to receiving the resource stack template 510, the service provider system 530 (or, more specifically, a resource stack management service 520 that is implemented on the service provider network) may parse the template and build the stack of resources 514 that are defined in the template 510 [build an instance of the software application on the computing device] and that will be used to execute the server application (shown as resource stack 540) [execute the instance of the software application on the computing device]. For example, in some embodiments, the resource stack management service 520 may include a resource provisioning system that is configured to instantiate the resources defined in the template 510 to create resource stack 540. In some embodiments, building the resource stack 540 may include instantiating at least one computing resource instance (e.g., compute node 542) that will execute the server application 544 and manage its runtime environment, and may include one or more other stack resources (shown as stack resources 546).”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Delacourt into the teachings of Bolik. This combination of teachings would have resulted in an apparatus configured to store multiple versions of an application blueprint that define code dependencies, as in Bolik, with a user request that triggers the delivery of code modules to instantiate and execute a build, as in Delacourt. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of making the selected resource stack template available in correspondence with constraints and configuration parameter settings that are selectable, visible or otherwise through a service console (Delacourt [0172]).
The combination of Bolik and Delacourt does not teach: identify one or more prerequisites for one or more of the multiple versions of the blueprint to be active, wherein the one or more prerequisites for a particular version of the blueprint of software application are hard coded into the particular version of the blueprint,
determine a most-recent version of the blueprint from among the multiple versions of the blueprint which has fulfilled the one or more prerequisites, and
transfer one or more code modules of the software application to the computing device based on dependencies between the one or more code modules included in the most-recent version of the blueprint
However, in an analogous art Karve teaches to identify one or more prerequisites for one or more of the multiple versions of the blueprint to be active, wherein the one or more prerequisites for a particular version of the blueprint of software application are hard coded into the particular version of the blueprint, (Karve Column 5 Lines 40-52, “As described in detail below, the server (110) and the knowledge engine (150) interpret and manage an executable codified infrastructure, e.g. blueprint(s). The management includes prerequisite driven orchestration of a blueprint. The knowledge engine (150) utilizes the prerequisite manager (152) to receive the executable blueprint, with the blueprint including one or more prerequisites. The prerequisites define an order of deployment of resources in the blueprint through the use of codified logical expressions. Prerequisites may include external requirements and those defined within the blueprint, e.g. internal requirements. Accordingly, the prerequisite manager (152) receives the executable codified infrastructure containing one or more prerequisites.”) [Examiner’s Note: The blueprint is a codified infrastructure described to contain the one or more prerequisites. A knowledge engine is defined to probe for these prerequisites when the blueprint is received. Karve further differentiates one or more blueprint versions by removal or attachment of required prerequisites/resources/code modules]
determine a most-recent version of the blueprint from among the multiple versions of the blueprint which has fulfilled the one or more prerequisites, (Karve Column 8 Lines 39-60, “A negative response to the determination at step (314) is an indication that newly created blueprint mirrors the originally received blueprint and there are no changes to the original blueprint, and as such the originally received blueprint is deployed (316). A positive response to the determination at step (314) is an indication that the newly created blueprint is an update to the originally received blueprint, and more specifically, the newly created blueprint contains changes from the original or prior blueprint version [determine a most-recent version of the blueprint from among the multiple versions of the blueprint]. The orchestration engine leverages the current state of resources so that new resources are provisioned or existing resources are re-provisioned (318) and the identified changes in the newly generated or revised blueprint are planned and applied to the originally received blueprint which is then deployed, wherein the deployment is based on the new resource provisioning or existing resource re-provisioning (320). Accordingly, probes are created to monitor one or more resource prerequisites, and a new blueprint is created or a previous blueprint is revised, with the new or revised blueprint incorporating one or more corresponding resource(s) based on the satisfaction of the monitored prerequisites [which has fulfilled the one or more prerequisites].”) and
transfer one or more code modules of the software application to the computing device based on dependencies between the one or more code modules included in the most-recent version of the blueprint (Karve Column 9 Lines 7-22, “A blueprint with one or more logic-based dependencies is received (402) [based on dependencies between the one or more code modules]. Similar to FIG. 3, probes dynamically monitor and evaluate the system for one or more resources associated with one or more identified prerequisites (404). A newly generated blueprint based on the satisfied prerequisite(s) is sent to the orchestration manager (406), and the orchestration manager deploys the blueprint with the identified change(s) (408) [included in the most-recent version of the blueprint]. The probes dynamically monitor and evaluate the system for blueprint resources and any resources associated with the identified prerequisite(s) in the newly generated or revised blueprint (410). A determination is made to ascertain if the newly generated blueprint requires one or more new resources based on a resource demand [transfer one or more code modules of the software application to the computing device], or downgrading, removing, or detaching one or more resources when prerequisites are no longer met”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Karve into the teachings of Bolik in view of Delacourt. This combination of teachings would have resulted in an apparatus configured to store multiple versions of an application blueprint that define code dependencies, as in Bolik, with a user request that triggers the delivery of code modules to instantiate and execute a build, as in Delacourt, wherein the blueprint is a codified infrastructure that defines prerequisties that when fulfilled can deliver the code modules accordingly, as in Karve. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of using a blueprint to describe resources that will be created, dependencies between resources, and their properties (Karve Column 3 Lines 42-57).
With regards to claim 2, the rejection of claim 1 is incorporated.
Bolik does not teach: to receive the request to run the software application from a main code module of the software application which is previously shipped to the computing device
However, in an analogous art Delacourt teaches to receive the request to run the software application from a main code module of the software application which is previously shipped to the computing device (Delacourt [0112], "Desktop application delivery agent 436 (which may be a client component of desktop application fulfillment platform 420) may be configured to communicate with various fulfillment platform control place services 426 in order to fulfill requests to subscribe to, install, and/or execute applications [to receive the request to run the software application] selected through desktop application management module 432 or through another user interface mechanism ( e.g., application icon 440 on desktop 434 or a start menu item). In other words, desktop application management module 432 is an application that may be installed on the end user's computing resource instance 438 [main code module of the software application which is previously shipped to the computing device] to allow the end user to interact with desktop application fulfillment platform 420 through desktop application delivery agent 436.")
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Delacourt into the teachings of Bolik. This combination of teachings would have resulted in an apparatus configured to store multiple versions of an application blueprint that define code dependencies, as in Bolik, with a user request that triggers the delivery of code modules to instantiate and execute a build, as in Delacourt. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of making the selected resource stack template available in correspondence with constraints and configuration parameter settings that are selectable, visible or otherwise through a service console (Delacourt [0172]).
With regards to claim 5, the rejection of claim 1 is incorporated.
Bolik does not teach: to generate an instance of the software application based on the dependencies between the one or more code modules included in the most-recent version of the blueprint,
and execute the instance of the software application on the computing device
However, in an analogous art Delacourt teaches to generate an instance of the software application based on the dependencies between the one or more code modules included in [the most-recent version of] the blueprint, and execute the instance of the software application on the computing device user identity and/or permissions information, alarms, tags, or other information (Delacourt [0122-123], "As illustrated in this example, a client of a service provider system 530 may provide a resource stack template 510 [included in the blueprint] that defines the resources 514 that will be used to execute a server application (c.g., a server product) on behalf of an end uscr of a service provider customer and a set of metadata 512 for the resource stack. For example, the resources may include one or more compute node instance ( or other modules) that will be used to execute the server application, a set of database instances that will store the data processed by the server, load balancers for distributing request traffic or other resources, and the metadata may include configuration files (which may contain the identities and/or setting for various resources of the resource stack), connectivity/dependencies [based on the dependencies between the one or more code modules], In some embodiments, in response to receiving the resource stack template 510, the service provider system 530 ( or, more specifically, a resource stack management service 520 that is implemented on the service provider network) may parse the template and build the stack of resources 514 that are defined in the template 510 and that will be used to execute the server application (shown as resource stack 540) [execute the instance of the software application on the computing device]. For example, in some embodiments, the resource stack management service 520 may include a resource provisioning system that is configured to instantiate the resources defined in the template 510 to create resource stack 540. In some embodiments, building the resource stack 540 may include instantiating at least one computing resource instance (e.g., compute node 542) that will execute the server application 544 and manage its runtime environment, and may include one or more other stack resources (shown as stack resources 546). The compute node 542 may be a virtualized computing resource instance that has a predefined computing capacity and/or memory capacity. In some embodiments, the compute node 542 may be loaded with an operating system, configuration files, or other resources that are pre-installed on the compute node 542 when it is instantiated [to generate an instance of the software application].")
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Delacourt into the teachings of Bolik. This combination of teachings would have resulted in an apparatus configured to store multiple versions of an application blueprint that define code dependencies, as in Bolik, with a user request that triggers the delivery of code modules to instantiate and execute a build, as in Delacourt. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of making the selected resource stack template available in correspondence with constraints and configuration parameter settings that are selectable, visible or otherwise through a service console (Delacourt [0172]).
Claims 9-10 and 13 are directed to a method corresponding to the apparatus limitations as disclosed in claims 1-2 and 5 respectively. Thus, claims 9-10 and 13 are rejected for the same reasons set forth in claim 1-2 and 5.
Claims 3 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Bolik in view of Delacourt in view of Karve, as applied to claims 1 and 9 respectively, in view of US 20220236976 A1 hereinafter “Wiegley” and further in view of US 20200257612 A1 hereinafter “Lang”.
With regards to claim 3, the rejection of claim 1 is incorporated.
The combination of Bolik, Delacourt, and Karve does not teach: wherein the processor is configured to identify a most-recent version of the blueprint in a blueprint data store,
However, Wiegley teaches: wherein the processor is configured to identify a most-recent version of the blueprint in a blueprint data store (Wiegley [0183], "A last known good version pointer may be different from a stable pointer when there are several recent versions since a stable version was created and a service owner identifies one of the recent versions that is relatively stable as the last known good version pointer. At some point the last known good pointer may become a stable pointer. Each version pointer identifies a version and the corresponding deployment package having the identified version [to identify]. Version pointers may be defined for a service or for an application. In an embodiment, the version pointer store 1520 stores a prefix of a checksum representing the version, so long as the prefix includes enough character or bytes to be able to uniquely identify the version. The latest version pointer always refers to the state of the template [a most-recent version of the blueprint], variables, macros, libraries and datacenter metadata at the time that the pipeline generator executes. In an embodiment, the version store associates a version pointer with a scope specified using the datacenter metadata [in a blueprint data store]. Accordingly, the version of the deployment package corresponding to the version pointer is applicable to all datacenter entities specified by the scope. For example, the version pointer may be associated with a datacenter, a service group, a service instance, or a combination of these. In an embodiment, the scope of a version pointer is a pipeline execution engine 360 such that all pipelines executed in the pipeline execution engine 360 correspond to the version specified by the version pointer.") [Examiner Note: A stable pointer can point to a version of the pipeline template in production that meets the requirements, but it doesn't always indicate the most-recent/latest version as determined by the latest version pointer]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Wiegley into the teachings of Bolik in view of Delacourt and further in view of Karve. This combination of teachings would have resulted in an apparatus configured to store multiple versions of an application blueprint that define code dependencies, as in Bolik, with a user request that triggers the delivery of code modules to instantiate and execute a build, as in Delacourt, wherein the blueprint is a codified infrastructure that defines prerequisties that when fulfilled can deliver the code modules accordingly, as in Karve, and determining the latest possible version blueprint that meets the requirements for further deployment of the application features, as in Wiegley. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of supporting versioning of pipeline templates in order to deploy, upon request, a version of the pipeline template while supporting customization for stable updates to the pipeline templates (Wiegley [0177]).
The combination of Bolik, Delacourt, Karve, and Wiegley does not teach: determine that [the most-recent version of] the blueprint has not fulfilled the one or more prerequisites based on [the most-recent version of] the blueprint.
However, in an analogous art Lang teaches to determine that [the most-recent version of] the blueprint has not fulfilled the one or more prerequisites based on [the most-recent version of] the blueprint. (Lang [0065-66], “Assessing the test results may involve identifying which objects, functions, and/or workflows/sequences of operations [determine that the blueprint] worked as needed and which did not [has not fulfilled]. These results can be provided to the client device 102 and can be used to identify software modules, within the tested build version of the enterprise application, were affected by errors, to annotate the development codebase for the tested build version of the enterprise application (which can later be used to create a new build version), to identify tested server environment configurations, or parts thereof, that may have led to an error The testing system 120 (as shown in FIGS. 1A-1B) may perform this integrity testing. During integrity testing, the testing system 120 systematically accesses elements in the data sets 114 and verifies whether the elements are present and accessible. The testing system 120 may check all of the properties of an object, as well as attempt to perform any functions that the object allows. In a similar manner, the testing system 120 can verify that links, dependencies, requirements, and relationships are valid [the one or more prerequisites]. In some implementations, this integrity testing is comprehensive, testing all objects or data of certain types, or even attempting to test all data elements in the data sets 114.")
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Lang into the teachings of Bolik in view of Delacourt in view of Karve and further in view of Wiegley. This combination of teachings would have resulted in an apparatus configured to store multiple versions of an application blueprint that define code dependencies, as in Bolik, with a user request that triggers the delivery of code modules to instantiate and execute a build, as in Delacourt, wherein the blueprint is a codified infrastructure that defines prerequisties that when fulfilled can deliver the code modules accordingly, as in Karve, and determining the latest possible version blueprint that meets the requirements for further deployment of the application features, as in Wiegley, incorporating dependency and code module relationships, are compatible with application requirements, as in Lang. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of defining workflows based on customer data and testing their configurations to reveal errors and incompatibilities (Lang [0031]).
Claim 11 is directed to a method corresponding to the apparatus limitations as disclosed in claim 3. Thus, claim 11 is rejected for the same reasons set forth in claim 3.
Claims 4 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Bolik in view of Delacourt in view of Karve in view of Wiegley in view of Lang, as applied to claims 3 and 11 respectively, and further in view of US 2006016563 A1 hereinafter “Besbris”.
With regards to claim 4, the rejection of claim 3 is incorporated.
The combination of Bolik and Delacourt does not teach: determine that [the next most-recent] version of the blueprint has fulfilled the one or more prerequisites, and in response, execute code modules included in [the next most recent version of] the blueprint.
However, in an analogous art Karve teaches determine that [the next most-recent] version of the blueprint has fulfilled the one or more prerequisites, and in response, execute code modules included in [the next most-recent version of] the blueprint. (Karve Column 4 Lines 7-18, "Blueprint prerequisites are logic-based dependencies and may include external requirements that are defined outside of the blueprint, and internal requirements that are defined within the blueprint. Dependencies are notations that allow a user to define which other resources must be satisfied before the next resource can begin. By their very nature, the next resource cannot be satisfied unless the prior resource upon which the dependency relies has been satisfied. A blueprint is defined with one or more prerequisites [the one or more prerequisites]. The orchestration engine deploys resources when the defined prerequisites as indicated in the blueprint are met [determine that the version of the blueprint has fulfilled].") (Karve Column 7 Lines 42-63, "Each of the APis may be implemented in one or more languages and interface specifications. API (212) provides support for receipt of the codified infrastructure, e.g. blueprint [of the blueprint]; API (222) provides support for creating one or more probes to monitor a dynamic resource state of each resource associated with a prerequisite in the blueprint; and API (232) provides support for generating a new or revised blueprint and deploying one or more new resources [execute code modules included] based on the satisfaction of one or more prerequisites [in response].")
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Karve into the teachings of Bolik in view of Delacourt. This combination of teachings would have resulted in an apparatus configured to store multiple versions of an application blueprint that define code dependencies, as in Bolik, with a user request that triggers the delivery of code modules to instantiate and execute a build, as in Delacourt, wherein the blueprint is a codified infrastructure that defines prerequisties that when fulfilled can deliver the code modules accordingly, as in Karve. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of using a blueprint to describe resources that will be created, dependencies between resources, and their properties (Karve Column 3 Lines 42-57).
The combination of Bolik, Delacourt, Karve, Wiegley, and Lang does not teach: to identify a next most-recent version [of the blueprint] in response to the determination that the most-recent version [of the blueprint] has not fulfilled the one or more prerequisites
However, in an analogous art Besbris teaches to identify a next most-recent version [of the blueprint] in response to the determination that the most-recent version [of the blueprint] has not fulfilled the one or more prerequisites (Besbris [0090], "The host manager 404 then inspects the service manifest to determine whether the manifest indicates that the service is incompatible with the client version (914). If a <clientFilter> tag and/or an <override> tag indicates that the client 402 (identified by its client moniker) is not permitted to use that version of the service (916) [in response to the determination has not fulfilled], and there are more versions of the service (918), then the host manager 404 accesses the service manifest of the next most recent version of the service (920) to determine if the client 402 is permitted to use that version of the service (914) [to identify a next most-recent version of the blueprint).") [Examiner Note: Each service is developed through its corresponding object model, a model that can have multiple versions depending on edits and controls the application objects (dependencies/software modules) See P[0045])
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Besbris into the teachings of Bolik in view of Delacourt in view of Karve in view of Wiegley and further in view of Lang. This combination of teachings would have resulted in an apparatus configured to store multiple versions of an application blueprint that define code dependencies, as in Bolik, with a user request that triggers the delivery of code modules to instantiate and execute a build, as in Delacourt, wherein the blueprint is a codified infrastructure that defines prerequisites that when fulfilled can deliver the code modules accordingly, as in Karve, determining the latest possible version blueprint that meets the requirements for further deployment of the application features, as in Wiegley, incorporating dependency and code module relationships, are compatible with application requirements, as in Lang, and if requirements are not met then the system enables identification of the next most-recent version compatible with the requirements, as in Besbris. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of searching a manifest to identify the correct version of the document object model for the client (Besbris [0089]).
Claim 12 is directed to a method corresponding to the apparatus limitations as disclosed in claim 4. Thus, claim 12 is rejected for the same reasons set forth in claim 4.
Claims 6-7 and 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Bolik in view of Delacourt in view of Karve, as applied to claims 1 and 9 respectively, and further in view of US 9063742 B1 hereinafter “Bienkowski”.
With regards to claim 6, the rejection of claim 1 is incorporated.
The combination of Bolik, Delacourt, and Karve does not teach: wherein the processor is further configured to download a prior version of the software application to the computing device, prior to downloading the one or more code modules included in the most-recent version of the blueprint.
However, in an analogous art Bienkowski teaches wherein the processor is further configured to download a prior version of the software application to the computing device, prior to downloading the one or more code modules included in the most-recent version of the blueprint. (Bienkowski Column 6 Lines 50-58, "As further shown in FIG. 4, process 400 may include storing, in the identified data structure, the first version [to download a prior version of the software application to the computing device] and/or the second version of the portion of program code (block 460). For example, client device 210 may identify the data structure, and may store the first version and/or the second version of the portion of program code in the data structure. Client device 210 may store the first version before or after the modification of the portion of program code from the first version to the second version. Additionally, or alternatively, client device 210 may store the second version after the modification of the portion of program code from the first version to the second version [prior to downloading the one or more code modules included in the most-recent version].") [Examiner's Note: An updated version of the blueprint can contain new configurations of the one or more code modules. Downloading one or more code modules can be accomplished by storing the second (updated) version of program code/code modules that are defined by the updated version of the blueprint]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Bienkowski into the teachings of Bolik in view of Delacourt and further in view of Karve. This combination of teachings would have resulted in an apparatus configured to store multiple versions of an application blueprint that define code dependencies, as in Bolik, with a user request that triggers the delivery of code modules to instantiate and execute a build, as in Delacourt, wherein the blueprint is a codified infrastructure that defines prerequisites that when fulfilled can deliver the code modules accordingly, as in Karve, and retrieving the versions of application software sequentially, as in Bienkowski. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of evaluating the program code based on the associated information generated with storing an indication between a result, a version, and a temporal relationship (Bienkowski Column 8 Lines 29-40).
With regards to claim 7, the rejection of claim 6 is incorporated.
The combination of Bolik and Delacourt does not teach: wherein the processor is further configured to identify a new code module that is included in the most-recent version of the blueprint that is not included in the prior version of the software application based on the one or more code modules included in the most-recent version of the blueprint, and identify a prerequisite of the new code module that is not a prerequisite for the prior version of the software application.
However, in an analogous art Karve teaches wherein the processor is further configured to identify a new code module that is included in the most-recent version of the blueprint that is not included in the prior version of the software application based on the one or more code modules included in the most-recent version of the blueprint, and identify a prerequisite of the new code module that is not a prerequisite for the prior version of the software application. (Karve Column 6 Lines 17-26, "The orchestration engine (170) identifies the changes between an original blueprint and the generated revised or new blueprint from the orchestration manager (156) [identify a new code module that is included in the most-recent version of the blueprint that is not included in the prior version of the software application]. Changes to the blueprint may be reflected in a corresponding resource, such as removal or detachment of a resource when a prerequisite is no longer met, or attachment of a resource when a prerequisite is met. For example, in an embodiment, blueprintA (164A) may be an original blueprint and blueprint (164B) may be a revised or new blueprint [based on the one or more code modules included in the version of the blueprint].") identify a prerequisite of the new code module that is not a prerequisite for the prior version of the software application. (Karve Column 8 Lines 55-60, "Accordingly, probes are created to monitor one or more resource prerequisites [identify a prerequisite], and a new blueprint is created or a previous blueprint is revised, with the new or revised blueprint incorporating one or more corresponding resource(s) based on the satisfaction of the monitored prerequisites. 60") (Karve Column 9 Lines 7-22, "A blueprint with one or more logic-based dependencies is received (402). Similar to FIG. 3, probes dynamically monitor and evaluate the system for one or more resources associated with one or more identified prerequisites (404). A newly generated blueprint based on the satisfied prerequisite(s) is sent to the orchestration manager ( 406), and the orchestration manager deploys the blueprint with the identified change(s) (408). The probes dynamically monitor and evaluate the system for blueprint resources and any resources associated [of the new code module] with the identified prerequisite(s) in the newly generated or revised blueprint (410). A determination is made to ascertain if the newly generated blueprint requires one or more new resources based on a resource demand, or downgrading, removing, or detaching one or more resources when prerequisites are no longer met (412) [that is not a prerequisite for the prior version of the software application].") [Examiner's Note: Each version on the blueprint corresponds with the application version. A new version of the blueprint will incorporate one or more new resources associated with one or more prerequisites. A new resource indicates a new prerequisite which also indicates a prerequisite that was not existent in the previous version of the blueprint/application]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Karve into the teachings of Bolik in view of Delacourt. This combination of teachings would have resulted in an apparatus configured to store multiple versions of an application blueprint that define code dependencies, as in Bolik, with a user request that triggers the delivery of code modules to instantiate and execute a build, as in Delacourt, wherein the blueprint is a codified infrastructure that defines prerequisties that when fulfilled can deliver the code modules accordingly, as in Karve. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of using a blueprint to describe resources that will be created, dependencies between resources, and their properties (Karve Column 3 Lines 42-57).
Claims 14-15 are directed to a method corresponding to the apparatus limitations as disclosed in claims 6-7 respectively. Thus, claims 14-15 are rejected for the same reasons set forth in claims 6-7.
Claims 8 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Bolik in view of Delacourt in view of Karve in view of Bienkowski, as applied to claims 7 and 15 respectively, and further in view of Besbris.
With regards to claim 8, the rejection of claim 7 is incorporated.
The combination of Bolik, Delacourt, Karve, and Bienkowski does not teach: wherein the processor is configured to verify that the identified prerequisite of the new code module has been fulfilled based on a query of the most-recent version of the blueprint.
However, in an analogous art Besbris teaches wherein the processor is configured to verify that the identified prerequisite of the new code module has been fulfilled based on a query of the most-recent version of the blueprint. (Besbris [0101] "The execution environment runtime 204b, through the service manager subsystem, may provide for service discovery, in which a client can request identification of services meeting particular criteria. As described above, service manifest files describe the properties and capabilities, and other information about the services or application services. A client may send a search query to the service manager subsystem [based on a query]. The search query specifies particular criteria. The service manager subsystem then searches the service manifests of the installed services or application services to determine which service manifest files contain meta-data meeting the specified criteria [to verify that the identified prerequisite of the new code module has been fulfilled]. The service manager subsystem then returns an identification of the services or application services that have manifest files that contain the specified metadata, and may return the specified metadata. The client can then use one of the returned services, or use the returned meta-data. The service manager subsystem also may limit the service manifests searched to those corresponding to the newest versions of the services [of the most-recent version of the blueprint] that are compatible with the client.")
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Besbris into the teachings of Bolik in view of Delacourt, in view of Karve, and further in view of Bienkowski. This combination of teachings would have resulted in an apparatus configured to store multiple versions of an application blueprint that define code dependencies, as in Bolik, with a user request that triggers the delivery of code modules to instantiate and execute a build, as in Delacourt, wherein the blueprint is a codified infrastructure that defines prerequisites that when fulfilled can deliver the code modules accordingly, as in Karve, and retrieving the versions of application software sequentially, as in Bienkowski, and if requirements are not met then the system enables identification of the next most-recent version compatible with the requirements, as in Besbris. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of searching a manifest to identify the correct version of the document object model for the client (Besbris [0089]).
Claim 16 is directed to a method corresponding to the apparatus limitations as disclosed in claim 8. Thus, claim 16 is rejected for the same reasons set forth in claim 8.
Allowable Subject Matter
Claims 17-20 allowed.
Response to Arguments
Applicant’s arguments, see Page 2 Line 13, filed 10/31/2025, with respect to 35 U.S.C. 112(b) have been fully considered and are persuasive. The rejection of claim 19 has been withdrawn.
Applicant’s arguments, see Pages 2-3, filed 10/31/2025, with respect to 35 U.S.C. 101 have been fully considered and are persuasive. The rejection of claims 1-20 has been withdrawn.
Applicant’s arguments with respect to claims 1-16 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TRAVIS VIET TRAN whose telephone number is (571)272-3720. The examiner can normally be reached Monday-Friday 8:30AM-5PM.
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, Wei Mui can be reached at 571-272-3708. 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.
/T.V.T./Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights