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 .
DETAILED ACTION
This Office Action is in response to the amendment filed 11/12/2025.
Claims 1-8 are pending in this application.
Claims 1 and 8 are independent claims.
Claims 1, 2, 4, 7 and 8 are currently amended.
This Office Action is made final.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1-8 are rejected under 35 U.S.C. 112(b), as being indefinite for failing to particularly point out and distinctly claim the subject matter which applicant regards as the invention.
The examiner appreciates the attorney’s effort in addressing some of the 112 issues in the previous office action. There is still a great deal of ambiguity in the claim language. The examiner believes a complete rewrite of the independent claims is needed in order to clarify the main points of the invention.
In claim 1, one sees the term “switching, when a job uncompleted whose execution by the first job execution module has not been completed exists” The word exists is not necessary and is a grammatical mistake.
The applicant has argued that there two steps here (1) switching the destination when an uncompleted job exists, and (2) retrying the job after failure detection post-switch.
The switching we see in this limitation “switching, when a job whose execution by the first job execution module has not been completed exists, a destination to which an execution request to execute a job is sent, from the first execution control module to the second execution control module”.
Despite grammatical problems, this is clear enough. This is migration from the first to the second module before the job is complete (failure or preemption)
The next limitation “issuing, to the first job execution module, an inquiry about a status of a job for which execution has been instructed to the first job execution module” is confusing. If the job has been transferred to the second job execution module, then the inquiry should be sent there and not to the “first job execution module” or if sent there the “first execution module” should relay this to the second one (this is where the job is running). If there is a relay of messages, this step needs to be added and support for it shown in the specification.
The last limitation covers the retry step. One sees “wherein, when execution of a job whose execution by the first job execution module has not been completed is determined to be a failure”. Again this is confusing. This is assumed to be a failure on the “second execution module” where the job is currently running. If so that needs to be added. The next step is even more confusing “an execution request to execute a job is sent is switched to the second execution control module, an execution request to execute the job is sent to the second execution control module”. The examiner will assume this is a retry attempt on the first module after detecting failure on the second module. The claim is not at all clear about that. Rather than emphasize where messages are sent, the examiner would appreciate more clarity about where the job is and where it is going and when and why?
Claim 8 has the same problem and is rejected for the same reasons.
The remaining claims, not specifically mentioned, are rejected for being dependent upon one of the claims above.
Claim Rejections - 35 USC § 103
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 of this title, 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 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Katou (US 2013/0219224 A1) in view of Sirota (US 2010/0153955 A1) in further view of Pollimera (US 2021/0342237 A1).
As per claim 1, Katou teaches A job management system, comprising:
at least one processor; (Katou [0070] The job execution units 301 and 302 are equipment which carries out jobs. They may be usual processors, or may be virtual servers such as the active-system virtual servers 10 and 11 in the first exemplary embodiment).
at least one memory device storing instructions which, when execute by the at least one processor, cause the at least one processor to perform operations comprising:
executing a first execution control module to instruct, in response to reception of an execution request to execute a job, a first job execution module to execute the job; (Katou [0027] The active-system virtual servers 10 and 11 are virtual servers built by the host server 1, and the names of server 1 and server 2 are given by the host server 1, respectively. The active-system virtual servers 10 and 11 are virtual servers which carry out jobs at a time of a usual operation, and include a job execution units 100 and 110, and local memories 101 and 111, respectively. The local memories 101 and 111 store programs and data of jobs which the job execution units 100 and 110 execute, respectively).
executing a second execution control module to instruct, in response to reception of an execution request to execute a job, a second job execution module to execute the job; outputting one execution request to execute a job at a time to the first execution control module; (Katou [0028] Similarly, the standby-system virtual server 12 is a virtual server built by the host server 1, and the name of server 3 is given by the host server 1. The standby-system virtual server 12 does not carry out jobs at a time of an usually operation, and, when a failure occurs in any one of the active-system virtual servers 10 and 11, and jobs cannot be carried out any more by the failed server, takes the jobs over from the failed server and continues execution of the stopped jobs. The standby-system virtual server 12 includes a job execution unit 120 and a local memory 121. The local memory 121 stores programs and data of jobs which the job execution unit 120 executes).
switching, when a job whose execution by the first job execution module has not been completed exists, a destination to which an execution request to execute a job is sent, from the first execution control module to the second execution control module; (Katou [0010] a job continuation management unit that refers to the job management information memory unit when a failure occurs in one of the job execution units, and, about records having identification information of the job execution unit identical with identification information of the job execution unit of failure origin, sends the job identification information and the job execution information to one of the job execution units except for a job execution unit of the failure origin sequentially in a order starting from a job having highest the job continuing execution priority to lowest, and making the job execution unit of a receiving party perform continuation execution of the job) and
Katou does not teach issuing, to the first job execution module, an inquiry about a status of a job for which execution has been instructed to the first job execution module.
However, Sirota teaches issuing, to the first job execution module, an inquiry about a status of a job for which execution has been instructed to the first job execution module (Sirota Fig 2A Block 210f shows job status and [0036] In this example, the master node 205 maintains various execution state information 210 regarding the distributed execution of Program X, such as to track the status of execution of execution jobs on each of the computing nodes 230. In particular, in this example, each line or entry in the information 210 corresponds to the performance of a particular operation for a particular execution job on a particular computing node, with information being tracked that in this example includes an identification 210a of the computing node, of the execution job 210b, of the operation 210c, of the status of performance of the operation 210f, of input data to be used by the operation 210d, of output data to be produced by the performance of the operation 210e, and optionally of various other information 210g. Such other status information may include, for example, information about dependencies or other inter-relationships between operations (e.g., operation B cannot be executed until after operation A is completed, operations C and D are to be executed simultaneously, etc.), information about expected completion of performance of an operation being performed (e.g., an expected completion time, an expected amount of time until completion, a percentage completion of an operation, a percentage of the operation that remains to be performed, etc.), information about expected initiation of performance of operations that are not yet being performed, etc.)
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Sirota with the system of Katou to issue an inquiry about a status of a job. One having ordinary skill in the art would have been motivated to use Sirota into the system of Katou for the purpose of separating the program execution into multiple distinct execution jobs that may each be executed on a distinct computing node (Sirota paragraph 08)
Kato and Sirota do not teach wherein, when execution of a job whose execution by the first job execution module has not been completed is determined to be a failure based on a result of the inquiry after the destination to which an execution request to execute a job is sent is switched to the
second execution control module, an execution request to execute the job is sent to the second execution control module.
However, Polimera teaches wherein, when execution of a job whose execution by the first job execution module has not been completed is determined to be a failure based on a result of the inquiry after the destination to which an execution request to execute a job is sent is switched to the second execution control module, an execution request to execute the job is sent to the second execution control module (Polimera [0381] The above-recited system wherein the disaster recovery orchestration job is for an unplanned failover of the first virtual machine to the second virtual machine, based on using administrative settings in the storage manager….. Initiate a second disaster recovery orchestration job that causes the second virtual machine to fail back to the first virtual machine, wherein the second disaster recovery job causes a first virtualization manager to re-activate the first virtual machine and establishes in the primary storage the first datastore of the re-activated first virtual machine based on a snapshot replicated from the failover storage and [claim 6] wherein the first computing device is further configured to: initiate a second disaster recovery orchestration job that causes the second virtual machine to fail back to the first virtual machine, wherein the second disaster recovery orchestration job causes a first virtualization manager to re-activate the first virtual machine and establishes in the primary data storage the first datastore of the re-activated first virtual machine based on a snapshot replicated from the failover data storage.)
The examiner is treating the above limitation to be a failure on the second execution unit and switch back (a retry) on the first execution unit. Please refer to the 112 rejection above for the reasons behind this interpretation.
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Polimera with the system of Katou and Sirota to failback to the first execution module. One having ordinary skill in the art would have been motivated to use Polimera into the system of Katou and Sirota for the purpose of implementing disaster recovery (DR) orchestration of virtual machine (VM) failover and failback operations (Polimera paragraph 04)
As per claim 2, Sirota teaches wherein the operations further comprise stopping issuance of an inquiry to the first job execution module after success or failure of execution has been determined based on a result of the inquiry, for every job instructed to the first job execution module. (Sirota Fig 2A Block 210f shows job status and [0036] In this example, the master node 205 maintains various execution state information 210 regarding the distributed execution of Program X, such as to track the status of execution of execution jobs on each of the computing nodes 230. In particular, in this example, each line or entry in the information 210 corresponds to the performance of a particular operation for a particular execution job on a particular computing node, with information being tracked that in this example includes an identification 210a of the computing node, of the execution job 210b, of the operation 210c, of the status of performance of the operation 210f, of input data to be used by the operation 210d, of output data to be produced by the performance of the operation 210e, and optionally of various other information 210g. Such other status information may include, for example, information about dependencies or other inter-relationships between operations (e.g., operation B cannot be executed until after operation A is completed, operations C and D are to be executed simultaneously, etc.), information about expected completion of performance of an operation being performed (e.g., an expected completion time, an expected amount of time until completion, a percentage completion of an operation, a percentage of the operation that remains to be performed, etc.), information about expected initiation of performance of operations that are not yet being performed, etc. see also Fig 4A Block 440 which shows the process of checking the status of every single job and then Block 485 which shows producing the final results (i.e. stopping the checking process) )
As per claim 3, Sirota teaches wherein the operations further comprise ending the issuing of an inquiry in response to confirmation, based on a result of the inquiry, that execution has ended for every job for which execution has been instructed to the first job execution module. (Sirota 0076] After block 515, the routine continues to block 520 to send a status message to the routine 400 indicating that the execution of the selected operation has begun, and in block 525 initiates the performance of the operation. In block 530, the routine waits for the completion of the performance of the operation, and optionally locally stores any intermediate results produced by the operation performance. In block 535, the routine then sends another status message to the routine 400 indicating that the performance of the operation is completed. In block 540, the routine then determines whether there are more operations to be performed, and if so returns to block 515).
As per claim 4, Katou teaches wherein the operations further comprise: receiving an execution request to execute a job from an operation support system; storing job data indicating the job, and acquiring one piece of the stored job data at a time, wherein outputting the execution request comprises outputting, in response to acquisition of a piece of the job data, an execution request to execute a job indicated by the piece of the job data to the first execution control module, before the destination to which an execution request to execute a job is output is switched to the second execution control module, and wherein outputting the execution request comprises outputting, in response to acquisition of a piece of the job data, an execution request to execute a job indicated by the piece of the job data to the second execution control module, after the destination to which an execution request to execute a job is sent is switched to the second execution control module. (Katou [0026] The host server 1 configures a virtual server system and includes active-system virtual servers 10 and 11, a standby-system virtual server 12, a virtual server monitoring unit 13, a shared memory 14 and a job continuation management unit 15. [0030] The shared memory 14 is a memory which is being managed by the host server 1 directly, and it is also accessible from the active-system virtual servers 10 and 11 and the standby-system virtual server 12. The shared memory 14 stores a copy of the programs and data of jobs executed by the active-system virtual servers 10 and 11 and the standby-system virtual server 12. [0031] The shared memory 14 includes a job management information memory unit 140. The job management information memory unit 140 stores job management information 141 which is management information about each job being carried out by the active-system virtual servers 10 and 11. [0033] The shared memory 14 also stores machine management information 142 which is management information on the system. [0040] Upon receiving an instruction of continuing execution of job 1 from the job continuation management unit 15, the job execution unit 120 of the standby-system virtual server 12 loads the program of the job processing engine "addition" and the input data NUM1 (I) and NUM2 (I) into the local memory 121 from the shared memory 14, and begins continuing execution of the job starting from I=5. [0043] Upon receiving the instruction of continuing execution of job 2 from the job continuation management unit 15, the job execution unit 120 loads the program of the job processing engine "multiplication" and the input data NUM1 (I) and NUM2 (I) into the local memory 121 from the shared memory 14, and begins continuing execution of the job starting from I=3. [0051] The job execution unit 120 loads data needed for continuing execution of the job directed by the job continuation management unit 15 from the shared memory 14 into the local memory 121, starts continuing execution of the job, and, when job execution is completed, reports it to the job continuation management unit 15 (S108). The job continuation management unit 15 eliminates the record about the job for which information of execution completion has been received from the job management information 141, and the processing returns to S102 (S 109)).
As to claim 8, it is rejected based on the same reason as claim 1.
Claims 5 and 6 are rejected under 35 U.S.C. 103 as being unpatentable over Katou (US 2013/0219224 A1) in view of Sirota (US 2010/0153955 A1) in further view of Pollimera (US 2021/0342237 A1) and Mares (US 2010/0153955 A1).
As per claim 5, Katou and Sirota and Pollimera do not teach wherein the operations further comprise notifying, to the operation support system, success, or failure of execution of a job that is determined based on a result of the inquiry.
However, Mares teaches wherein the operations further comprise notifying, to the operation support system, success, or failure of execution of a job that is determined based on a result of the inquiry. (Mares [0159] A completed job can also have an exit code, which will identify if the administrative or other command has succeeded, failed or succeeded with warnings, for example SUCCESS--the command is successfully completed; FAILURE--the command is completed and execution failed; or WARNING--the command is completed and there was a warning [0160] When a command is first started by the client, it is in an EXECUTING state. If the command has finished execution of the command then its state is changed to COMPLETED state, and the exit code is set to SUCCESS, FAILURE or WARNING. The time the command finished execution is stored for later housekeeping).
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Mares with the system of Katou and Sirota and Pollimera to determine success or failure of a job. One having ordinary skill in the art would have been motivated to use Mares into the system of Katou and Sirota and Pollimera for the purpose of supporting fault tolerant job management in a cloud environment. (Mares paragraph 03)
As per claim 6, Sirota teaches wherein notifying comprises notifying, to the operation support system, during a period in which an inquiry is issued to the first job execution module and an inquiry to the second job execution module, success or failure of execution of a job that is determined based on a result of an inquiry issued to the first job execution module and success or failure of execution of a job that is determined based on a result of an inquiry issued to the second job execution module. (Sirota Fig 2A Block 210f shows job status for multiple nodes and jobs and [0036] In this example, the master node 205 maintains various execution state information 210 regarding the distributed execution of Program X, such as to track the status of execution of execution jobs on each of the computing nodes 230. In particular, in this example, each line or entry in the information 210 corresponds to the performance of a particular operation for a particular execution job on a particular computing node, with information being tracked that in this example includes an identification 210a of the computing node, of the execution job 210b, of the operation 210c, of the status of performance of the operation 210f, of input data to be used by the operation 210d, of output data to be produced by the performance of the operation 210e, and optionally of various other information 210g. Such other status information may include, for example, information about dependencies or other inter-relationships between operations (e.g., operation B cannot be executed until after operation A is completed, operations C and D are to be executed simultaneously, etc.), information about expected completion of performance of an operation being performed (e.g., an expected completion time, an expected amount of time until completion, a percentage completion of an operation, a percentage of the operation that remains to be performed, etc.), information about expected initiation of performance of operations that are not yet being performed, etc.)
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Katou (US 2013/0219224 A1) in view of Sirota (US 2010/0153955 A1) and in further view of Pollimera (US 2021/0342237 A1) and Mares (US 2010/0153955 A1) and Helleren (US 2010/0153955 A1).
As per claim 7, Katou and Sirota and Pollimera do not teach wherein, when execution of a job whose execution by the first job execution module has not been completed is determined to be a failure based on a result of the inquiry after the destination to which an execution request to execute a job is sent is switched to the second execution control module, outputting the execution request comprises outputting an execution request to execute the job to the second execution control module, without notifying the failure of the execution of the job to the operation support system.
However, Helleren teaches wherein, when execution of a job whose execution by the first job execution module has not been completed is determined to be a failure based on a result of the inquiry after the destination to which an execution request to execute a job is sent is switched to the second execution control module, outputting the execution request comprises outputting an execution request to execute the job to the second execution control module, without notifying the failure of the execution of the job to the operation support system (Helleren [0249] After an orphaned job is accepted by a surviving instance, the surviving instance can use stored recovery data to start processing the accepted job. For example, the recovery data can optionally include data describing the last successful operation performed by a job before machine or instance failure. The recovery data can also indicate where or how the surviving instance can access messages or job inputs related to the failed job that took place after the failure occurred. The instance can then access and replay these messages to begin the recovery process. In certain embodiments, the recovery data can include or indicate where a snapshot of the job prior to failure can be accessed. Additionally, the instances can be configured to ensure that the instance that was running the job when it failed does not attempt to accept or restart the job. [0250] After an instance determines that it should accept a failed job, the job is recovered. After accepting a failed job, an instance can notify the synchronization device that it has accepted the job so the synchronization device can update its records and data accordingly).
Paragraph 250 of Helleren teaches that the instance accepts the failed job and then informs the synchronization device and not the other way around (being informed by the synchronization job to accept the failed job). The examiner is interpreting this according to what is disclosed in the specification ([0014] Further, when execution of a job uncompleted by the first job execution module is determined to be a failure based on a result of the inquiry after the destination to which an execution request to execute a job is output is switched to the second execution control means, the execution request output means may be configured to output an execution request to execute the job to the second execution control means, without the notification means notifying the failure of the execution of the job to the operation support system).
It would have been obvious to a person in the ordinary skill in the art before the filing date of the claimed invention to combine Helleren with the system of Katou and Sirota and Pollimera and Mares to send switch notification to a second device. One having ordinary skill in the art would have been motivated to use Helleren into the system of Katou and Sirota and Pollimera and Mares for the purpose of implementing fault tolerance systems to help ensure application and/or system uptime and reliability. (Helleren paragraph 01)
Response to Arguments
Applicant's arguments filed on 11/12/2025 have been fully considered but they are not persuasive.
Applicant’s arguments with respect to claims 1 and 8 have been considered but are moot because the arguments do not apply because of the introduction of new art by Polimera.
The applicant has argued that “In Katou, jobs are transferred only after a failure occurs in a job execution unit, and there is no teaching or suggestion of switching execution requests while jobs are still pending or being executed. As such, Katou fails to teach or suggest preemptive switching of jobs prior to a failure”. There is nothing in the claim language that suggests preemption. It just says the job is incomplete. This could be due to failure which leaves the job incomplete or preemption. In fact the word “preemption” does not appear in the specification. The abstract suggests the switch is due to a failure “When execution of a job uncompleted by the first job execution module (14a) is determined to be a failure based on a result of the inquiry after the destination to which an execution request to execute a job is output is switched to the second execution control module (32b)”
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MEHRAN KAMRAN whose telephone number is (571)272-3401. The examiner can normally be reached on 9-5.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor April Blair, can be reached on (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.
/MEHRAN KAMRAN/Primary Examiner, Art Unit 2196