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
Applicant's arguments filed 03/27/2026 have been fully considered but they are not persuasive.
On page 7, applicant argues that Bruun does not disclose "in response to the orchestration engine determining that a first rule of the set of orchestration rules is not consistent with the transition from the initial state to the proposed target state, modifying the proposed target state to be consistent with the first rule". Examiner respectfully disagrees. Bruun teaches applying dependency rules to possible state transitions. Bruun also teaches that application of dependency rules creates inter-service dependencies between state transitions. On paragraph [0078] Bruun teaches “ At operation 606, the computing device creates inter-service dependencies between state transitions corresponding to the various services within the set of services. In this implementation, the set of dependency rules are applied to the different types of relationships between the services.” Bruun also teaches in [0079-0080], detecting cyclic or conflicting transition arrangements and identifying the state transition that “should change” so that the graph becomes acyclic. Bruun expressly teaches [0084] “At operation 622, the computing device may modify one of the state transitions within the set of services and/or one of the relationships within the model. ”. Bruun defines a state transition function as computing a new state from an existing state and explains that a state transition includes an input and output state. See Bruun [0034]. Modifying the state transition reasonably encompasses modifying its resulting or target state. Bruun teaches applying orchestration rules, detecting that a proposed state transition is inconsistent or conflicting with those rules, modifying the transition and updating so that he resulting transition is rule consistent and executable. Murray is relied for the separately recited database limitation. Murray teaches that state transitions determined by the model and state manager are persisted via the state model. See Murray [0053]. Therefore, he combination of Bruun and Murray teaches the limitations of claim 1, 13 and 14.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 6, 9 and 12-17 are rejected under 35 U.S.C. 103 as being unpatentable over Bruun (US 20190312794 A1) in view of Murray (US 20230161643 A1).
Regarding claim 1, Bruun teaches:
A method, performed by a computing device, of orchestrating runs of a task or workflow, the method comprising. (Claim 1. A method, executable by a computing device, the method comprising:)
receiving, by an orchestration engine running on the computing device, a request from a run of a task or workflow to transition states from an initial state to a proposed target state. ([0047] FIG. 2C represents an example service with possible state transitions 204a-204e and inter-service dependencies 212a-212d to other services 214a-214c. In this example, based on building state model 202 as in FIG. 2A, planner 108 as in FIG. 1 applies a set of dependency rules to different types of relationships. The application of the dependency rules create inter-service dependencies 212a-212d. Inter-service dependencies 212a-212d are those dependencies created from the application of the set of dependency rules. These inter-service dependencies 212a-212d are those dependencies that exist between state transitions between the services. For example, assume the set of dependency rules relate to state transitions the given service to child and referenced services 214a-214c. In this example, the given service transition from state “checked” 204a to “designed” 204b creates inter-service dependency 212a that depends on a state transition (not illustrated) in other service 214a. In another example, the given state transition from “designed” 204b into “reserved” 204 has dependence 212b to other state transition (not illustrated) in other service 214a. Yet, in another example, state transition from “reserved” 204c into “provisioned” 204d has inter-service dependency 212c to state transition corresponding to other service 214a. In one more example, state transition for the given service from “provisioned” 204d into “active” 204e has inter-service dependency 212d to state transition corresponding to other service 214a. The set of dependency rules may be explained in detail in later figures.)
assessing, by the orchestration engine with reference to a set of orchestration rules, whether the run is permitted to transition from the initial state to the proposed target state; and. ([0042] Orchestration plan 114 is produced by planner 108 upon creation of the inter-service dependencies. Orchestration plan 114 lists the sequenced order of the state transitions for the system to keep the system in FIG. 1 in a consistent state without interruption or downtime. In one implementation, orchestration plan 114 is developed from a directed graph. In this example, planner 108 applies a linear-time algorithm that provides a topological sorting for the state transitions for the set of services. As such, orchestration plan 114 prioritizes the state transitions for the set of services. [0048] Planner 108 applies dependency rules 312 which are specific to the different types of relationships. By applying dependency rules 312, planner 108 creates inter-service dependencies between the given service and other services as represented by 210. Creating the inter-service dependencies, planner 108 obtains a directed graph (not illustrated). Examples of the directed graph are discussed in later figures. Using the directed graph, planner 108 may apply a topological sorting algorithm 322 to obtain a list of state transitions for execution by 316. The list of state transitions is developed by the orchestration plan (not illustrated). The orchestration plan includes the sequenced order of state transitions for execution. E.N.: Dependency rules determine if and when a transition is permitted this is directly analogous to “assessing whether the run is permitted” )
returning permission to the run to transition states. ([0048] FIG. 3 illustrates an example system architecture to develop an orchestration plan of state transitions for a set of services for execution by executor 316. Using model 206 that shows how service 208 relates to other services via different types of relationships (e.g., parent, sibling, child, referrer, pre-requisite, references, etc.). Impact model 314 may develop model 216 that is used by planner 108. Planner 108 applies dependency rules 312 which are specific to the different types of relationships. By applying dependency rules 312, planner 108 creates inter-service dependencies between the given service and other services as represented by 210. Creating the inter-service dependencies, planner 108 obtains a directed graph (not illustrated). [0074] At operation 506, the computing device develops the orchestration plan that includes the sequenced order of state transitions for the set of services. In an implementation, based on applying the set of dependency rules for the different types of relations, inter-service dependencies are created between the state transitions.)
and in response to the orchestration engine determining that a first rule of the set of orchestration rules is not consistent with the transition from the initial state to the proposed target state, modifying the proposed target state to be consistent with the first rule. ([0077] At operation 604, the computing device builds the MTOSI model. Building the MTOSI model, is a visual representation that represents an initial state and possible state transitions for each service within the set of services. The MTOSI model which implements interfaces between operation support systems (OSSs). MTOSI models may be used by service providers to manage complex networks. In this manner, since various parts of the network interact, the MTOSI model implements the corresponding OSSs. The MTOSI model provides a visual depiction of the inter-relatedness between each of the services within the set services. Based on building the MTOSI model, the computing device proceeds to apply a set of dependency rules to the different types of relationships as at operation 606. [0078] At operation 606, the computing device creates inter-service dependencies between state transitions corresponding to the various services within the set of services. In this implementation, the set of dependency rules are applied to the different types of relationships between the services. Upon application of the set of dependency rules, this creates inter-service dependencies between the state transitions for each of the services within the set of services. Further note, [0084] At operation 622, the computing device may modify one of the state transitions within the set of services and/or one of the relationships within the model. In response to this modification, modifications to other services may be cascaded throughout the set of services. In turn, the computing device updates the directed graph and the orchestration plan accordingly as at operation 624. [0085] At operation 624, in response to modifying one of the state transitions and/or relationships, the computing device provides the updated directed graph. From the updated graph that includes the possible state transitions, the computing device develops the updated orchestration plan. The updated orchestration plan includes the updated sequence of order of the state transitions within the set of services. Based on the updated orchestration plan, the computing device may proceed to execute the updated state transitions. E.N.: Bruun teaches based on the rules, one could modify state transitions and thereby state so the conflict is removed.)
Bruun does not appear to explicitly teach: in response to the orchestration engine determining that the run is permitted to transition states, writing the state change to a database and
However, Murray teaches: [0037] The resource object and state model system 230 is shown including a model and state manager 235, an object model 236, a state model 238, a notifier 232, a provisioner 233, a reservation system 234, a pool manager 237. In an implementation, the object model 236 and the state model 238 may be implemented in GO (a statically typed, compiled programming language), deployed as stateless Kubernetes pods for scalability, accessed via representational state transfer (REST) API calls, and persisted in a database. [0053] FIG. 4 shows a diagram illustrating a state model 400 in accordance with an example. The state model 400 represents a non-limiting example of the state model 238 of FIG. 2. The state model 400 may be used by a NEM (e.g., NEM 210) to represent the current state of logical resource objects (e.g., nodes and pools of nodes). In one example, state transitions within the state model 400 are determined by the model and state manager, persisted via the state model, and then used to trigger: (i) infrastructure plugin functionality, notifications to workloads (e.g., workloads 104), for example, via application orchestration tools, and (iii) potentially additional orchestrations.
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Bruun and Murray before them, to include Murray’s state persistence using a database with Bruun’s orchestration system. One would have been motivated to make such a combination to ensure reliable tracking of approve transitions and support distributed orchestration across network devices.
Regarding claim 2, Bruun teaches:
The method of claim 1, wherein assessing includes iterating through the set of orchestration rules, bypassing rules of the set of orchestration rules that are not relevant to the proposed transition of the run of the task or workflow from the initial state to the proposed target state. ([0046] FIG. 2B represents an example service 208 with different types of relationships (e.g., parent, sibling, referrers, references, prerequisites, etc.). The arrows indicate the relationship of given service 208 to those other services. For example, there is a parent service to given service 108, while another service is a sibling to given service 208. The model is developed as in FIG. 2A that also includes the different types of relationships between given service 208 and other services. Depending on the type of relationship, a set of dependency rules may be applied to the different types of relationships to create inter-service dependencies as illustrated in FIG. 2C. See also [0055-0064])
Regarding claim 3, Bruun teaches:
The method of claim 2, wherein a rule of the set of orchestration rules is deemed to not be relevant in response to determining that that rule does not cover a transition from the initial state to the proposed target state. ([0047] For example, assume the set of dependency rules relate to state transitions the given service to child and referenced services 214a-214c. In this example, the given service transition from state “checked” 204a to “designed” 204b creates inter-service dependency 212a that depends on a state transition (not illustrated) in other service 214a. In another example, the given state transition from “designed” 204b into “reserved” 204 has dependence 212b to other state transition (not illustrated) in other service 214a. Yet, in another example, state transition from “reserved” 204c into “provisioned” 204d has inter-service dependency 212c to state transition corresponding to other service 214a. In one more example, state transition for the given service from “provisioned” 204d into “active” 204e has inter-service dependency 212d to state transition corresponding to other service 214a. The set of dependency rules may be explained in detail in later figures.)
Regarding claim 4, Bruun teaches:
The method of claim 3, wherein a rule of the set of orchestration rules is further deemed to not be relevant in response to determining that either: the run is of a workflow, and that rule applies only to runs of tasks; or the run is of a task, and that rule applies only to runs of workflows. ([0047-0048] FIG. 3 illustrates an example system architecture to develop an orchestration plan of state transitions for a set of services for execution by executor 316. Using model 206 that shows how service 208 relates to other services via different types of relationships (e.g., parent, sibling, child, referrer, pre-requisite, references, etc.). Impact model 314 may develop model 216 that is used by planner 108. Planner 108 applies dependency rules 312 which are specific to the different types of relationships. By applying dependency rules 312, planner 108 creates inter-service dependencies between the given service and other services as represented by 210. Creating the inter-service dependencies, planner 108 obtains a directed graph (not illustrated). Examples of the directed graph are discussed in later figures. Using the directed graph, planner 108 may apply a topological sorting algorithm 322 to obtain a list of state transitions for execution by 316. The list of state transitions is developed by the orchestration plan (not illustrated). The orchestration plan includes the sequenced order of state transitions for execution.)
Regarding claim 6, Bruun teaches:
The method of claim 2, wherein iterating through the set of orchestration rules includes applying each rule of the set of orchestration rules that is relevant to the proposed transition to determine whether that rule is consistent with the transition from the initial state to the proposed target state.. ([0048] [0048] FIG. 3 illustrates an example system architecture to develop an orchestration plan of state transitions for a set of services for execution by executor 316. Using model 206 that shows how service 208 relates to other services via different types of relationships (e.g., parent, sibling, child, referrer, pre-requisite, references, etc.). Impact model 314 may develop model 216 that is used by planner 108. Planner 108 applies dependency rules 312 which are specific to the different types of relationships. By applying dependency rules 312, planner 108 creates inter-service dependencies between the given service and other services as represented by 210. Creating the inter-service dependencies, planner 108 obtains a directed graph (not illustrated).)
Regarding claim 9, Bruun teaches:
The method of claim 2, wherein the method further includes, after writing the state change to the database and prior to returning permission to the run to transition states, determining whether the rules of the set of orchestration rules that were previously deemed to be relevant to the proposed transition are still relevant. ([0074] At operation 506, the computing device develops the orchestration plan that includes the sequenced order of state transitions for the set of services. In an implementation, based on applying the set of dependency rules for the different types of relations, inter-service dependencies are created between the state transitions. Based on the inter-service dependencies, the computing device computes the directed graph that includes a node for each service and state transition for its respective service. From the directed graph, the computing device may proceed to develop the orchestration plan. The orchestration plan lists the sequenced order of state transitions. This means that each state transition is illustrated to indicate which service state transitions should be executed before other service state transitions. In a further implementation, one of the relationships may be modified and/or state transitions of the service. In this implementation, the directed graph and the orchestration plan are updated to reflect the modification.)
Regarding claim 12, Bruun teaches:
The method of claim 1, wherein: the run operates on another computing device across a network; the request is received from the other computing device via the network; and the permission is sent to the other computing device via the network. ([0036] The foregoing disclosure describes a number of example implementations for determining a sequence of actions to perform based on a modification to a service in a graph. The disclosed examples may include systems, devices, computer-readable storage media, and methods for detecting the member suffering the soft failure. For purposes of explanation, certain examples are described with reference to the components illustrated in FIGS. 1-8. The functionality of the illustrated components may overlap, however, and may be present in a fewer or greater number of elements and components. Further, all or part of the functionality of illustrated elements may co-exist or be distributed among several geographically dispersed locations. Moreover, the disclosed examples may be implemented in various environments and are not limited to the illustrated examples.)
Regarding claim 13, the claim recites similar limitation as corresponding claim 1 and is rejected for similar reasons as claim 1 using similar teachings and rationale.
Regarding claim 14, the claim recites similar limitation as corresponding claim 1 and is rejected for similar reasons as claim 1 using similar teachings and rationale.
Regarding claim 15, Bruun teaches:
The method of claim 1, wherein modifying the proposed target state to be consistent with the first rule is performed while the run is being executed. ([0084] At operation 622, the computing device may modify one of the state transitions within the set of services and/or one of the relationships within the model. In response to this modification, modifications to other services may be cascaded throughout the set of services. In turn, the computing device updates the directed graph and the orchestration plan accordingly as at operation 624.[0083] At operation 620, the computing device proceeds to execute each of the state transitions for the set of services. The computing device executes the state transitions as specified in the orchestration plan, in the sequenced order provided by the orchestration plan. This means the computing device executes the state transitions in the order provided by the orchestration plan. Executing the sequenced order of the state transitions prevents conflicting state transitions that may occur with the set of services. E.N.: Bruun begins executing the state transitions at operation 620, modifies a state at 622, updates and continues to execute the orchestration plan at 624. These steps occur while the orchestration run is being executed.)
Regarding claim 16, the claim recites similar limitation as corresponding claim 15 and is rejected for similar reasons as claim 15 using similar teachings and rationale.
Regarding claim 17, the claim recites similar limitation as corresponding claim 15 and is rejected for similar reasons as claim 15 using similar teachings and rationale.
Claims 5, 8, 10 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Bruun (US 20190312794 A1) in view of Murray (US 20230161643 A1) and in further view of Sijelmassi (US 8667491 B2).
Claims 5, Bruun does not appear to explicitly teach:
The method of claim 3, wherein a rule of the set of orchestration rules is further deemed to not be relevant in response to determining that that rule is designated as applying only after a state change has been assessed.
However, Sijelmassi teaches: (col 5, line 8-24. Construct 1: When transitioning from lane L1 to lane L2. Referring to FIG. 3A, in this example, P and Q may be user defined steps that are executed by computer 30 whenever the main workflow transitions from lane L1 to lane L2. In this case, the transition from lane L1 to lane L2 is a specific starting point, after whose occurrence computer 30 executes steps P and Q. Construct 2: When transitioning from any lane to lane L2 (or on entering lane L2). Referring to FIG. 3B, in this example, R and STOP may be user defined steps that need to be executed by computer 30 based on the decision box whenever the main workflow first enters lane L2. The execution of the main flow by computer 30 may not resume if STOP is encountered. In this case, the transition from any lane to lane L2 is another specific starting point, after whose occurrence computer 30 executes steps R or STOP based on decision box?. E.N.: the transition triggers rules , meaning they do not apply before the state is change)
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Bruun and Sijelmassi before them, to include Sijelmassi’s transition trigger rule execution with Bruun’s orchestration system. One would have been motivated to improve workflow logic and ensure that certain rules are applied only after a state change has been assessed.
Regarding claim 8, Sijelmassi teaches:
The method of claim 6 wherein iterating through the set of orchestration rules further includes, prior to applying that rule, applying logic of a pre-transition hook associated with that rule. (col 2, line 43-50. Workflow engine 32 may interpret the semantics of the workflow and execute the steps of the workflow. To this end, workflow engine 32 may manage the loading, initiation, and progression of a workflow at run-time. In addition, workflow engine 32 may also determine when a Swim Lane needs to be changed. Upon determining that a Swim Lane needs to be changed, workflow engine 32 may invoke lane change handler 34. Col 2, line 60 – col 3, line 5 When the main workflow is in the initiation state, workflow engine 32 may determine the starting point of the workflow and complete the starting point. In addition, workflow engine 32 may complete the required house keeping for the flow. As workflow engine 32 processes each step, the results of the processed step may be stored for further processing. As such, workflow engine 32 may periodically check to see if the step that was initiated has completed and the results of the step has been stored. If so, workflow engine 32 may retrieve the results of the step. Workflow engine 32 may then evaluate all outgoing links to determine the qualifying target steps by comparing the results of a source step against predefined link definitions. E.N.: this logic executes before applying a transition rule (before invoking constructs for P, Q, R, W etc.) it is analogous to “pre-transition hook logic” ).
Refer to claim 5 for the motivation to combine.
Regarding claim 10, Sijelmassi teaches:
The method of claim 9, wherein the method further includes, in response to determining that a rule of the set of orchestration rules is not still relevant to the proposed transition, nullifying pre-transition logic associated with that rule. (col 5, line 15-24. Construct 2: When transitioning from any lane to lane L2 (or on entering lane L2). Referring to FIG. 3B, in this example, R and STOP may be user defined steps that need to be executed by computer 30 based on the decision box whenever the main workflow first enters lane L2. The execution of the main flow by computer 30 may not resume if STOP is encountered. In this case, the transition from any lane to lane L2 is another specific starting point, after whose occurrence computer 30 executes steps R or STOP based on decision box?. E.N.: )
Refer to claim 5 for the motivation to combine.
Regarding claim 11, Sijelmassi teaches:
The method of claim 9, wherein the method further includes, in response to determining that a rule of the set of orchestration rules is still relevant to the proposed transition, applying logic of a post-transition hook associated with that rule prior to applying that rule again. (col 5, line 7-14 Construct 1: When transitioning from lane L1 to lane L2. Referring to FIG. 3A, in this example, P and Q may be user defined steps that are executed by computer 30 whenever the main workflow transitions from lane L1 to lane L2. In this case, the transition from lane L1 to lane L2 is a specific starting point, after whose occurrence computer 30 executes steps P and Q. col 5, line 25-31 Construct 3: When transitioning from lane L1 to any lane (or on leaving Lane L1). Referring to FIG. 3C, in this example, W may be a user defined step that may be executed by computer 30 whenever the main workflow first leaves lane L1. In this case, the transition from lane L1 to any other lane is another specific starting point, after whose occurrence computer 30 executes step W. E.N.: These are examples of posy-transition hooks).
Refer to claim 5 for the motivation to combine.
Conclusion
THIS ACTION IS MADE FINAL. 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.
THIS ACTION IS MADE FINAL. 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 CARLOS A ESPANA whose telephone number is (703)756-1069. The examiner can normally be reached Monday - Friday 8 a.m - 5 p.m EST.
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, LEWIS BULLOCK JR can be reached at (571)272-3759. 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.
/C.A.E./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights