DETAILED ACTION
The Office Action is in response to a request for continued examination filed 3/26/2026.
Claims 1-2, 5-7, 8-10, 13-15, and 18 are currently amended.
Claim 16 is cancelled.
The objection to the specification has been withdrawn in view of the applicant’s amendments to the specification.
The objection to the claims have been withdrawn in view of the applicant’s amendments to the claims.
The rejection to claims 3 and 5 under 35 U.S.C. 112(b) has been withdrawn in view of the applicant’s amendments to the claims.
Claims 1-15 and 17-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 .
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, 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over US 20190243665 A1 hereinafter "Bolik" in view of US 20150199188 A1 hereinafter "Mantripragada" and further in view of US 20160132805 A1 hereinafter "Delacourt".
With regards to claim 1, Bolik teaches
An apparatus comprising: 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 teaches a blueprint but does not teach: determine that one or more prerequisites for a particular version of the blueprint have not been fulfilled based on querying the blueprint in a blueprint store to be active, wherein the one or more prerequisites for the particular version of the blueprint of software application are hard coded into the particular version of the blueprint,
identify a fallback blueprint of the software application which contains the one or more prerequisites that have all been fulfilled based on querying the fallback blueprint,
based on dependencies between the one or more code modules included in the fallback blueprint
However, in an analogous art Mantripragada teaches to determine that one or more prerequisites for a particular version of the blueprint (Mantripragada [0034], “Also in step 210, software package deployment management program 104 (see FIG. 1) determines whether all dependencies identified in a dependency profile included in the QA seal are satisfied. The dependency profile specifies hardware and software dependencies and pre-requisites for successful deployment of the software package.”) have not been fulfilled based on querying the blueprint in a blueprint store to be active, (Mantripragada [0041], “Returning to step 210, if software package deployment management program 104 (see FIG. 1) determines the QA seal indicates the software package is not compatible with the target deployment environment and/or determines that not all the aforementioned dependencies are satisfied, then the No branch of step 210 is taken and step 220 is performed. Again, in step 220, software package deployment management program 104 (see FIG. 1) creates a failure report or notification indicating that the deployment of the software package is not authorized. Following step 220, the process of FIG. 2 ends at step 218.”) wherein the one or more prerequisites for the particular version of the blueprint of software application are hard coded into the particular version of the blueprint, (Mantripragada [0021], “A QA seal is a data structure embedded in a software package, which provides a signature or security token, along with other profile data and metadata, used to automatically validate a software package and its contents and to deploy the software package to relevant target environments. A software package is software deployed to multiple computers or multiple distributed target computing environments, such as cloud-based or virtualized environments. For example, the software package may be an installer in an .exe or .zip file.”) [Examiner’s Note: A QA (quality assurance) seal includes the dependency profile which describes required dependencies and pre-requisites for software package deployments. If it is embedded as a data structure in the software package then it is hard coded into the blueprint.]
identify a fallback blueprint of the software application which contains the one or more prerequisites that have all been fulfilled (Mantripragada [0036], “In step 212, software package deployment management program 104 (see FIG. 1) determines whether the QA seal retrieved in step 202 indicates the software package is approved for release and deployment to the target deployment environment obtained in step 206. If software package deployment management program 104 (see FIG. 1) determines in step 212 that the QA seal indicates the software package is approved for release to the target deployment environment, then the Yes branch of step 212 is taken and step 214 is performed…. In step 214, software package deployment management program 104 (see FIG. 1) authorizes deployment of the software package to the target deployment environment and creates a success report or notification indicating the authorized deployment of the software package.”) based on querying the fallback blueprint; (Mantripragada [0028], “The process of FIG. 2 starts at step 200. In step 202, software package deployment management program 104 (see FIG. 1) retrieves a software package and its corresponding QA seal from software package repository 106 (see FIG. 1).”) [Examiner’s Note: A QA seal will include the dependency profile and prerequisites. If it is approved then that would mean that the prerequisites are fulfilled and the YES branch is taken]
based on dependencies between the one or more code modules (Mantripragada [0021], “A QA seal is a data structure embedded in a software package, which provides a signature or security token, along with other profile data and metadata, used to automatically validate a software package and its contents and to deploy the software package to relevant target environments. A software package is software deployed to multiple computers or multiple distributed target computing environments, such as cloud-based or virtualized environments. For example, the software package may be an installer in an .exe or .zip file.”) (Mantripragada [0034], “Also in step 210, software package deployment management program 104 (see FIG. 1) determines whether all dependencies identified in a dependency profile included in the QA seal are satisfied. The dependency profile specifies hardware and software dependencies and pre-requisites for successful deployment of the software package.”) included in the fallback blueprint (Mantripragada [0036], “In step 212, software package deployment management program 104 (see FIG. 1) determines whether the QA seal retrieved in step 202 indicates the software package is approved for release and deployment to the target deployment environment obtained in step 206. If software package deployment management program 104 (see FIG. 1) determines in step 212 that the QA seal indicates the software package is approved for release to the target deployment environment, then the Yes branch of step 212 is taken and step 214 is performed…. In step 214, software package deployment management program 104 (see FIG. 1) authorizes deployment of the software package to the target deployment environment and creates a success report or notification indicating the authorized deployment of the software package.”)
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 Mantripragada 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, determining whether or not a version of the defined application meets quality assurance standards that correspond to dependency and prerequisites, as in Mantripragada. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of providing a verification approach to regulate software package deployments to a target environment based on Quality Assurance Seal requirements (Mantripragada [0020]).
The combination of Bolik and Mantripragada 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 one or more code modules identified [based on dependencies between the one or more code modules included in the fallback blueprint] received via the transfer, and
execute the instance of the software application on the computing device.
However, in an analogous art Delacourt teaches: 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 one or more code modules identified […] 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 in view of Mantripragada. 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, determining whether or not a version of the defined application meets quality assurance standards that correspond to dependency and prerequisites, as in Mantripragada, 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 2, the rejection of claim 1 is incorporated.
The combination of Bolik and Mantripragada does not teach: to receive the request to run the software application from a main code module of the software application which was 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 was 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 in view of Mantripragada. 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, determining whether or not a version of the defined application meets quality assurance standards that correspond to dependency and prerequisites, as in Mantripragada, 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.
The combination of Bolik and Mantripragada teaches the one or more code modules included in the fallback blueprint but does not teach: wherein the processor is further configured to generate a second instance of the software application based on the dependencies between the one or more code modules included in the fallback blueprint, and
execute the second instance of the software application on the computing device.
However, in an analogous art Delacourt teaches: wherein the processor is further configured to generate a second instance of the software application based on the dependencies between the one or more code modules included in the fallback blueprint, and
execute the second 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 [included in the fallback 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 second 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 a second 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 in view of Mantripragada. 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, determining whether or not a version of the defined application meets quality assurance standards that correspond to dependency and prerequisites, as in Mantripragada, 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 claims 1-2 and 5.
Claims 17-18 are directed to a computer-readable medium corresponding to the apparatus limitations as disclosed in claims 1-2 respectively. Thus, claims 17-18 are rejected for the same reasons set forth in claims 1-2.
Claims 3, 11, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Bolik in view of Mantripragada in view of Delacourt as applied to claims 1, 9, and 17 respectively above, in view of US 20220236976 A1 hereinafter "Wiegley" in view of US 20200257612 Al hereinafter "Lang".
With regards to claim 3, the rejection of claim 1 is incorporated.
The combination of Bolik, Mantripragada, and Delacourt does not teach: wherein the processor is configured to identify a most-recent version of the blueprint in a blueprint data store,
However, in an analogous art 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 Mantripragada and further 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, determining whether or not a version of the defined application meets quality assurance standards that correspond to dependency and prerequisites, as in Mantripragada, with a user request that triggers the delivery of code modules to instantiate and execute a build, as in Delacourt, 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, Mantripragada, Delacourt and Wiegley teaches a most-recent blueprint but does not teach 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.
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 Mantripragada in view of Delacourt 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, determining whether or not a version of the defined application meets quality assurance standards that correspond to dependency and prerequisites, as in Mantripragada, with a user request that triggers the delivery of code modules to instantiate and execute a build, as in Delacourt, 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 when 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 claims 3 respectively. Thus, claim 11 is rejected for the same reasons set forth in claim 3.
Claim 19 is directed to a computer-readable medium corresponding to the apparatus limitations as disclosed in claims 3 respectively. Thus, claim 19 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 Mantripragada in view of Delacourt in view of Wiegley in view of Lang as applied to claims 3 and 11 respectively above, and further in view of US 2006016563 A1 hereinafter "Besbris".
With regards to claim 4, the rejection of claim 3 is incorporated.
Bolik 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 Mantripragada teaches determine that the [next most-recent] version of the blueprint has fulfilled the one or more prerequisites, (Mantripragada [0036], “In step 212, software package deployment management program 104 (see FIG. 1) determines whether the QA seal retrieved in step 202 indicates the software package is approved for release and deployment to the target deployment environment obtained in step 206. If software package deployment management program 104 (see FIG. 1) determines in step 212 that the QA seal indicates the software package is approved for release to the target deployment environment, then the Yes branch of step 212 is taken and step 214 is performed…. In step 214, software package deployment management program 104 (see FIG. 1) authorizes deployment of the software package to the target deployment environment and creates a success report or notification indicating the authorized deployment of the software package.”)
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 Mantripragada 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, determining whether or not a version of the defined application meets quality assurance standards that correspond to dependency and prerequisites, as in Mantripragada. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of providing a verification approach to regulate software package deployments to a target environment based on Quality Assurance Seal requirements (Mantripragada [0020]).
The combination of Bolik and Mantripragada does not teach: in response, execute code modules included in the [next most-recent] version of the blueprint
However, in an analogous art Delacourt teaches: in response, execute code modules included in the [next most-recent] version of the blueprint (Delacourt [0123], “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). 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 in view of Mantripragada. 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, determining whether or not a version of the defined application meets quality assurance standards that correspond to dependency and prerequisites, as in Mantripragada, 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, Mantripragada, Delacourt, Wiegley and Lang teaches the blueprint but does not teach: wherein the processor is further configured 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 Mantripragada, in view of Delacourt 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, determining whether or not a version of the defined application meets quality assurance standards that correspond to dependency and prerequisites, as in Mantripragada, with a user request that triggers the delivery of code modules to instantiate and execute a build, as in Delacourt, 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 when 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 claims 4 respectively. Thus, claim 12 is rejected for the same reasons set forth in claim 4.
Claims 6 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Bolik in view of Mantripragada in view of Delacourt as applied to claims 1 and 9 respectively above, 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, Mantripragada, and Delacourt 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 particular 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 particular 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 Mantripragada and further 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, determining whether or not a version of the defined application meets quality assurance standards that correspond to dependency and prerequisites, as in Mantripragada, with a user request that triggers the delivery of code modules to instantiate and execute a build, as in Delacourt, 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).
Claim 14 is directed to a method corresponding to the apparatus limitations as disclosed in claims 6 respectively. Thus, claim 14 is rejected for the same reasons set forth in claim 6.
Claims 7 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Bolik in view of Mantripragada in view of Delacourt in view of Bienkowski as applied to claims 6 and 14 respectively above, and further in view of US 11099907 B1 hereinafter "Karve".
With regards to claim 7, the rejection of claim 6 is incorporated.
The combination of Bolik, Mantripragada, Delacourt, and Bienkowski does not teach: wherein the processor is further configured to identify a new code module that is included in the particular 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 particular 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 particular 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 particular
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 particular 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 Mantripragada in view of Delacourt 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, determining whether or not a version of the defined application meets quality assurance standards that correspond to dependency and prerequisites, as in Mantripragada, with a user request that triggers the delivery of code modules to instantiate and execute a build, as in Delacourt, and retrieving the versions of application software sequentially, as in Bienkowski, 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).
Claim 15 is directed to a method corresponding to the apparatus limitations as disclosed in claims 7 respectively. Thus, claim 15 is rejected for the same reasons set forth in claim 7.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Bolik in view of Mantripragada in view of Delacourt in view of Bienkowski in view of Karve as applied to claims 7 above, and further in view Besbris
With regards to claim 8, the rejection of claim 7 is incorporated.
The combination of Bolik, Mantripragada, Delacourt, Bienkowski, and Karve teaches a query of the particular version of the blueprint but 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 particular 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 particular 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 particular 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 Mantripragada in view of Delacourt in view of Bienkowski 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, determining whether or not a version of the defined application meets quality assurance standards that correspond to dependency and prerequisites, as in Mantripragada, with a user request that triggers the delivery of code modules to instantiate and execute a build, as in Delacourt, and retrieving the versions of application software sequentially, as in Bienkowski, wherein the blueprint is a codified infrastructure that defines prerequisties that when fulfilled can deliver the code modules accordingly, as in Karve, 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 20 is rejected under 35 U.S.C. 103 as being unpatentable over Bolik in view of Mantripragada in view of Delacourt as applied to claim 17 above, and further in view of Besbris.
With regards to claim 20, the rejection of claim 17 is incorporated.
The combination of Bolik Mantripragada and Delacourt teaches identifying the fallback blueprint but does not teach: [wherein the identifying the fallback blueprint comprises] identifying a next newest blueprint of the software application in the blueprint data store.
However, in an analogous art Besbris teaches […] identifying a next newest blueprint of the software application in the blueprint data store. (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), and there are more versions of the service (918), then the host manager 404 accesses the service manifest [in the blueprint data store] 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 newest 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 Mantripragada 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, determining whether or not a version of the defined application meets quality assurance standards that correspond to dependency and prerequisites, as in Mantripragada, with a user request that triggers the delivery of code modules to instantiate and execute a build, as in Delacourt, 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]).
Response to Arguments
Applicant’s arguments with respect to claims 1-20 have been considered but are moot in view of the new ground of rejections (see the rejections above for the detailed explanation).
Conclusion
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