DETAILED ACTION
Claims 1-3, 5-11, 13-18 and 20-21 are pending. Applicant has amended claims 1, 5, 8, 9, 13, 16, 17, 20, cancelled claims 4, 12, 19 and added new claim 21.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/5/2025 has been entered.
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-3, 5, 7-11, 13, 15-18 and 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over Montagut (US 8,000,991 B2) in view of Spivak et al. (US 9,015,710 B2) further in view of Mitevski et al. (US 11,599,382 B2).
As to claim 1, Montagut teaches a system (a computer or processing device; col. 20, line 22) comprising:
a processor (a processor; col. 20, line 33); and
a memory device including instructions that are executable by the processor for causing the processor to (memory; col. 20, lines 22-30):
receive (receiving a message representing an incoming routing activity; col. 2, lines 62-63), by a process engine distributed across a plurality of nodes of a distributed computing environment (a distributed system … devices 220, 240, 260, 280 … a part of the workflow management infrastructure may also be deployed on each device. Therefore, each one of the devices comprises a workflow engine 210, 230, 250 and 270 executing on the device; col. 8, lines 9-27), a description of a process comprising a plurality of deployment units (The workflow W may therefore be a finite set of task activities; col. 7, lines 40-42 and col. 11, lines 55-59), the process associated with a graph representing a plurality of tasks to be performed to complete the process (In the graphical workflow model, each circle-shaped vertex represents at least part or all workflow actions contiguously performed by a device, whereas the edges 130 represent the sequence of workflow operations among devices. The following activities associated with a graph definition are distinguished: task activities comprising or consisting of actions performed by devices participating in the workflow … task activities; col. 7, lines 5-28);
deploy, by the process engine, the plurality of deployment units in the distributed computing environment (sending one or more messages representing a routing activity to the one or more next local devices thus identified; col. 3, 4-5 and the deployment of runtime mechanism … global process definition W to enable a device to retrieve W expressed in BPEL to execute a given index; col. 13, lines 13-18 and Deploying a BPEL process; col. 14, lines 11-35); and
cause, by the process engine, an action associated with an execution of one or more deployment units of the plurality of deployment units (an executing component configured to execute task activities comprised by the generated local part on the device; col. 4, lines 16-17 and execute on the device the required task activities corresponding to the current vertex; col. 8, lines 31-32) subsequent to deploying the plurality of deployment units (a method for executing a workflow, a discovery of all local devices may be enabled at the workflow initialization phase; col. 3, lines 65-67 and A distributed system 200 on which a pervasive workflow may be executed in a distributed manner … the workflow management task is distributed among part or all involved devices 220. As a result, a part of the workflow management infrastructure may also be deployed on each device; col. 8, lines 9-18).
Montagut does not teach the description including, for each deployment unit, a manifest specifying at least one task of the plurality of tasks and an identifier of a communication channel associated with the deployment unit, configured, by the process engine, the communication channel for each deployment unit based on the manifest; and present state information associated with the execution of the plurality of deployment units at a user interface.
However, Spivak teaches, in the same field of endeavor, the description including, for each deployment unit, a manifest specifying at least one task of the plurality of tasks and an identifier of a communication channel associated with the deployment unit (“administrative client 304 provides a deployment manifest, associated with the release, that describes a desired computing environment of cloud computing platform application 200 after cloud computing platform application 200 has been deployed. The deployment manifest describes attributes of the desired computing environment Such as a number of resource pools (e.g., groups of VMs) to be utilized, networks to be setup, and other settings, as will be described later, and functions as a specification for deployment in this embodiment”; col. 5, lines 31-41; DNS, port; col. 10, lines 39-42 and Tables 1 and 2; and “In one embodiment, deployment manifest 402 includes a “properties' section that provides enables a system administrator to parameterize these configuration file templates. As such, when deployment director 320 deploys cloud computing platform application 200, deployment director 320 may parse the configuration file templates and “fill in the appropriate parameters based on the corresponding values provided in “properties' section. For example, a router job may have a configuration file that lists a login credential for the router service as variables (“<$users>,” “<$passwords>”). In such an example, deployment director 320 parses out and evaluates the variables based on “user:' and “password:” name-value pairs provided in the properties section. Table 2 lists an example configuration file template embodied as a Ruby on Rails script file (e.g., ERB template) that may be parsed by deployment director 320.”; col. 11, lines 35-49), and configured, by the process engine, the communication channel for each deployment unit based on the manifest (“Based on deployment manifest 402, deployment director 320 generates a logical infrastructure 350 comprising one or more resource pools (identified as resource pools 404 and 404 in FIG. 4) that associate stem cell VMs with a stem cell (e.g., VM template) and a network. For example, a resource pool labeled “small is associated with a stem cell specified as “bosh-stemcell” version 0.2.39 and with the “management” network defined within deployment manifest 402. A stem cell refers to a VM template that defines a generalized software infrastructure that supports execution of a job provided by deployment director 320 and as specified by deployment manifest 402. In some embodiments, the stem cell is a VM template that includes an agent 322 installed on a guest operating system 406, and any supporting runtimes, frameworks, and libraries for the agent 322. Each resource pool may be assigned a size corresponding to a number of stem cell VMS 324 to be provisioned for the resource pool. For example, deployment director 320 provisions 14 stem cell VMs for the “small” resource pool. Deployment manifest 402 may include pass-through settings for infrastructure platform 308 for provisioning resource pools 404; col. 10, lines 46-66; and col. 12, line 64 – col. 13, line 38).
It would have been obvious to one of ordinary to art before the effective filing date of the claimed invention to apply the teaching of Spivak to the system of Montagut because Spivak teaches a method that provides the ability to deploy a multimode distributed application that eliminate the complex and time-consuming for a system administrator to manage (col. 2, lines 6-24).
Mitevski teaches present state information associated with the execution of the plurality of deployment units at a user interface (The task represent works work that should be performed. For each task, an execution context is created. The example execution context holds information about data associated with the task and information about progress of the task execution … to send feedback to a user and/or other system … the client receives notifications from the task dispatcher and updates an associate user interface to provide feedback regarding the execution of the tasks; col. 8, lines 25-56).
It would have been obvious to one of ordinary to art before the effective filing date of the claimed invention to apply the teaching of Mitevski to the system of Montagut and Spivak because Mitevski teaches a method that reports the execution progress of the task and the result of executing the task, thus provide the user with information regarding the task execution progress.
As to claim 2, Montagut as modified by Spivak and Mitevski teaches
receive, subsequent to deploying the plurality of deployment units, a command to execute the process (an executing component configured to execute task activities comprised by the generated local part on the device; col. 4, lines 16-17 and execute on the device the required task activities corresponding to the current vertex; col. 8, lines 31-32);
determine a first deployment unit of the plurality of deployment units that is to be executed subsequent to a second deployment unit of the plurality of deployment units and prior to a third deployment unit of the plurality of deployment units based on the description (See Fig. 7 or Fig. 1, and A more complex example of a process representation is provided using distBPEL … in the workflow depicted in Fig. 7; col. 15, line 11 – col. 16, line 13, in which vertex 102 and 103 are deployed and executed after vertex 101 execution completed and before vertex 104 deployed and executed as shown in Fig. 1, and similar in Fig. 7);
receive, from the second deployment unit subsequent to executing the second deployment, an indication of an end of an execution phase of the second deployment unit (Once the local part W is completed; col. 11, line 29-30); and
cause, in response to receiving the indication, the action by triggering the execution of the first deployment unit (the Data D … is sent to the identified device 270; col. 11, lines 29-42).
As to claim 3, Montagut as modified by Spivak and Mitevski teaches receive, subsequent to deploying the plurality of deployment units, a command to execute the process (see Montagut: an executing component configured to execute task activities comprised by the generated local part on the device; col. 4, lines 16-17 and execute on the device the required task activities corresponding to the current vertex; col. 8, lines 31-32); determine that the process is incomplete; and cause the action by outputting a report indicating that the process is incomplete (see Mitevski: failure; col. 9, lines 9-18).
As to claim 5, Montagut as modified by Spivak and Mitevski teaches receive, by the process engine, a message associated with a first deployment unit of the plurality of deployment units; and send the message to a second deployment unit of the plurality of deployment units, the second deployment unit configured to propagate the message to the first deployment unit via the communication channel (col. 11, lines 4-42).
As to claim 7, Montagut as modified by Spivak and Mitevski teaches wherein the action comprises creating a process instance of the process by performing the execution of the plurality of deployment units (col. 5, lines 24-31 and an executing component configured to execute task activities comprised by the generated local part on the device; col. 4, lines 16-17 and execute on the device the required task activities corresponding to the current vertex; col. 8, lines 31-32), manipulating a lifecycle of the process instance by starting, stopping, resuming, or restarting the process instance, manipulating a property associated with the process instance by adjusting a runtime state of the process during execution of the plurality of deployment units, or tracing the execution of the plurality of deployment units through execution associated with the process (an executing component configured to execute task activities comprised by the generated local part on the device; col. 4, lines 16-17 and execute on the device the required task activities corresponding to the current vertex; col. 8, lines 31-32).
As to claim 8, Montagut as modified by Spivak and Mitevski teaches wherein the description comprises a business process model and notation file defining the graph associated with the process (see Montagut: graph; col. 7, lines 9-28 and BPEL; col. 11, lines 43-46 and 55-62); and wherein each deployment unit of the plurality of deployment units comprises a containerized service including the at least one task of the plurality of tasks of the process (see Spivak: VM, container: col. 14, lines 1-22).
As to claim 9, it is the same as the system of claim 1 above except this is a method claim, and therefore is rejected under the same ground of rejection.
As to claims 10, 11, 13 and 15-16, see rejections of claims 2, 3, 5 and 7-8 above, respectively.
As to claim 17, it is the same as the system of claim 1 above except this is a non-transitory computer-readable medium claim, and therefore is rejected under the same ground of rejection.
As to claims 18 and 20, see rejections of claims 2 and 5 above, respectively.
As to claim 21, Montagut as modified by Spivak and Mitevski teaches wherein the state information is associated with the execution of each deployment unit of the plurality of deployment units, and wherein the state information indicates an execution status of the one or more tasks for each deployment unit (see Spivak: health monitor; col. 4, lines 32-36, and col. 7, lines 39-55) and (see Mitevski: col. 8, lines 37-53 and col. 9, lines 1-28).
Claims 6 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Montagut (US 8,000,991 B2) in view of Spivak et al. (US 9,015,710 B2) and Mitevski et al. (US 11,599,382 B2) further in view of Branson et al. (US 2013/0124726 A1).
As to claim 6/14, Montagut as modified by Spivak and Mitevski does not teach determine that a deployment unit of the plurality of deployment units receives a number of requests above a threshold; and cause a node of the distributed computing environment executing the deployment unit to be scaled up based on the number of requests being above the threshold.
However, Branson teaches adjusting/upscale/downscale resources assigned to executing task/job/request/application based on the performance (paragraphs [0036]-[0038]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the teaching of Montagut because Branson teaches a method that the system can dynamically allocate more resources to a process as needed or reclaim resources from processes that are idle, thus, would improve the performance of the system.
Response to Arguments
Applicant’s arguments with respect to claims 1-3, 5-11, 13-18 and 20-21 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DIEM K CAO whose telephone number is (571)272-3760. The examiner can normally be reached Monday-Friday 8:00am-4:00pm.
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, April Blair can be reached at 571-270-1014. 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.
/DIEM K CAO/Primary Examiner, Art Unit 2196
DC
December 26, 2025