Prosecution Insights
Last updated: October 23, 2026
Application No. 18/798,267

DYNAMIC JOB ROUTING AND DATA CONSOLIDATION

Non-Final OA §101§103§112
Filed
Aug 08, 2024
Examiner
HUYNH, ANTHONY DUC
Art Unit
2198
Tech Center
2100 — Computer Architecture & Software
Assignee
Microsoft Technology Licensing, LLC
OA Round
1 (Non-Final)
Grant Probability
Favorable
1-2
OA Rounds

Examiner Intelligence

Grants only 0% of cases
0%
Career Allowance Rate
0 granted / 0 resolved
-55.0% vs TC avg
Minimal +0% lift
Without
With
+0.0%
Interview Lift
resolved cases with interview
Typical timeline
Avg Prosecution
3 currently pending
Career history
4
Total Applications
across all art units
This examiner has no resolved cases yet (career too new); statute-level performance unavailable. The Grant Probability card shows Tech Center averages instead.

Office Action

§101 §103 §112
DETAILED ACTION This communication is in response to the application filed on August 8, 2024 in which claims 1-20 are pending in the application. Claims 1, 10, and 17 are in independent form. 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 . Information Disclosure Statement The information disclosure statement (IDS) submitted on August 13, 2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. The information disclosure statement (IDS) submitted on October 17, 2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner. Drawings The drawings are objected to because FIG. 6 labels “Step 304” and “Step 306” is inconsistent with the specification where they are referred to as “step 204” (Paragraph 0095) and “step 206” (Paragraph 0096). Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance. Specification The disclosure is objected to because of the following informalities: Paragraph [0031] recites “in job request 154” which it appears “in job request 150” was intended. It also recites “account configuration 154” which it appears “account configuration 152” was intended. Paragraph [0038] recites “resource manager 126” which it appears “resource manager 120” was intended. Paragraph [0041] recites “memory of node 182” which it appears “memory of node 180” was intended. Paragraph [0057] recites “the migration status” multiple times which it appears “the migration state” was intended. Paragraph [0059] recites “a indicating” which it appears “an indication” was intended. Paragraph [0072] recites “. provider system 110In” which is not understood. Paragraph [0072] recites “configuration response 208” which it appears “configuration response 308” was intended. Paragraph [0080] recites “from one architect” which it appears “from one architecture” was intended. Paragraph [0082] recites “to router 102” which it appears “to gateway 102” was intended. Paragraph [0086] recites “first job request the second” which it appears “first job request to the second” was intended. Paragraph [0156] recites “wired interface(s) 1360” which it appears “wired interface(s) 1380” was intended. Appropriate correction is required. Claim Objections Claim objected to because of the following informalities: In claim 2, “route the second job” should read “routes the second job” Appropriate correction is required. Claim Rejections - 35 USC § 112 7. 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. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. Claims rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 1 recites the limitation “the processor circuit.” There is insufficient antecedent basis for this limitation in the claim. Claim 1 earlier introduces “a processor” but it is unclear if the limitation is referring to the processor or a separate component. For examination purposes, “the processor circuit” is interpreted to be “the processor.” Claim 1 also recites the limitation “and a migration state is enabled”. It is unclear within the context of the claim as a whole if the limitation refers to the job router “determines a migration state is enabled”, or the migration status “indicates a migration state is enabled”, or both. It is not clear if “migration state” and “migration status” are being used interchangeably. For examination purposes, “and a migration state is enabled” is interpreted as the job router “determines a migration state is enabled”. Claim 8 recites the limitation “the distributed cache”. There is insufficient antecedent basis for this limitation in the claim. Claim 8 earlier introduces “a cache” and it is unclear if the applicant is referring to the cache or a separate “distributed cache.” For examination purposes, “the distributed cache” is interpreted as “the cache”. Claim 12 recites the limitation “the migration state.” There is insufficient antecedent basis for this limitation in the claim. Claim 10, from which claim 12 depends, recites “a migration status” and it is unclear if the limitation refers to a separate element or if “migration status” is being used interchangeably with “migration state.” For examination purposes, “the migration state” is interpreted as “a migration state”. Claim 17 recites “the first job service architecture” and “the second job service architecture.” There is insufficient antecedent basis for these limitations in the claim. The limitations refer to elements that were not previously introduced in the claim, so it is unclear what the limitations are referring to. For examination purposes, “the first job service architecture” is interpreted as “a first job service architecture” and “the second job service architecture” is interpreted as “a second job service architecture.” Claims 2-4, and 8, which depend from claim 1, claims 5-7, which depend from claim 4, claim 9, which depend from claim 8, and claims 18-20, which depend from claim 17, inherit the indefinite limitations of their respective independent claims and are similarly rejected. Claim 16 recites a similar limitation to claim 8 and is similarly rejected. Claim Rejections - 35 USC § 101 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 1- 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception without significantly more. Step 1: Claims 1-9 are directed to a system and therefore is a machine which is one of the statutory categories of inventions. Claims 10-16 are directed to a method (series of steps) and therefore is a process which is one of the statutory categories of inventions. Claims 17-20 are directed to a computer-readable storage medium which the specification explicitly defines as physical hardware media disavowing media under signals per se (Paragraph 0155) and therefore is a manufacture which is one of the statutory categories of inventions. Step 2A, Prong 1: Claims 1, 10, and 17 recite the limitation “determin[ing] a migration status of the user account.” This limitation as drafted, under its broadest reasonable interpretation, covers performance of the limitation in the mind, but for recitation of generic computer components. That is, other than reciting “a job router”, nothing in the claim element precludes the step from practically being performed in a human mind or with the aid of pen and paper. For example, “determining” in the context of this claim encompasses a person such as an account manager mentally, and with the aid of pen and paper writing down a list of labels associated with user accounts and evaluate which label is assigned based on the user account. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, then it falls within the “mental processes” grouping of abstract ideas (concepts performed in the human mind including observation, evaluation, judgment, and opinion.) (MPEP 2106.04(a)(2)(III)). Step 2A, Prong 2: The claims recite additional elements: “Receiv[ing] a first job request associated with a user account”, receiving data is a limitation which amounts to data gathering which is considered to be insignificant extra solution activity (MPEP 2106.05(g)). “Rout[ing] the first job request to the second job service architecture”, routing data is a limitation which amounts to data gathering which is considered to be insignificant extra solution activity (MPEP 2106.05(g)). Claim 17 further recites “access[ing] a job status datastore storing IDs of existing jobs”, accessing data is a limitation which amounts to data gathering which is considered to be insignificant extra solution activity (MPEP 2106.05(g)). The additional elements “a system” (claim 1), “a processor” (claim 1), “a memory that stores program code” (claim 1), “a computer readable storage medium having program instructions” (claim 17), these limitations amount to no more than mere instructions to apply the exception using generic computer components. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea (see MPEP 2106.05(f)). The claims are directed to an abstract idea. Step 2B: The limitations “a system” (claim 1), “a processor” (claim 1), “a memory that stores program code” (claim 1), “a computer readable storage medium having program instructions” (claim 17) are merely generic computer or generic computer components to apply the judicial exception, which cannot provide an inventive concept. The limitation “receiv[ing] a first job request associated with a user account”, receiving data over a network is a computer function the courts have recognized as well-understood, routine, and conventional activity when claimed in a merely generic manner (MPEP 2106.05(d)(II)(i)). The limitation “rout[ing] the first job request to the second job service architecture”, routing or transmitting data over a network is a computer function the courts have recognized as well-understood, routine, and conventional activity when claimed in a merely generic manner (MPEP 2106.05(d)(II)(i)). The limitation “access[ing] a job status datastore storing IDs of existing jobs” (claim 17) is receiving or transmitting data over a network, a computer function the courts have recognized as well-understood, routine, and conventional activity when claimed in a merely generic manner (MPEP 2106.05(d)(II)(i)). The specification also discloses that the limitations are apparent and therefore well-known in the art (Paragraph. 0050 “Further structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following description of FIG. 2 with respect to FIG. 1.”). Even when viewed in combination, the additional elements do not amount to significantly more. Accordingly, the additional elements do not amount to significantly more than the judicial exception. Dependent Claims: Claim 2 recites the limitations wherein, subsequent to routing the first job request: the job router: “receives a second job request”, receiving a job request is mere data gathering which the courts have found to be insignificant extra-solution activity (MPEP 2106.05(g)). “determines the migration state is disabled”, determining the value of a migration state is an evaluation and judgment that can be practically performed in the human mind, or even with the aid of pen and paper (MPEP 2106.04(a)(2)(III)). “determines the second job request corresponds to a second job”, determining the job request corresponds to a job is an evaluation and judgment that can be practically performed in the human mind, or even with the aid of pen and paper (MPEP 2106.04(a)(2)(III)). “and routes the second job request to the first job service architecture.”, routing or transmitting data over a network is mere data gathering which the courts have found to be insignificant extra-solution activity (MPEP 2106.05(g)). The specification also discloses that the limitations are apparent and therefore well-known in the art (Paragraph 0085). Even when viewed in combination, the additional elements do not amount to significantly more. Accordingly, the limitations do not amount to significantly more. Claim 3 recites the limitations wherein to determine the migration status, the job router: “provides an account status request to a resource provider”, providing or transmitting data over a network is mere data gathering which the courts have found to be insignificant extra-solution activity (MPEP 2106.05(g)). Responsive to providing the account status request, “receives the migration status from the resource provider.” receiving or retrieving information from memory is mere data gathering which the courts have found to be insignificant extra-solution activity (MPEP 2106.05(g)). The limitations do not amount to significantly more. Claim 4 recites the limitations: wherein the program code further comprises a job data consolidator that: “receives a first job record from the first job service architecture”, receiving or retrieving information from memory is mere data gathering which the courts have found to be insignificant extra-solution activity (MPEP 2106.05(g)). “receives a second job record from the second job service architecture”, receiving or retrieving information from memory is mere data gathering which the courts have found to be insignificant extra-solution activity (MPEP 2106.05(g)). “processes the first and second job records to generate processed records”, processing data amounts to mere instructions to apply an exception which is considered insignificant extra solution activity (MPEP 2106.05(g)). “stores the processed records as consolidated data in a job data datastore”, storing information in memory is mere data gathering which the courts have found to be insignificant extra-solution activity (MPEP 2106.05(g)). Even when viewed in combination, the limitations do not amount to significantly more. Accordingly, the limitations do not amount to significantly more. Claim 5 recites the limitations: wherein to receive the first job record, the job data consolidator generates a first worker thread that: “determines a syncing checkpoint associated with the first job service architecture, the syncing checkpoint indicating a last sync point of the first job service architecture”, determining a sync point is an evaluation and judgment that can be practically performed in the human mind, or even with the aid of pen and paper (MPEP 2106.04(a)(2)(III)). And utilizes an application programming interface (API) to “receive the first job record from the first job service architecture, the first job record submitted subsequent to the last sync point.”, receiving or retrieving information from memory is mere data gathering which the courts have found to be insignificant extra-solution activity (MPEP 2106.05(g)). Even when viewed in combination, the limitations do not amount to significantly more. Accordingly, the limitations do not amount to significantly more. Claim 6 recites the limitations: wherein: “the first job record corresponds to a previous job performed by the first job service architecture, the previous job comprising a first operation to modify data; the first job comprises a second operation to modify the data;”, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea (MPEP 2106.05(f)). And the first job causes the second job service architecture to “access the job data datastore to receive the first job record.” Accessing or retrieving information from memory and receiving data from memory is mere data gathering which the courts have found to be insignificant extra-solution activity (MPEP 2106.05(g)). Even when viewed in combination, the limitations do not amount to significantly more. Accordingly, the limitations do not amount to significantly more. Claim 7 recites the limitations: wherein the job router: responsive to receiving a job report request, causes the job data consolidator to “retrieve the consolidated data from the job data datastore; and causes the consolidated data to be provided as a response to the job report request.” Retrieving information from memory and providing or transmitting data from over a network is mere data gathering which the courts have found to be insignificant extra-solution activity (MPEP 2106.05(g)). Even when viewed in combination, the limitations do not amount to significantly more. Accordingly, the limitations do not amount to significantly more. Claim 8 recites the limitations: further comprising: “a cache that stores job identifiers (IDs) of existing jobs”, a cache is merely a generic computer component to apply the judicial exception, which cannot provide an inventive concept and amounts to no more than mere instructions to apply the exception using generic computer components (MPEP 2106.05(f)(2)). “and wherein the first job request comprises a job ID and to cause the job to be scheduled”, causing the job to be scheduled amounts to mere instructions to apply an exception which is considered insignificant extra solution activity (MPEP 2106.05(g)). The job router: “fails to find a job ID stored by the distributed cache matching the job ID of the first job request,”, failing to find a job ID is a mental process that can be performed by a human mind through observation, evaluation, judgment, and/or opinion, or even with the aid of pen and paper (MPEP 2106.04(a)(2)(III)). “and routes the first job request to the second job service architecture.”, routing or transmitting data over a network is mere data gathering which the courts have found to be insignificant extra-solution activity (MPEP 2106.05(g)). Even when viewed in combination, the limitations do not amount to significantly more. Accordingly, the limitations do not amount to significantly more. Claim 9 recites the limitation wherein the job router: “stores, in the cache, a mapping of the job ID of the job request to the routed job service architecture”, storing information in memory is mere data gathering which the courts have found to be insignificant extra-solution activity (MPEP 2106.05(g)). The limitations do not amount to significantly more. Claim 11 recites the limitations: wherein routing the first job request “causes the second job service architecture to perform the step by executing the script of code.”, causing the second architecture to perform a step amounts to mere instructions to apply an exception which is considered insignificant extra solution activity (MPEP 2106.05(g)). The specification also discloses that the limitations are apparent and therefore well-known in the art (Paragraph 0050). The limitations do not amount to significantly more. As per claims 12 and 20, they contain similar limitations as claim 2 and therefore are rejected using the same rationale. As per claim 13, it contains similar limitations as claim 4 and is therefore rejected using the same rationale. As per claim 14, it contains similar limitations as claim 5 and is therefore rejected using the same rationale. As per claims 15 and 19, they contain similar limitations as claim 7 and therefore are rejected using the same rationale. As per claim 16, it contains similar limitations as claims 8 and 9 and is therefore rejected using the same rationale. As per claim 18, it contains similar limitations as claim 11 and is therefore rejected using the same rationale. 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. Claim(s) 1-3, 8-12, 16-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Jones et al. US 2014/0259021 (hereinafter Jones) in view of Kosuru et al. US 2013/0036149 (hereinafter Kosuru) in further view of Parvathaneni et al. US 2007/0109592 (hereinafter Parvathaneni) in further view of Aiken et al. US 10691653 (hereinafter Aiken). As per claim 1, Jones teaches a system comprising: (Para. 0017 “the computer 100” Fig. 1 computer element 100) a processor; (Para. 0017 “processor 105” Fig. 1 processor element 105) a memory that stores program code executable by the processor circuit, the program code comprising: (Para. 0017 “memory 110” Para. 0008 “The computer readable program code is executable by a processor to perform a method that includes receiving a job” Fig. 1 memory element 110) A job router that: (Para. 0024 “scheduling system 200 may comprise a job router 210” Fig. 2 job router element 210) receives a first job request (Fig. 3 step 310 “job router receives new job for scheduling”), and routes the first job request to the second job service architecture (Fig. 3 step 350 “job router assigns the job to a computer supporting the requested functionality”), the first job request causing the second job service architecture to schedule a first job (Para. 0030 “the job router 210 need not exclude any of the computer systems 230 based on functionality, and may assign the job based entirely on other scheduling criteria”). However, Jones does not explicitly teach the first job request comprising a script of code and the first job request comprising a step to execute the script of code, a first job request associated with a user account, and determin[ing] a migration status of the user account indicates the user account is migrating from a first job service architecture to a second job service architecture and a migration state is enabled. Kosuru teaches the first job request comprising a script of code. (Para. 0063 “For example, the code (e.g., a script) can be specified in its entirety as a parameter included as part of the job request.”) Kosuru further teaches the first job request comprising a step to execute the script of code. (Para. 0005 “the at least one memory and the computer program code configured to, with the at least one processor, cause, at least in part, the apparatus to determine at least one job for execution over a distributed computing platform”) Jones and Kosuru are in the same field of endeavor and they are both in the field of job scheduling and, therefore, are combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the job request taught by Jones to include the script of code as taught by Kosuru because the job requests would comprise a script of executable code. The motivation would be that executing code from the job requests would allow the system to more efficiently use resources as taught by Kosuru (Para. 0003). However, Jones in view of Kosuru does not explicitly teach a first job request associated with a user account and determin[ing] a migration status of the user account indicates the user account is migrating from a first job service architecture to a second job service architecture and a migration state is enabled. Parvathaneni teaches a first job request associated with a user account. (Para. 0005 “there is a need for a system that can consistently send a user’s job requests to a particular server such that the user’s account data may be cached and efficiently used for subsequent job requests from the user.”) Both inventions are in the same field of endeavor and they are both in the field of job scheduling and, therefore, are combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Jones and Kosuru to include the job request associated with a user account as taught by Parvathaneni because the job router would be able to process job requests from user accounts. The motivation would be that the combined method would allow user account data to be cached and efficiently used for subsequent job requests as taught by Parvathaneni (Para. 0005). However, Jones in view of Kosuru in further view of Parvathaneni do not explicitly teach determin[ing] a migration status of the user account indicates the user account is migrating from a first job service architecture to a second job service architecture and a migration state is enabled. Aiken teaches determin[ing] a migration status of the user account. (Para. 53 “As noted above, the computing environment 103 may maintain a status of a migration of the user account data”) Aiken further teaches a migration status of the user account indicates the user account is migrating from a first job service architecture to a second job service architecture and a migration state is enabled. (Para. 11 “In some instances, legacy data pertaining to the user account must be migrated to the new system” Para. 58 “Thereafter, the backfill system 170 may invoke a service call, setStatus( ), to set an initial status 206 of the backfill system 170 as “initiated” or other appropriate status.”) Both inventions are reasonably pertinent to the problem disclosed by the claimed invention and are both concerned with management of user account data directed toward multiple systems and, therefore, are combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Jones and Kosuru and Parvathaneni to include the migration status of the user account as taught by Aiken because the job routing system could be adapted to user account migration between legacy and new architectures. The motivation would provide a more reliable system to resource providers in routing job requests based on user account migration state, as job requests would not be handled by only a single architecture. As per claim 2, Jones teaches wherein, subsequent to routing the first job request, the job router: receives a second job request (Fig. 3 step 310 “job router receives new job for scheduling”), and routes the second job request to the first job service architecture (Para. 0030 “Thus, the job router 210 may assign the job to only those computer systems 230 that can provide the full functionality requested by the job. In the case of a job that requires only the lowest level of functionality provided from among all the computer systems 230”). However, Jones does not explicitly teach a second job request associated with the user account and determines the second job request corresponds to a second job. Parvathaneni teaches a second job request associated with the user account (Para. 0005 “there is a need for a system that can consistently send a user’s job requests to a particular server such that the user’s account data may be cached and efficiently used for subsequent job requests from the user.”) and determines the second job request corresponds to a second job (Para. 0062 “3. The job scheduler first adds the job request to the persistent job table as an assurance against job loss.” Para. 0063 “4. The job scheduler then adds the job to the JMS Queue for processing by the job dispatcher.”). Both inventions are in the same field of endeavor and they are both in the field of job scheduling and, therefore, are combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the job request taught by Jones to include the job request associated with the user account and job request corresponding to a job as taught by Parvathaneni because the job router would be able to process job requests from user accounts. The motivation would be the same for the combination used in claim 1 above. However, Jones in view of Parvathaneni does not explicitly teach determines the migration state is disabled. Aiken teaches determines the migration state is disabled (Para. 0058 “Thereafter, the backfill system 170 may invoke a service call, setStatus( ), to set an initial status 206 of the backfill system 170 as “initiated” or other appropriate status. Thereafter, a service call, requestCapacity( ), may be invoked to determine an availability of computing resources to perform the backfill operation.”). Both inventions are reasonably pertinent to the problem disclosed by the claimed invention and are both concerned with management of user account data directed toward multiple systems and, therefore, are combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Jones and Parvathaneni to include the migration state taught by Aiken because the job routing system could be adapted to user account migration between legacy and new architectures. The motivation would be the same for the combination used in claim 1 above. As per claim 3, Jones teaches wherein to determine the migration status, the job router: provides a request to a resource provider associated with the first and second job architectures (Para. 0034 “At block 320, the job router 220 may transmit the job, or a portion of the new job's code, to a job reader 220.” Fig. 3 step 320 “Job router transmits the job to job reader”); responsive to providing the request, receives the status from the resource provider (Para. 0034 “At block 330, the job reader 220 may analyze the job to output an indication of functionality requested by the job.” Fig. 3 step 330 “Job reader analyzes the job and outputs an indication of functionality requested by the job”). However, Jones does not explicitly teach an account status request and responsive to providing the account status request, receives the migration status. Aiken teaches an account status request (Para. 37 “The resource monitor 180 is executed to identify the availability, or lack thereof, of computing resources.” Fig. 4 step 402 “Identify User Accounts for which automaton needs to be invoked to Perform Migration”) and responsive to providing the account status request, receives the migration status (Para. 53 “As noted above, the computing environment 103 may maintain a status of a migration of the user account data for the single user account in a data store 129.”). Both inventions are reasonably pertinent to the problem disclosed by the claimed invention and are both concerned with management of user account data directed toward multiple systems and, therefore, are combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the job router taught by Jones to include the account status request and migration status of Aiken because the job routing system would be able to request user account statuses from the resource provider. The motivation would be job requests would correspond to the first or second architecture depending on account migration status. As per claim 8, Jones teaches further comprising: a cache (Para. 0018 “The processor 105 includes a cache 170, which may include, but is not limited to, an instruction cache to speed up executable instruction fetch, a data cache to speed up data fetch and store”); and the job router: routes the first job request to the second job service architecture (Para. 0030 “Thus, the job router 210 may assign the job to only those computer systems 230 that can provide the full functionality requested by the job.” Jones Fig. 3 step 350 “job router assigns the job to a computer supporting the requested functionality”). However, Jones does not explicitly teach a cache that stores job identifiers (IDs) of existing jobs; and wherein the first job request comprises a job ID and to cause the job to be scheduled, and the job router: fails to find a job ID stored by the cache matching the job ID of the first job request. Aiken teaches a cache that stores job identifiers (IDs) of existing jobs; and wherein the first job request comprises a job ID and to cause the job to be scheduled (Para. 53 “The event identifier 203 may include, for example, a unique identifier that may be used to query an event 109 from the event data store 130 or the event processing queue 137.” Fig. 1 Event data store element 130 corresponds to a cache, Fig. 2A event identifier element 203a corresponds to a job ID, event element 109a corresponds to the first job request), and the job router: fails to find a job ID stored by the cache matching the job ID of the first job request (Para. 33 “In some embodiments, the computing environment 112 may defer to other authoritative sources to record events 109 in the event data store 130.”). Both inventions are reasonably pertinent to the problem disclosed by the claimed invention and are both concerned with management of data directed toward multiple systems and, therefore, are combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the job routing system taught by Jones to include a cache that stores job identifiers of existing jobs and job request comprising a job ID as taught by Aiken because the cache would be adapted to store identifiers of jobs. The motivation would be querying jobs by their identifiers in the cache would be more efficient than querying the jobs themselves. As per claim 9, Jones teaches wherein the job router: the cache (Para. 0018 “The processor 105 includes a cache 170, which may include, but is not limited to, an instruction cache to speed up executable instruction fetch, a data cache to speed up data fetch and store”). However, Jones does not teach the job router: stores, in the cache, a mapping of the job ID of the job request to the routed job service architecture. Aiken teaches stores, in the cache, a mapping of the job ID of the job request to the routed job service architecture (Para. 53 “an event 109 may generated by a service 106 or the backfill system 170 to include an event identifier 203a . . . 203b, an initial status 206a . . . 206b, an account identifier 209a . . . 209b, a timestamp 212a . . . 212b, an automaton identifier 215a . . . 215b (also referred to as an operation(s) identifier), as well as additional information pertaining to a backfill operation to be performed by a compute engine 183 using a particular automaton or, in other words, a predefined series of operations to be performed by the compute engine 183 to transform legacy data to data for a new system 190”). Both inventions are reasonably pertinent to the problem disclosed by the claimed invention and are both concerned with management of data directed toward multiple systems and, therefore, are combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the job router taught by Jones to include storing a mapping of the job ID in the cache as taught by Aiken because the cache would be adapted to store mappings of job IDs to a job request’s corresponding architecture. The motivation would be the same for the combination used in claim 8 above. As per claim 10, it has similar limitations as claim 1 and is therefore rejected using the same rationale. As per claim 11, it has similar limitations as claim 1 and is therefore rejected using the same rationale. As per claim 12, it has similar limitations as claim 2 and is therefore rejected using the same rationale. As per claim 16, it has similar limitations as claims 8 and 9, and is therefore rejected using the same rationale. As per claim 17, it has similar limitations as claim 1, 8, and 9, and is therefore rejected using the same rationale. As per claim 18, it has similar limitations as claim 1, and is therefore rejected using the same rationale. As per claim 20, it has similar limitations as claim 2 and 8, and is therefore rejected using the same rationale. Claim(s) 4, 7, 13, 15, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Jones in view of Kosuru in further view of Parvathaneni in further view of Aiken in further view of Patiejunas et al. US 8959067 (hereinafter Patiejunas). As per claim 4, Jones in view of Kosuru in further view of Parvathaneni in further view of Aiken disclose the claimed invention as detailed above for claim 1 but do not explicitly teach wherein the program code further comprises a job data consolidator that: receives a first job record from the first job service architecture; receives a second job record from the second job service architecture; processes the first and second job records to generate processed records; and stores the processed records as consolidated data in a job data datastore. However, Patiejunas teaches wherein the program code further comprises a job data consolidator that (Para. 61 “In some embodiments, job tracker 230 may collect information necessary to construct a job record from multiple requests.”, Fig. 2 job tracker element 230 corresponds to a job data consolidator): receives a first job record from the first job service architecture (Para. 163 “Additionally, the process 1000 may include receiving information corresponding to a completed job associated with the stored data at 1006.” Para. 62 “data stored in job tracker store 230 may be partitioned to enable fast enumeration of jobs that belong to a specific customer, facilitate efficient bulk record deletion, parallel processing by separate instances of a service and the like”); receives a second job record from the second job service architecture (Para. 165 “At 1210, the process 1200 may include receiving second information associated with a second operation.” Para. 61 “In an embodiment, control plane for direct I/O 210 includes a job tracker 230 that is configured to create job records or entries corresponding to customer requests, such as those received from API request handler 218, and monitor the execution of the jobs.”); processes the first and second job records to generate processed records (Para. 62 “For example, in some embodiments, a job tracker 230 may perform aggregate multiple jobs corresponding to multiple requests into one single aggregated job before inserting it into job tracker store 232.”); and stores the processed records as consolidated data in a job data datastore (Para. 62 “In some embodiments, control plane for direct I/O 210 includes a job tracker store 232 for storing job entries or records.” and Para. 62 “In an embodiment, transactions against job tracker store 232 may be aggregated to reduce the total number of transactions. For example, in some embodiments, a job tracker 230 may perform aggregate multiple jobs corresponding to multiple requests into one single aggregated job before inserting it into job tracker store 232.” Fig. 2 job tracker store element 232 corresponds to a job data datastore). Both inventions are in the same field of endeavor and both are in the field of job scheduling and, therefore, are combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Jones and Kosuru and Parvathaneni and Aiken to include the job data consolidator and job data datastore as taught by Patiejunas to consolidate job records from both service architectures and place them in a single store component. The motivation would be that the amount of data stored in the overall system is reduced as duplicate records on both architectures are made redundant. As per claim 7, Patiejunas further teaches wherein the job router: responsive to receiving a job report request, causes the job data consolidator to retrieve the consolidated data from the job data datastore (Para. 127 “In an embodiment, process 600 includes receiving 602 a data retrieval request to retrieve data such as stored by process 500, described above.”); and causes the consolidated data to be provided as a response to the job report request (Para. 139 “In an embodiment, process 600 includes providing 624 a notification of the completion of the retrieval job to the requestor of the retrieval request or another entity or entities otherwise configured to receive such a notification.”). As per claim 13, it has similar limitations as claim 4, and is therefore rejected using the same rationale. As per claim 15, it has similar limitations as claim 7, and is therefore rejected using the same rationale. As per claim 19, Patiejunas further teaches wherein the method further comprises: receiving a job report request requesting a status of the first job (Patiejunas Para. 61 “As discussed above, a job refers to a customer-initiated activity that may be performed asynchronously to the initiating request, such as data retrieval, storage, metadata queries or the like. In an embodiment, control plane for direct I/O 210 includes a job tracker 230 that is configured to create job records or entries corresponding to customer requests, such as those received from API request handler 218, and monitor the execution of the jobs. In various embodiments, a job record may include information related to the execution of a job such as a customer account identifier, job identifier, data object identifier, reference to payload data cache 228 (described below), job status, data validation information and the like.”); transmitting instructions to a job data consolidation service to cause the job data consolidation service to determine the status of the first job (Patiejunas Para. 63 “In some embodiments, job tracker 230 may be further configured to handle customer queries such as job status queries”); and subsequent to receiving the status of the first job from the job data consolidation service, providing the status of the first job as a response to the job report request (Patiejunas Para. 63 “In some embodiments, job tracker 230 also provides notifications of job status changes to customers or other services of the archival data storage system.”). Claim(s) 5, 6, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Jones in view of Kosuru in further view of Parvathaneni in further view of Aiken in further view of Patiejunas in further view of Berrington et al. US 2017/0031932 (hereinafter Berrington). As per claim 5, Jones in view of Kosuru in further view of Parvathaneni in further view of Aiken in further view of Patiejunas disclose the claimed invention above for claims 1 and 4. Patiejunas teaches [utilizing] an application programming interface (API) to receive the first job record from the first job service architecture (Para. 34 “In some embodiments, archival data storage system 206 provides the APIs for customers to retrieve data stored in the archival data storage system.” Para. 62 “In an embodiment, control plane for direct I/O 210 includes a job tracker 230 that is configured to create job records or entries corresponding to customer requests, such as those received from API request handler 218”). However, the combination of references do not explicitly teach wherein to receive the first job record, the job data consolidator generates a first worker thread that: determines a syncing checkpoint associated with the first job service architecture, the syncing checkpoint indicating a last sync point of the first job service architecture; and the first job record submitted subsequent to the last sync point. However, Berrington teaches wherein to receive the first job record, the job data consolidator generates a first worker thread that (Para. 0232 “It shows that when the time comes at step 4201 for a worker thread to commit a checkpoint for the file system, several tasks are performed before and after committing the checkpoint.”): determines a syncing checkpoint associated with the first job service architecture (Para. 0232 “Generally, the file system checkpointing thread 4200 will sleep/wake up at regular intervals and/or become active upon receiving a synchronous checkpoint request at step 4201.”), the syncing checkpoint indicating a last sync point of the first job service architecture (Para. 0232 “A checkpoint is committed at step 4203 resulting in all outstanding changes in the file system completely committed to disk.”); and the first job record submitted subsequent to the last sync point (Para. 0253 “The files on the delay queue 850 will have all of their modifications committed to disk once the file system commits its next checkpoint.”). Both inventions are reasonably pertinent to the problem disclosed in the claimed invention and are both concerned with data management in multi-computer systems and, therefore, are combinable/modifiable. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Jones and Kosuru and Parvathaneni and Aiken and Patiejunas to include the known technique of [using] a worker thread to commit a checkpoint for the file system taught by Berrington to the job data consolidator taught by Patiejunas. The motivation would be combining them would have predictably resulted in a checkpoint mechanism to initiate a syncing checkpoint of a system as taught by Berrington (Para. 0004, 0232). As per claim 6, Patiejunas further teaches wherein: the first job record corresponds to a previous job performed by the first job service architecture (Para. 18 “For example, one computing device of the archival data storage service may be configured to perform operations for performing jobs while another computing device may be configured to perform operations for providing metadata about those completed jobs to a result queue.”), the previous job comprising a first operation to modify data; the first job comprises a second operation to modify the data (Para. 17 “In some examples, the jobs may include or be accompanied by associated instructions for configuring the one or more computing devices to perform operations including, but not limited to, storing data, retrieving data and deleting data in memory of the archival storage service.”); and the first job causes the second job service architecture to access the job data datastore to receive the first job record (Para. 18 “Still another computing device may be configured to perform operations for receiving data associated with completed operations from a result queue.”). As per claim 14, it has similar limitations as claim 5, and is therefore rejected using the same rationale. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US 20200104404 A1 to Li et al. teaches a method for transitioning from a legacy technology stack to a new technology stack comprising of steps to route requests from the legacy service to the new service [Paragraph 0016] and comprises synchronization with a new database. [Paragraph 0039] US 20170061027 A1 to Chesla et al. teaches a method of migrating data, comprising steps which include determining a control signal value, the control signal value indicating a migration state of a migration of member profile data associated with one or more members of a Social Networking Service. [Paragraph 0042] US 11281498 to Kinney, Jr. et al. teaches a method where computing resources are selected for a job based at least in part on the compute resource type indicated by the plurality of constraints and satisfying one or more job requirements indicated by a job definition associated with the job. [Paragraph 18] Rob, Bagby, NPL from IDS filed on October 17, 2025 teaches a job routing method that routes requests to either a legacy application or a new service [Page 1, Paragraph 4.]. It also teaches considerations for the method to be used during service migration. [Page 2, Paragraph 1-2.] Examiner has cited particular columns/paragraphs/sections and line numbers in the references applied and not relied upon to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner. When responding to the Office action, applicant is advised to clearly point out the patentable novelty the claims present in view of the state of the art disclosed by the reference(s) cited or the objections made. A showing of how the amendments avoid such references or objections must also be present. See 37 C.F.R. 1.111(c). When responding to this Office action, applicant is advised to provide the line and page numbers in the application and/or reference(s) cited to assist in locating the appropriate paragraphs. Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANTHONY DUC HUYNH whose telephone number is (571)272-0732. The examiner can normally be reached Monday - Friday, 8 a.m. - 5 p.m. ET.. 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, Pierre Vital can be reached at (571) 272-4215. The fax phone number for the organization where this application or proceeding is assigned is 571-272-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. /A.D.H./Examiner, Art Unit 2198 /PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198
Read full office action

Prosecution Timeline

Aug 08, 2024
Application Filed
Sep 11, 2026
Non-Final Rejection mailed — §101, §103, §112
Oct 07, 2026
Interview Requested

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
Grant Probability
Low
PTA Risk
Based on 0 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month