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
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 05/12/2026 has been entered.
Claims 1-8 are presented for examination.
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.
The examiner will proceed limitation by limitation to show how confusing the claim language is. First we find the following limitations “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; 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” .
This is badly worded. What does “executing a first execution control module to instruct” mean in this context?. These two limitations imply there are two servers or nodes (job execution modules) that can execute a job. These needs to be clearly stated.
Next we find “outputting one execution request to execute a job at a time to the first execution control module”. The term “outputting” throws the reader off. This is basically saying “the first execution module executes the job”.
Next we see “switching, when a job whose execution by the first job execution module has not been completed, 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”. This is somewhat clearer, this is migration of a job that is incomplete from the first to the second module. In this regard the applicant has stated “Applicant respectfully submits that the claimed embodiment of claim 1 enables seamless switching of job execution modules by: (1) switching the destination for new execution requests while uncompleted jobs still exist at the first module”.
The claim limitation does not have the word “new” in it but the examiner will treat it as such. The word incomplete basically means running not finished. If the aim is to say “new”, “incomplete” can almost mean the opposite. Is this “new assignment” or “migration” of an existing job. The applicant’s comments are different than what is claimed. The applicant then continues “(2) continuing to monitor those uncompleted jobs that "remain at the first job execution module" after the switching; and (3) re-executing failed jobs on the second module instead of the first”. and
The re-execution part (last limitation) is clear enough.
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 § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1 and 8 are rejected under 35 U.S.C. 102(a)(1) as anticipated by He (US 2014/0181825 A1)
As per claim 1, He teaches A job management system, comprising: ( He Fig 1)
at least one processor; (He [0034] 102 can implement the processing
modules 104 as processing cores of one or more CPUs).
at least one memory device storing instructions which, when executed 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; 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; (He [0011] FIG. 2 illustrates a scenario in which the scheduling module of FIG. 1 assigns jobs to three different processing modules having different respective performance levels (e.g., "sizes" [0048] Starting with FIG. 2, this figure illustrates a scenario in which the scheduling module 118 assigns jobs to three different processing modules having respective performance levels. The processing module A [first execution control module] has the lowest performance level, the processing module C has the highest performance level [second execution control module], and the processing module B has a performance level that is between the levels of modules A and B. The performance levels may correspond to the speeds at which the processing modules can perform their operations. That is, the processing module A is the slowest, but consumes the least energy, while the processing module C is the fastest, but consumes the most energy. The processing modules A, B, and C can be informally referred to as small, medium, and large modules, respectively.).
outputting one execution request to execute a job at a time to the first execution control module; switching, when a job whose execution by the first job execution module has not been completed, 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; (He [0055] FIG. 3 is a procedure 300 which generalizes the operations of FIG. 2 in flowchart form. In block 302, the scheduling module 118 determines whether a new job has been received. In block 304, the scheduling module 118 determines whether a processing module is currently available. If so, in block 306, the scheduling module 118 assigns the new job to the highest-performing processing module that is currently available [second execution module]. If not, in block 308, the scheduling module 118 stores the new job in the job queue 120)
after the switching, continuing to issue, to the first job execution module, an inquiry about a status of a job that remains at the first job execution module and for which execution was instructed to the first job execution module before the switching, (He [0056] the scheduling module 118 determines whether there is an in-progress job on a lower-performing processing module (e.g., a smaller processing module) [first job execution module]).
wherein, when execution of a job, for which execution was instructed to the first job execution module before the switching is determined to be a failure based on a result of the inquiry, an execution request to re-execute the job is sent to the second execution control module. (He [0064] In block 610, the scheduling module 118 determines whether there is an in-progress job on a lower-performing processing module that has a level of urgency which exceeds a prescribed urgency threshold (U.sub.thresh). For example, the scheduling module 118 can perform this test by determining whether any in-progress job has been running on a lower-performing processing module for more than a prescribed amount of time without completing [failure of job]. If so, in block 612, the scheduling module 118 determines whether there is a higher-performing processing module that is available. And if so, in block 614, the scheduling module 118 moves the in-progress job to the highest-performing processing module that is currently available [second execution module]).
As to claim 8, it is rejected based on the same reason as claim 1.
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 2 and 3 are rejected under 35 U.S.C. 103 as being unpatentable over He (US 2014/0181825 A1) in view of Sirota (US 2010/0153955 A1).
As per claim 2, He does not teach 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.
However, 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) )
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 He to stop issuance of an inquiry. One having ordinary skill in the art would have been motivated to use Sirota into the system of He 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)
As per claim 3, He does not teach 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.
However 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).
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 He to stop issuance of an inquiry. One having ordinary skill in the art would have been motivated to use Sirota into the system of He 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)
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over He (US 2014/0181825 A1) in view of Katou (US 2013/0219224 A1)
As per claim 4, He does not teach 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.
However, 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)).
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 Katou with the system of He to store job data. One having ordinary skill in the art would have been motivated to use Katou into the system of He for the purpose of continuing execution of jobs which have been being carried out at the time of a system failure (Katou paragraph 02)
Claims 5 is rejected under 35 U.S.C. 103 as being unpatentable over He (US 2014/0181825 A1) in view of Katou (US 2013/0219224 A1) and in further view of Mares (US 2010/0153955 A1).
As per claim 5, He and Katou 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 He and Katou 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 He and Katou for the purpose of supporting fault tolerant job management in a cloud environment. (Mares paragraph 03)
Claims 6 is rejected under 35 U.S.C. 103 as being unpatentable over He (US 2014/0181825 A1) in view of Katou (US 2013/0219224 A1) and in further view of Mares (US 2010/0153955 A1) and Sirota (US 2010/0153955 A1).
As per claim 6, He and Katou and Mares do not teach 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.
However 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.)
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 He and Katou and Mares to stop issuance of an inquiry. One having ordinary skill in the art would have been motivated to use Sirota into the system of He and Katou and Mares 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)
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over He (US 2014/0181825 A1) in view of Katou (US 2013/0219224 A1) and in further view of Mares (US 2010/0153955 A1) and Helleren (US 2010/0153955 A1).
As per claim 7, He and Katou and Mares 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 He and Katou 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 He and Katou 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 05/12/2026 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 He.
The applicant has used the word “seamless” quite a bit in the arguments section (example Applicant respectfully submits that the claimed embodiment of claim 1 enables seamless switching of job execution modules and “this enables seamless switching without waiting for jobs to complete or transferring them to the second module”).
The examiner does not see any meaningful connection between assignment or migration of jobs from the first to the second module and continuing the monitoring process on the first module to look for more job failures. These are two distinct steps and one does not see the connection here. The applicant has remarked “This enables seamless switching by allowing failed jobs from the old module to be retried on the new module, as described in the specification. (See As-Filed Specification, page 29, line 7-15)”
You are simply retrying failed jobs on a machine. This is taught in He.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20170068603 A1 – discloses a job net including a plurality of jobs to be executed in parallel using a shared file, a shared file determination unit determines whether a file used by the jobs is a shared file, a checkpoint management unit sets a checkpoint when the job writes data into a file that was determined to be a shared file, a file copy processing unit creates a replication of the shared file used by the jobs, a process copy processing unit creates a replication of a process of the jobs, and a job execution control unit determines, upon detecting an abnormal state in an active job, a checkpoint from where processing of the job is to be resumed, and resumes the job by using the replication of the shared file and the replication of the process which were created when the checkpoint was set.
US 20160054781 A1 – discloses one or more processors of a distributed computer system to perform operations including determining whether a power consumed by the distributed computer system is greater than a power allocated to the distributed computer system, responsive to determining the power consumed by the distributed computer system is greater than the power allocated to the distributed computer system, determining whether all jobs being processed by the distributed computer system are processing at a lowest power state for each job, wherein a job includes one or more calculations performed by the one or more processors of the distributed computer system and responsive to determining all jobs being processed by the distributed computer system are processing at a lowest power state for each job, suspending a job having a lowest priority among all jobs being processed by the distributed computer system is shown.
US 20110154332 A1 – discloses when hardware failure occurs in an operation device, a provisional job executing unit of a virtual machine is allowed to temporarily execute a job until setup of a spare device as an alternative job execution device is completed. Start of operation of the virtual machine is performed in a short time by shift from a suspending state to an operating state. Therefore, execution of the job is not stopped by the hardware failure of the operation device and it is possible to improve continuity of the job and improve reliability of a redundant configuration of the job execution device in which the spare device is associated with the operation device.
US 20080307258 A1 – discloses recovery of an instance of a job manager running on one of a plurality of nodes used to execute the processing elements associated with jobs that are executed within a cooperative data stream processing system. The states of the processing elements are checkpointed to a persistence mechanism in communication with the job manager. From the checkpointed processing element states, the state of each distributed job is determined and checkpointed. Processing element states are also checkpointed locally to the nodes one which the processing elements are running. Following a failure of the job manager, the job manager is reinstantiated on one of the nodes. The recovery instance of the job manger obtains state data for processing elements and jobs from the persistence mechanism and constructs an initial state for jobs and processing elements. These initial states are reconciled against the current states of the processing elements and adjustments are made accordingly. Once the job and processing element states are reconciled, the system is returned to normal operation.
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
Prosecution Insights