DETAILED ACTION
Claims 1, 3-12 and 14-22 are presented for examination. Claims 2 and 13 are cancelled. Claims 1, 4, 7, 12, 15 and 18 are amended. This office action is response to the submission on 3/29/2026.
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 .
Response to Arguments
With respect to 35 U.S.C. §112 Rejections:
Applicant’s arguments, see page 8 of applicant response filed 3/29/2026 with respect to claims 4 and 15 have been considered and are persuasive in light of the amendments to the claims. The 35 U.S.C. §112 (b) rejections of claims 4 and 15 have been withdrawn.
With respect to 35 U.S.C. §101 Rejections:
Applicant’s arguments, see page 8 of applicant response filed 3/29/2026 with respect to claims 1, 3-6, 9-12, 14-17 and 20-22 have been considered and are persuasive in light of the amendments to the claims. The 35 U.S.C. §101 rejections of claims 1, 3-6, 9-12, 14-17 and 20-22 have been withdrawn.
With respect to 35 U.S.C. §102 Rejections:
Applicant’s arguments, see page 8 of applicant response filed 3/2/2026 with respect to claims 1, 3-12 and 14-22 have been considered and are persuasive. Examiner agrees that Brown et al. (US20040225952A1) does not teach all of the claim limitations in light of the amendments. The 35 U.S.C. §102 rejections of claims 1, 3-12 and 14-22 have been withdrawn. Examiner notes that a rejection under 35 U.S.C. §103 is applied to these claims as indicated below.
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-22 are rejected under 35 U.S.C. 103 as being unpatentable over Brown et al. (US20040225952A1) in view of Chen (US20180157472A1).
Claim 1:
Brown teaches “A method for customizing orchestration of an industrial system infrastructure, the method comprising: receiving hardware user selections defining a plurality of hardware components of the industrial system infrastructure as a complete system;” (Brown teaches a service definition model which allows an architect to define applications that will be implemented by physical resources in Brown [0094] "The service definition model (SDM) provides tools and a context for an application architect to design distributed computer applications and data centers in an abstract manner. The model defines a set of elements that represent functional units of the applications that will eventually be implemented by physical computer resources and software. Associated with the model elements is a schema that dictates how functional operations represented by the components are to be specified."; Brown teaches that the architect may try placements of application elements onto virtual hardware elements in i.e. the architect defines hardware components in Brown [0799] "Once the applications and virtual data centers are architected using SDM semantics, the architect can logically try different logical placements of the application elements onto the virtual hardware elements. There can be different logical placements for different deployment environments (development, test, production, etc.). Logical placement can be done at design time, and requirements and constraints are checked and the developer is alerted of any errors or warnings. The result of the logical placement is captured in a separate file, with constraint checking being implemented using XPath and the XSD specified on each component, port and wire class. This is illustrated in FIG. 21. The designer may utilize a UI (user interface) for intuitive gestures when placing different application elements onto the physical elements."),
“receiving application user selections defining applications to be deployed on the plurality of hardware components;” (Brown teaches that the architect may try placements of application elements onto virtual hardware elements in i.e. the architect selects applications to be deployed on the hardware elements in Brown [0799] "Once the applications and virtual data centers are architected using SDM semantics, the architect can logically try different logical placements of the application elements onto the virtual hardware elements. There can be different logical placements for different deployment environments (development, test, production, etc.). Logical placement can be done at design time, and requirements and constraints are checked and the developer is alerted of any errors or warnings. The result of the logical placement is captured in a separate file, with constraint checking being implemented using XPath and the XSD specified on each component, port and wire class. This is illustrated in FIG. 21. The designer may utilize a UI (user interface) for intuitive gestures when placing different application elements onto the physical elements."),
“receiving policy user selections defining rules for deployment of the plurality of hardware components and applications;” (Brown teaches that the architect may provide constraints i.e. rules for deployment in Brown [0854-0855] "With the SDM model, developers, Network Architects, and Application Operators will have the ability to provide settings/constraints (Network Architect and developers), SDU mappings (developers), and deployment-time settings (Application Operators). These constraints and settings will be scoped per host (i.e. IIS, SQL, BizTalk) each with its own schema, rules, and values. Each host's exposed group of settings will be divided into those settable by the application and those reserved by the host. We refer to the former as application settings and latter as host settings. Furthermore, a host restricts the application settings by specifying ‘host constraints’, and an application gives prerequisites on host settings through ‘application constraints’. Restrictions may be on a setting's range of values, a specific value, or dependencies."; Brown teaches that the architect may annotate component types with policies for operation in Brown [0942] "The developer or an operations developer will be able to also add “operator intent” to the model by annotating component types in the model with policy and guidelines for operation, such as setting a minimum number of servers that must be running."),
“and causing generation of logic that defines a plan for deployment of the applications on the plurality of hardware components in compliance with the rules for deployment, wherein the logic is configured to guide deployment of the applications on the plurality of hardware components,” (Brown teaches that before an SDU is deployed, constraints are checked and the developer is alerted of any errors or warnings i.e. it checks whether the components are in compliance with the rules for deployment in Brown [0316] "Before an SDU can be deployed, we must first do a logical placement of the types on the target deployment environment. Logical placement can be done at design time. Requirements and constraints are checked and the developer is alerted of any errors or warnings. The result of the logical placement is captured in a separate file from the SDU. An SDU can be have different logical placements for different deployment environments (Development, Test, Production, etc.) Constraint checking is implemented using XPath and the XSD specified on each component, port and wire class." Brown teaches picking the target of deployment i.e. a plan for deployment of applications on hardware components and that placement is constrained by the logical placement in Brown [0322] "Physical placement is the act of picking the specific host instance that is the target of deployment. Physical placement is constrained by the logical placement. Constraints are revalidated during physical placement. See FIG. 26."; Brown teaches that architects provide constraints and the constraints will be scoped per host with its own rules in Brown [0854] "With the SDM model, developers, Network Architects, and Application Operators will have the ability to provide settings/constraints (Network Architect and developers), SDU mappings (developers), and deployment-time settings (Application Operators). These constraints and settings will be scoped per host (i.e. IIS, SQL, BizTalk) each with its own schema, rules, and values.), and
“and deploying the plurality of hardware components and applications according to the logic.” (Brown teaches packaging binaries i.e. applications for a distributed application in Brown [0313] "Component, port and wire types for a distributed application are packaged along with any binaries in an Service Deployment Unit (SDU). Binaries include all .DLLs, .EXE, config, static content, etc. SDU represents a portable, independently installable, distributed application. Analogous to the Windows Installer MSI file for Desktop applications. But, unlike desktop applications which primarily target a uniform environment (Windows), distributed applications. Can be hosted on different deployment environments that vary significantly. Must be able to express their requirements on the deployment environment. Must honor all policies of their deployment environment."; Brown teaches deploying an application to one or more servers in Brown [0694-0699] "An operator must be able to deploy a distributed application to one or more servers in a data center environment. The target servers must be part of an Active Directory domain or forest. The computer from which the test run deployment is initiated must be in the same domain or forest as the target server(s). 1. The application SDU is placed in a deployment folder on the computer where the SDM Runtime service is executing. 2. Operator chooses a deployment action (install, update, uninstall) and is prompted for domain credentials. 3. Operator is authenticated and mapped to a deployment role which determines whether the authenticated user is authorized to perform the requested deployment operation. 4. Operator selects which components to install, update or delete on which target servers. 5. The SDM Runtime service connects to the selected target servers as a trusted service account and performs the operations.").
Brown does not appear to explicitly teach “wherein the logic comprises a state machine comprising a digital representation of assets of the industrial system infrastructure;” However, Chen does teach this claim limitation (Chen teaches an application lifecycle director that includes a state machine which includes application states for the deployment of an application i.e. a digital representation of assets in Chen [0028] "In some embodiments, the application lifecycle director 123 may allow the configuration of a customized application lifecycle for the deployment of a specific application. The customized application deployment lifecycle may be in the form of a state machine 125, which may include a set of customized application states for the deployment of an application, as well as a corresponding set of permissible operations that can be performed when the application is in each of the customized application states. In other words, the state machine 125 may include a series of customized application states associated with the blueprint 122, a set of customized deployment operations, and relationships among the customized application states and the customized deployment operations."; Chen teaches deploying an application with a deployment plan based on a state machine in Chen [0033] "In some embodiments, if the application lifecycle director 123 determines that the deployment operation is allowed for the application in the specific current state, the application lifecycle director 123 may instruct (116) the deployment plan generator 124 to generate a deployment plan 126 for the application, based on the blueprint 122 (and optionally the state machine 125) associated with the application. After the deployment plan 126 is created, the deployment plan generator 124 may instruct (117) the deployment director 127 to execute the deployment plan 126 by communicating with the cloud broker 141.").
Brown and Chen are analogous art because they are from the same field of endeavor of deploying applications. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having teachings of Brown and Chen before him/her, to modify the teachings of Architecture for distributed computing system and automated design, deployment, and management of distributed applications of Brown to include the state machines of Chen because adding the Customized application state transition of Chen would allow for the state machine to determine whether deployment is possible as described in Chen [0054-0055] “At block 340, the application manager may determine whether the deployment operation is allowed based on the state machine and the current state. Specifically, the application manager may select a state operation from the plurality of state operations in the state machine using the deployment operation. In some embodiments, in response to a determination that the current state of the application is not a pre-state associated with the state operation, the application manager may determine that the deployment operation is not allowed, and the process 301 may proceed to block 350. Alternatively, in response to a determination that the current state of the application is a pre-state associated with the state operation, the application manager may determine that the deployment operation is allowed, and the process 301 may proceed to block 360. At block 350, in response to the determination that the deployment operation is not allowed, the application manager may generate a message as a response to the client request, indicating the performing of the deployment operation on the application in the cloud environment is not allowed according to the state machine.”
Claim 3:
Brown in view of Chen teaches “The method of claim 1, further comprising providing a graphical user interface (GUI) for receiving the hardware user selections, the application user selections, and the policy user selections, and the GUI allows a user to select the hardware user selections, application user selections, and policy user selections from one or more repositories of information.” (Brown teaches a GUI for the SDM server interface i.e. the GUI would allow for selecting the hardware, application, and policies in Brown [0748-0751] "The user interface for the SDM server will include: A wizard in Visual Studio that will provide a simple method to deploy, update or remove a test instance of an application. Command line tools to load SDM's, SDU's and instance requests. A complete UI that surfaces all the functionality of the object model and additionally provides graphical tools for composing Host models and instance requests."; Brown teaches that deployment environments are bulit including component, port, and wire types i.e. hardware user selections and in Brown [0318] "Deployment environments are built using the SDM model. See FIG. 22. In essence, they are SDM Applications at a different layer. Component, port and wire types are used in the same way to compose service hosts, network architectures, and hardware. In the Whidbey timeframe we will support deploying the application layer only. In ADS V2.0 we will be able to deploy the Service Host, Network and Hardware Layers. Visual studio is building a designer for authoring deployment environments. Visual Studio refers to this as the Logical Infrastructure Model. FIG. 23 illustrates an example deployment."; Brown teaches that architects provide constraints i.e. policy selections in Brown [0854] "With the SDM model, developers, Network Architects, and Application Operators will have the ability to provide settings/constraints (Network Architect and developers), SDU mappings (developers), and deployment-time settings (Application Operators). These constraints and settings will be scoped per host (i.e. IIS, SQL, BizTalk) each with its own schema, rules, and values.
PNG
media_image1.png
521
567
media_image1.png
Greyscale
).
Claim 4:
Brown in view of Chen teaches “The method of claim 1, wherein the hardware user selections define connections between hardware components and a topology which indicates how the hardware components are connected with each other.” (Brown teaches that the SDM captures the structure of the application, describing the topology of the service in Brown [0113] "Another way to think about the SDM is that it is both a meta-model for the behavior of distributed applications/services and a “live” blueprint of a running application/service in its computing environment. The SDM captures the structure of the application in its computing environment, including its allowable software operations, in a declarative and scale-invariant manner. The ability to declaratively describe the topology of a service, including the bindings between the hardware and network resources, and the valid operations of its software components, is quite powerful."; Brown teaches that deployment environments are built including component, port, and wire types i.e. hardware components and how they're connected in Brown [0318] "Deployment environments are built using the SDM model. See FIG. 22. In essence, they are SDM Applications at a different layer. Component, port and wire types are used in the same way to compose service hosts, network architectures, and hardware. In the Whidbey timeframe we will support deploying the application layer only. In ADS V2.0 we will be able to deploy the Service Host, Network and Hardware Layers. Visual studio is building a designer for authoring deployment environments. Visual Studio refers to this as the Logical Infrastructure Model. FIG. 23 illustrates an example deployment.").
Claim 5:
Brown in view of Chen teaches “The method of claim 1, further comprising performing a cross-validation process, which includes validating the hardware user selections, the application user selections, and the policy user selections in view of one another.” (Brown teaches validating a component's settings against a host's constraints in Brown [0195] "The ability to map from the application layer to the deployment layer (and so on) is quite powerful because it enables design-time validation of a component's settings against a host's constraints; and it also allows validation of a host's settings against a component's constraints."; Brown teaches validating between components in Brown [0198] "FIG. 8 shows how design-time validation would work between components at the different layers using the SDM settings and constraints semantics described previously."; Brown teaches checking constraints and requirements in Brown [0316] "Before an SDU can be deployed, we must first do a logical placement of the types on the target deployment environment. Logical placement can be done at design time. Requirements and constraints are checked and the developer is alerted of any errors or warnings. The result of the logical placement is captured in a separate file from the SDU. An SDU can be have different logical placements for different deployment environments (Development, Test, Production, etc.) Constraint checking is implemented using XPath and the XSD specified on each component, port and wire class."; Brown teaches that architects provide constraints and that the constraints are scoped per host in Brown [0854] "With the SDM model, developers, Network Architects, and Application Operators will have the ability to provide settings/constraints (Network Architect and developers), SDU mappings (developers), and deployment-time settings (Application Operators). These constraints and settings will be scoped per host (i.e. IIS, SQL, BizTalk) each with its own schema, rules, and values.).
Claim 6:
Brown in view of Chen teaches “The method of claim 5, further comprising prompting a user to revise one or more of the hardware user selections, the application user selections, and the policy user selections, followed by repeating the cross-validation process.” (Brown teaches that constraints are checked and the developer is alerted of any errors or warnings in Brown [0316] "Before an SDU can be deployed, we must first do a logical placement of the types on the target deployment environment. Logical placement can be done at design time. Requirements and constraints are checked and the developer is alerted of any errors or warnings. The result of the logical placement is captured in a separate file from the SDU. An SDU can be have different logical placements for different deployment environments (Development, Test, Production, etc.) Constraint checking is implemented using XPath and the XSD specified on each component, port and wire class."; Brown teaches that the architect can try different placements of application elements on the hardware elements i.e. after being alerted of a warning in Brown [0799] "Once the applications and virtual data centers are architected using SDM semantics, the architect can logically try different logical placements of the application elements onto the virtual hardware elements. There can be different logical placements for different deployment environments (development, test, production, etc.). Logical placement can be done at design time, and requirements and constraints are checked and the developer is alerted of any errors or warnings. The result of the logical placement is captured in a separate file, with constraint checking being implemented using XPath and the XSD specified on each component, port and wire class. This is illustrated in FIG. 21. The designer may utilize a UI (user interface) for intuitive gestures when placing different application elements onto the physical elements.").
Claim 7:
Brown in view of Chen teaches “The method of claim 1, further comprising optimizing the logic to best satisfy one or more optimization goals before outputting the logic.” (Brown teaches an operator providing a request to resolve an abstract description into real resources which optimizes the choice of resources in Brown [0794-0795] "When deploying a new application into the data center environment, operators create abstract description of the resources needed by the application. A request is to the services platform asking that the abstract description be resolved into real resources. The services platform works with the resource managers to locate resources that can fulfill the request, selects the resources which most economically fulfill the request, marks the resources as used, configures the resources to fit the request requirements, and places the concrete description of the allocated resources into the abstract description. As the application's needs change, the operator updates the resource description and asks the service platform to resolve the update application description. Individual resource providers can use hardware or OS specific software drivers that configure physical resources to meet application needs. Concepts associated with data center description include (1) a graph language for describe desired resources, resource requests, and granted resources; (2) a set of domain specific resource providers with knowledge of available resources of a given type and the ability to configure those resources to meet application requirements; and (3) a resource manager which processes resource requests, communicates with resource providers to find appropriate available resources, optional optimizes the choice of specific resources, asks the resource providers to configure the chosen resources, and updates the resource request to reflect the chosen resources.").
Claim 8:
Brown in view of Chen teaches “The method of claim 7, wherein the one or more optimization goals are included in the policy user selections.” (Brown teacheas a developer may set a minimum servers that must be running with the policy i.e. an optimization goal in Brown [0942] "The developer or an operations developer will be able to also add “operator intent” to the model by annotating component types in the model with policy and guidelines for operation, such as setting a minimum number of servers that must be running."; Brown teaches a resource manager which optimizes the choice of resources in Brown [0795] "Concepts associated with data center description include (1) a graph language for describe desired resources, resource requests, and granted resources; (2) a set of domain specific resource providers with knowledge of available resources of a given type and the ability to configure those resources to meet application requirements; and (3) a resource manager which processes resource requests, communicates with resource providers to find appropriate available resources, optional optimizes the choice of specific resources, asks the resource providers to configure the chosen resources, and updates the resource request to reflect the chosen resources.").
Claim 9:
Brown in view of Chen teaches “The method of claim 1, further comprising individually validating the hardware user selections, the application user selections, and/or the policy user selections.” (Brown teaches checking constraints and requirements in Brown [0316] "Before an SDU can be deployed, we must first do a logical placement of the types on the target deployment environment. Logical placement can be done at design time. Requirements and constraints are checked and the developer is alerted of any errors or warnings. The result of the logical placement is captured in a separate file from the SDU. An SDU can be have different logical placements for different deployment environments (Development, Test, Production, etc.) Constraint checking is implemented using XPath and the XSD specified on each component, port and wire class."; Brown teaches that architects provide constraints and that the constraints are scoped per host in Brown [0854] "With the SDM model, developers, Network Architects, and Application Operators will have the ability to provide settings/constraints (Network Architect and developers), SDU mappings (developers), and deployment-time settings (Application Operators). These constraints and settings will be scoped per host (i.e. IIS, SQL, BizTalk) each with its own schema, rules, and values.).
Claim 10:
Brown in view of Chen teaches “The method of claim 5, further comprising receiving notification of a problem associated with the industrial system infrastructure” (Brown teaches alerting the developer of errors and warnings in Brown [0316] "Before an SDU can be deployed, we must first do a logical placement of the types on the target deployment environment. Logical placement can be done at design time. Requirements and constraints are checked and the developer is alerted of any errors or warnings. The result of the logical placement is captured in a separate file from the SDU. An SDU can be have different logical placements for different deployment environments (Development, Test, Production, etc.) Constraint checking is implemented using XPath and the XSD specified on each component, port and wire class."), and
“and causing the cross- validation process to be repeated responsive to receipt of the notification of the problem, and causing the generation of the logic to be repeated.” (Brown teaches that the architect can try different placements of application elements on the hardware elements i.e. after being alerted of a warning in Brown [0799] "Once the applications and virtual data centers are architected using SDM semantics, the architect can logically try different logical placements of the application elements onto the virtual hardware elements. There can be different logical placements for different deployment environments (development, test, production, etc.). Logical placement can be done at design time, and requirements and constraints are checked and the developer is alerted of any errors or warnings. The result of the logical placement is captured in a separate file, with constraint checking being implemented using XPath and the XSD specified on each component, port and wire class. This is illustrated in FIG. 21. The designer may utilize a UI (user interface) for intuitive gestures when placing different application elements onto the physical elements.").
Claim 11:
Brown in view of Chen teaches “The method of claim 5, further comprising receiving an update to at least one of the hardware user selections, the application user selections, and the policy user selections, causing the cross-validation process to be repeated responsive to receipt of the update, and causing the generation of the logic to be repeated.” (Brown teaches that the architect can try different placements of application elements on the hardware elements and checks for errors in Brown [0799] "Once the applications and virtual data centers are architected using SDM semantics, the architect can logically try different logical placements of the application elements onto the virtual hardware elements. There can be different logical placements for different deployment environments (development, test, production, etc.). Logical placement can be done at design time, and requirements and constraints are checked and the developer is alerted of any errors or warnings. The result of the logical placement is captured in a separate file, with constraint checking being implemented using XPath and the XSD specified on each component, port and wire class. This is illustrated in FIG. 21. The designer may utilize a UI (user interface) for intuitive gestures when placing different application elements onto the physical elements."; Brown teaches that constraints are revalidated during physical placement i.e. after a user updates a hardware selection in Brown [0322] "Physical placement is the act of picking the specific host instance that is the target of deployment. Physical placement is constrained by the logical placement. Constraints are revalidated during physical placement. See FIG. 26."; Brown teaches that architects provide constraints and that the constraints are scoped per host in Brown [0854] "With the SDM model, developers, Network Architects, and Application Operators will have the ability to provide settings/constraints (Network Architect and developers), SDU mappings (developers), and deployment-time settings (Application Operators). These constraints and settings will be scoped per host (i.e. IIS, SQL, BizTalk) each with its own schema, rules, and values.).
Claim 12:
Brown in view of Chen teaches “A system for customizing orchestration of an industrial system infrastructure, the system comprising: a memory configured to store programmable instructions; and a processing device in communication with the memory,” (Brown teaches a service definition model which allows an architect to define applications that will be implemented by physical resources in Brown [0094] "The service definition model (SDM) provides tools and a context for an application architect to design distributed computer applications and data centers in an abstract manner. The model defines a set of elements that represent functional units of the applications that will eventually be implemented by physical computer resources and software. Associated with the model elements is a schema that dictates how functional operations represented by the components are to be specified."; Brown teaches that the invention relates to an architecture for a distributed computing system and management of distributed applications on the computing system i.e. it has a memory configured to store programmable instructions and a processing device in communication with the memory in Brown [0010] "The invention relates to an architecture for a distributed computing system and automated design, deployment, and management of distributed applications on the distributed computing system."),
“wherein the processing device, upon execution of the programmable instructions is configured to: receive hardware user selections defining a plurality of hardware components of the industrial system infrastructure as a complete system;” (Brown teaches that the architect may try placements of application elements onto virtual hardware elements in i.e. the architect selects applications to be deployed on the hardware elements in Brown [0799] "Once the applications and virtual data centers are architected using SDM semantics, the architect can logically try different logical placements of the application elements onto the virtual hardware elements. There can be different logical placements for different deployment environments (development, test, production, etc.). Logical placement can be done at design time, and requirements and constraints are checked and the developer is alerted of any errors or warnings. The result of the logical placement is captured in a separate file, with constraint checking being implemented using XPath and the XSD specified on each component, port and wire class. This is illustrated in FIG. 21. The designer may utilize a UI (user interface) for intuitive gestures when placing different application elements onto the physical elements."),
“receive application user selections defining applications to be deployed on the plurality of hardware components;” (Brown teaches a UI that allows the architect to describe the distributed application in Brown [0797] "Applications can likewise be defined using the SDM semantics. This is described above in more detail with reference to the SDM sections beginning in paragraph 0. FIG. 20 shows a graphical user interface (UI) that allows the architect to describe a large-scale distributed application in terms of SDM semantics."; Brown teaches deploying an application to one or more servers in Brown [0694-0699] "An operator must be able to deploy a distributed application to one or more servers in a data center environment. The target servers must be part of an Active Directory domain or forest. The computer from which the test run deployment is initiated must be in the same domain or forest as the target server(s). 1. The application SDU is placed in a deployment folder on the computer where the SDM Runtime service is executing. 2. Operator chooses a deployment action (install, update, uninstall) and is prompted for domain credentials. 3. Operator is authenticated and mapped to a deployment role which determines whether the authenticated user is authorized to perform the requested deployment operation. 4. Operator selects which components to install, update or delete on which target servers. 5. The SDM Runtime service connects to the selected target servers as a trusted service account and performs the operations."),
“receive policy user selections defining rules for deployment of the plurality of hardware components and applications;” (Brown teaches that the architect may provide constraints i.e. rules for deployment in Brown [0854-0855] "With the SDM model, developers, Network Architects, and Application Operators will have the ability to provide settings/constraints (Network Architect and developers), SDU mappings (developers), and deployment-time settings (Application Operators). These constraints and settings will be scoped per host (i.e. IIS, SQL, BizTalk) each with its own schema, rules, and values. Each host's exposed group of settings will be divided into those settable by the application and those reserved by the host. We refer to the former as application settings and latter as host settings. Furthermore, a host restricts the application settings by specifying ‘host constraints’, and an application gives prerequisites on host settings through ‘application constraints’. Restrictions may be on a setting's range of values, a specific value, or dependencies."; Brown teaches that the architect may annotate component types with policies for operation in Brown [0942] "The developer or an operations developer will be able to also add “operator intent” to the model by annotating component types in the model with policy and guidelines for operation, such as setting a minimum number of servers that must be running."),
“cause generation of logic that defines a plan for deployment of the applications on the plurality of hardware components in compliance with the rules for deployment, wherein the logic is configured to guide deployment of the applications on the plurality of hardware components,” (Brown teaches that before an SDU is deployed, constraints are checked and the developer is alerted of any errors or warnings i.e. it checks whether the components are in compliance with the rules for deployment in Brown [0316] "Before an SDU can be deployed, we must first do a logical placement of the types on the target deployment environment. Logical placement can be done at design time. Requirements and constraints are checked and the developer is alerted of any errors or warnings. The result of the logical placement is captured in a separate file from the SDU. An SDU can be have different logical placements for different deployment environments (Development, Test, Production, etc.) Constraint checking is implemented using XPath and the XSD specified on each component, port and wire class." Brown teaches picking the target of deployment i.e. a plan for deployment of applications on hardware components and that placement is constrained by the logical placement in Brown [0322] "Physical placement is the act of picking the specific host instance that is the target of deployment. Physical placement is constrained by the logical placement. Constraints are revalidated during physical placement. See FIG. 26."; Brown teaches that architects provide constraints and the constraints will be scoped per host with its own rules in Brown [0854] "With the SDM model, developers, Network Architects, and Application Operators will have the ability to provide settings/constraints (Network Architect and developers), SDU mappings (developers), and deployment-time settings (Application Operators). These constraints and settings will be scoped per host (i.e. IIS, SQL, BizTalk) each with its own schema, rules, and values.), and
“and deploying the plurality of hardware components and applications according to the logic.” (Brown teaches packaging binaries i.e. applications for a distributed application in Brown [0313] "Component, port and wire types for a distributed application are packaged along with any binaries in an Service Deployment Unit (SDU). Binaries include all .DLLs, .EXE, config, static content, etc. SDU represents a portable, independently installable, distributed application. Analogous to the Windows Installer MSI file for Desktop applications. But, unlike desktop applications which primarily target a uniform environment (Windows), distributed applications. Can be hosted on different deployment environments that vary significantly. Must be able to express their requirements on the deployment environment. Must honor all policies of their deployment environment."; Brown teaches deploying an application to one or more servers in Brown [0694-0699] "An operator must be able to deploy a distributed application to one or more servers in a data center environment. The target servers must be part of an Active Directory domain or forest. The computer from which the test run deployment is initiated must be in the same domain or forest as the target server(s). 1. The application SDU is placed in a deployment folder on the computer where the SDM Runtime service is executing. 2. Operator chooses a deployment action (install, update, uninstall) and is prompted for domain credentials. 3. Operator is authenticated and mapped to a deployment role which determines whether the authenticated user is authorized to perform the requested deployment operation. 4. Operator selects which components to install, update or delete on which target servers. 5. The SDM Runtime service connects to the selected target servers as a trusted service account and performs the operations.").
Brown does not appear to explicitly teach “wherein the logic comprises a state machine comprising a digital representation of assets of the industrial system infrastructure;” However, Chen does teach this claim limitation (Chen teaches an application lifecycle director that includes a state machine which includes application states for the deployment of an application i.e. a digital representation of assets in Chen [0028] "In some embodiments, the application lifecycle director 123 may allow the configuration of a customized application lifecycle for the deployment of a specific application. The customized application deployment lifecycle may be in the form of a state machine 125, which may include a set of customized application states for the deployment of an application, as well as a corresponding set of permissible operations that can be performed when the application is in each of the customized application states. In other words, the state machine 125 may include a series of customized application states associated with the blueprint 122, a set of customized deployment operations, and relationships among the customized application states and the customized deployment operations."; Chen teaches deploying an application with a deployment plan based on a state machine in Chen [0033] "In some embodiments, if the application lifecycle director 123 determines that the deployment operation is allowed for the application in the specific current state, the application lifecycle director 123 may instruct (116) the deployment plan generator 124 to generate a deployment plan 126 for the application, based on the blueprint 122 (and optionally the state machine 125) associated with the application. After the deployment plan 126 is created, the deployment plan generator 124 may instruct (117) the deployment director 127 to execute the deployment plan 126 by communicating with the cloud broker 141.").
Brown and Chen are analogous art because they are from the same field of endeavor of deploying applications. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having teachings of Brown and Chen before him/her, to modify the teachings of Architecture for distributed computing system and automated design, deployment, and management of distributed applications of Brown to include the state machines of Chen because adding the Customized application state transition of Chen would allow for the state machine to determine whether deployment is possible as described in Chen [0054-0055] “At block 340, the application manager may determine whether the deployment operation is allowed based on the state machine and the current state. Specifically, the application manager may select a state operation from the plurality of state operations in the state machine using the deployment operation. In some embodiments, in response to a determination that the current state of the application is not a pre-state associated with the state operation, the application manager may determine that the deployment operation is not allowed, and the process 301 may proceed to block 350. Alternatively, in response to a determination that the current state of the application is a pre-state associated with the state operation, the application manager may determine that the deployment operation is allowed, and the process 301 may proceed to block 360. At block 350, in response to the determination that the deployment operation is not allowed, the application manager may generate a message as a response to the client request, indicating the performing of the deployment operation on the application in the cloud environment is not allowed according to the state machine.”
Claims 14-22:
Claims 14-22 are substantially the same as claims 3-11 respectively and are rejected for the same reasons.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Thomsen et al. (US20230131783A1) teaches a state machine management system that deploys state machines for execution on industrial controllers (see Thomsen [0039]), which can configure a state machine which defines behavior of an automation system (see Thomsen [0044]), and it validates state machines before deployment (see Thomsen [0068]).
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 Zachary A Cain whose telephone number is (571)272-4503. The examiner can normally be reached Mon-Fri 7:00-3:30 CST.
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, Kenneth M Lo can be reached at (571) 272-9774. 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.
/Z.A.C./ Examiner, Art Unit 2116
/KENNETH M LO/ Supervisory Patent Examiner, Art Unit 2116
Prosecution Insights