Prosecution Insights
Last updated: April 19, 2026
Application No. 17/723,202

SYNCHRONIZATION SYSTEM AND METHOD

Final Rejection §103
Filed
Apr 18, 2022
Examiner
FERRER, JEDIDIAH P
Art Unit
2153
Tech Center
2100 — Computer Architecture & Software
Assignee
Advanced Micro Devices, Inc.
OA Round
4 (Final)
52%
Grant Probability
Moderate
5-6
OA Rounds
4y 1m
To Grant
91%
With Interview

Examiner Intelligence

Grants 52% of resolved cases
52%
Career Allow Rate
114 granted / 220 resolved
-3.2% vs TC avg
Strong +40% interview lift
Without
With
+39.6%
Interview Lift
resolved cases with interview
Typical timeline
4y 1m
Avg Prosecution
26 currently pending
Career history
246
Total Applications
across all art units

Statute-Specific Performance

§101
19.2%
-20.8% vs TC avg
§103
63.7%
+23.7% vs TC avg
§102
5.8%
-34.2% vs TC avg
§112
8.1%
-31.9% vs TC avg
Black line = Tech Center average estimate • Based on career data from 220 resolved cases

Office Action

§103
DETAILED ACTION Claims 1-2, 4-5, 7-10, 13-14, 16-17, and 19-20 are pending. Independent claims 1, 9, 16, and 20 have been amended. Claim 20 has been amended but continues to differ from independent claims 1, 9, and 16. Claims 1-2, 4-5, 7-10, 13-14, 16-17, and 19-20 are rejected. Notice of 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 . Examiner Notes/Claim Objections Claim 17 recites “central storge system” and should likely recite “central storage system.” Claim 20 also recites “determine that a first workload output file hash is missing from the central storge” and should likely recite “central storage.” Claim 20 recites “and that and a first workload output file has been created”; the second “and” should likely be removed. Claim 20 is objected to for reciting “cause the first workload file of the compute system to be hashed, wherein the hash of the first workload file of first compute system is a second hash.” Claim 20 should likely recite “the first compute system” and “of the first compute system” due to an earlier “identify a first workload file on a first compute system” limitation. Response to Arguments Applicant’s arguments, see Remarks pp17-27 filed 09/17/2025, with respect to the rejection(s) of claims 1-2, 4-5, 7-10, 13-14, 16-17, and 19 under 35 U.S.C. 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made. While Penangwala remains in the rejection, it is no longer being relied on to address being missing from the central storage (Remarks p26, ¶ 2). Applicant’s arguments, see Remarks pp28-31 filed 09/17/2025, with respect to the rejection(s) of claim 20 under 35 U.S.C. 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made. While Penangwala remains in the rejection, it is no longer being relied on to address being missing from the central storage (Remarks p30, ¶ 7) Statutory Review under 35 USC § 101 Claims 1-5 and 7-8 are directed toward an article of manufacture and have been reviewed. Claims 1-5 and 7-8 initially appear to remain statutory, as the article of manufacture excludes transitory signals. Claims 1-5 and 7-8 appear to remain patent-eligible at this time as its judicial exception is integrated into a practical application as per (Revised) Step 2A, Prong Two of the patent subject matter eligibility determination. Specifically, the claims recite additional elements demonstrating that the claim as a whole integrates the exception into a practical application. The claims have been evaluated to ensure that the claims reflect the disclosed improvement: the claims are drawn to ensuring the correct first workload input file is used by allowing the workload to proceed as intended if compared hashes are identical or by overwriting a first copy if compared hashes are different. These additional claim elements improve the functioning of a computer or any other technology or technical fields, thus integrating the abstract exception into a practical application. Claims 9-11 and 13-14 are directed toward a system and have been reviewed. Claims 9-11 and 13-14 initially appear to remain statutory under 35 USC § 101 as it includes hardware, “a server” in light of ¶ 0021 of the specification as pointed out by the Applicant (Remarks p16). Claims 9-11 and 13-14 also appear to remain patent-eligible at this time as their judicial exceptions are integrated into a practical application as per (Revised) Step 2A, Prong Two of the patent subject matter eligibility determination. Specifically, the claims recite additional elements demonstrating that the claim as a whole integrates the exception into a practical application. The claims have been evaluated to ensure that the claims reflect the disclosed improvement: the claims are drawn to ensuring the correct first workload input file is used by allowing the workload to proceed as intended if compared hashes are identical or by overwriting a first copy if compared hashes are different. These additional claim elements improve the functioning of a computer or any other technology or technical fields, thus integrating the abstract exception into a practical application. Claims 16-19 are directed towards a method and have been reviewed. Claims 16-19 appear to remain patent-eligible at this time as their judicial exceptions are integrated into a practical application as per (Revised) Step 2A, Prong Two of the patent subject matter eligibility determination. Specifically, the claims recite additional elements demonstrating that the claim as a whole integrates the exception into a practical application. The claims have been evaluated to ensure that the claims reflect the disclosed improvement: the claims are drawn to ensuring the correct first workload input file is used by allowing the workload to proceed as intended if compared hashes are identical or by overwriting a first copy if compared hashes are different. These additional claim elements improve the functioning of a computer or any other technology or technical fields, thus integrating the abstract exception into a practical application. Claim 20 is directed toward a system and has been reviewed. Claim 20 initially appears to remain statutory under 35 USC § 101 as it includes hardware, “a server” in light of ¶ 0021 of the specification as pointed out by the Applicant (Remarks p16). Claim 20 also appears to remain patent-eligible at this time as its judicial exception is integrated into a practical application as per (Revised) Step 2A, Prong Two of the patent subject matter eligibility determination. Specifically, the claims recite additional elements demonstrating that the claim as a whole integrates the exception into a practical application. The claims have been evaluated to ensure that the claims reflect the disclosed improvement: the claims are drawn to rehashing a first workload file and comparing a first hash to the rehash to ensure that no errors have occurred when the first workload file was copied to the compute system. These additional claim elements improve the functioning of a computer or any other technology or technical fields, thus integrating the abstract exception into a practical application. 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, 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-2, 4-5, 7-10, 13-14, 16-17, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Watson et al., U.S. Patent Application Publication No. 2018/0101544 (hereinafter Watson) in view of Lee et al., U.S. Patent Application Publication No. 2017/033972 (hereinafter Lee) in further view of Imai et al., U.S. Patent Application Publication No. 2008/0147662 (hereinafter Imai) in further view of Penangwala et al., U.S. Patent Application Publication No. 2016/0085769 (hereinafter Penangwala). Regarding claim 1, Watson teaches: A non-transitory computer-readable medium storing instructions executable by a hardware processor to: (Watson FIG. 5, ¶ 0050-0054: a computing device 300 suitable for certain components of the computer system 100 in FIG. 1. For example, the computing device 300 can be suitable for the file server 106, the workflow server 126, or the client devices 102 of FIG. 1. In a very basic configuration 302, the computing device 300 can include one or more processors 304 and a system memory 306 ... The system memory 306, removable storage devices 336, and non-removable storage devices 338 are examples of computer readable storage media) create a first hash of a first workload input file having a first filename, (Watson ¶ 0007: a file server can assign a read validation token and a write validation token to an uploaded computer file and notify the client device regarding the assigned read/write validation tokens … the read or write validation token can include a hash (e.g., an XOR hash) of the computer file; Watson ¶ 0034: the sync request 130a can include data representing certain information associated with the computer file 112. Such information can include, for example, file name, date/time created, authored by, file size, or other suitable information) wherein the first hash and the first workload input file are stored on a central storage; (Watson ¶ 0007: a file server can assign a read validation token and a write validation token to an uploaded computer file ... at least one of the read or write validation token can be generated and/or predicted based on a protocol followed by both a file server and client devices. For example, in one embodiment, the read or write validation token can include a hash (e.g., an XOR hash) of the computer file; Watson ¶ 0019: when metadata is inserted into a server copy, the server copy with the inserted metadata can have an updated read validation token; Watson ¶ 0039: the client device 102 can transmit another sync request 130b and in response receive another notification 131b from the file server 106, indicating that the server copy 112b′ is now associated with a read validation token of two while the write validation token stays at one) make the first workload input file accessible, from the central storage device, to a plurality of third-party compute systems; (Watson FIG. 1, ¶ 0020-0024: the computer system 100 can include a file server 106 and a workflow server 126 interconnected with one or more client devices 102 via a computer network 104 … The file server 106 can be configured to provide shared storage of documents, sound files, photographs, movies, images, databases, or other suitable types of computer files to the client devices 102 over the computer network 104. For example, users 101 utilizing corresponding client devices 102 can retrieve, edit, save, or perform other suitable file operations on computer files managed by the file server 106 [see this aligning with the claimed workload input file based on instant specification para. 0008-0009 and para. 0026-0030]) … i) compare the first hash stored on the central storage system to a first copy hash of the first copy stored on the first third-party compute system, (Watson ¶ 0007: the read or write validation token can include a hash (e.g., an XOR hash) of the computer file; Watson FIG. 4B, ¶ 0048: decision stage 211 to determine whether a read validation token of the local copy matches that of the server copy) …when the first hash is the same as the first copy hash, and (Watson ¶ 0007: the read or write validation token can include a hash (e.g., an XOR hash) of the computer file; Watson FIG. 4B, ¶ 0048: decision stage 211 to determine whether a read validation token of the local copy matches that of the server copy. In response to determining that the read validation token of the local copy matches that of the server copy, the process 210 can include indicating that file synchronization of the computer file is complete at stage 214) iii) provide a second copy of the first workload input file from the central storage system to the first third-party compute system to overwrite the first copy so the first workload is carried out using the second copy when the first hash is different than the first copy hash; (Watson ¶ 0007: the read or write validation token can include a hash (e.g., an XOR hash) of the computer file; Watson FIG. 4B, ¶ 0048: In response to determining that the read validation token of the local copy does not match that of the server copy, the process 210 can include downloading the server copy to overwrite the local copy at stage 212 before indicating that file synchronization of the computer file is complete at stage 214 [see this aligning with carrying out a first workload based on instant specification para. 0008-0009 and para. 0026-0030]) receive a notification when the first workload on the first workload file is complete and a first workload output file has been created; and (Watson FIG. 4A, ¶ 0045-0047: the process 200 can include detecting a change in a local copy of a computer file at stage 202 ... the detected change can include other suitable user operations that create and/or modify the computer file; see Watson ¶ 0047: the process 200 can include uploading the changed local copy to overwrite the server copy in the repository 121 [relevant to first workload output file]) in response to receiving the notification that the first workload is complete, provide a copy of the first workload output file from the third-party compute system to the central storage when a first workload output file … is missing from the central storage, wherein the first workload output file is one of the one or more output files. (Watson FIG. 4A, ¶ 0045-0047, see first Watson ¶ 0045: the process 200 can include detecting a change in a local copy of a computer file at stage 202 ... the detected change can include other suitable user operations that create and/or modify the computer file; see then Watson ¶ 0046: The process 200 can then include obtaining state information of a corresponding server copy of the computer file at stage 204. In certain embodiments, the state information includes an existence or non-existence of a server copy of the computer file in, for example, the repository 121 of FIG. 2A [relevant to being missing from central storage]; see then Watson ¶ 0047: The process 200 can then include a decision stage 205 to determine whether the write validation token of the changed local copy matches that of the server copy. In response to determining that the write validation tokens match, the process 200 can include uploading the changed local copy to overwrite the server copy in the repository 121 [shows providing a copy of the first workload output file to the central storage]) Watson does not expressly disclose performing steps such as a comparison “in response to a first third-party compute system of the plurality of third-party compute systems having initiated a first workload intended to employ the first workload input file to create one or more output files and the first third-party compute system having a first copy of the first workload input file stored thereon.” Watson further does not expressly disclose: ii) allow the first third-party compute system to carry out the first workload using the first copy stored thereon when the first hash is the same as the first copy hash, Watson further does not expressly disclose a first workload output file hash is missing. However, Lee teaches: in response to a first third-party compute system of the plurality of third-party compute systems having initiated a first workload intended to employ the first workload input file to create one or more output files and the first third-party compute system having a first copy of the first workload input file stored thereon, (Lee FIG. 2, ¶ 0049: The database environment 200 can include a client 204. Although a single client 204 is shown, the client 204 can represent multiple clients [shows a first of a plurality]; see Lee FIG. 10, ¶ 0162: generating a workload replay file [one or more output files], such as from a workload capture file [first workload input file] or other workload capture data. Workload capture data, such as a workload capture file, is received in step 1010 ... For each of the workload capture units, in step 1025, the collected execution context data and performance measure data are stored in a format replayable by a second database system; see Lee FIG. 16B, ¶ 0183: In step 1660, a request [shows having initiated] for a database operation of workload capture data...) i) compare the first hash stored on the central storage system to a first copy hash of the first copy stored on the first third-party compute system, (Lee FIG. 16A, ¶ 0182: a method 1600 for determining hash values for a captured workload ... The data is hashed in step 1620 to produce a hash value. In step 1630 the hash value is stored in a capture file with execution context data and performance data associated with the request for a database operation; Lee FIG. 16B, ¶ 0183: In step 1660, a request for a database operation of workload capture data is executed at a second database system to generate execution data. In step 1670, a hash value is calculated for the execution data. The calculated hash value is compared, in step 1680, with a stored hash value [such as Lee ¶ 0182 above] associated with the execution of the request for a database operation at a first database system) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the file hash comparison of Lee with the file hash comparison of Watson. In addition, both of the references (Watson and Lee) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as file data/metadata hashing. Motivation to do so would be to improve the functioning of Watson involving using hashing to determine file status with the functioning in similar reference Lee also using hashing to determine file status but with the improvement of storing context and performance data alongside the hash. Motivation to do so would also be the teaching, suggestion, or motivation for one of ordinary skill in the art to improve database performance (Lee ¶ 0043) and to improve accuracy in database system verification techniques (Lee ¶ 0173). Watson in view of Lee does not expressly disclose: ii) allow the first third-party compute system to carry out the first workload using the first copy stored thereon when the first hash is the same as the first copy hash, Watson in view of Lee further does not expressly disclose a first workload output file hash is missing. However, Imai teaches: ii) allow the first third-party compute system to carry out the first workload using the first copy stored thereon when the first hash is the same as the first copy hash, and (Imai FIG. 8, ¶ 0075: In step S804, the verification processor 214 compares the hash data acquired in step S802 with that acquired in step S803. As a result of comparison, if the two data are equal to each other, the process advances to step S805. If the hash data acquired in step S802 is equal to that acquired in step S803, this means that no alterations etc. have been applied to the files 404 to 407 included in the selected folder 401; see then Imai ¶ 0079 showing the claimed workload being carried out: upon verification of the presence/absence of alterations etc. for files managed by the file management system, the processing can be executed for respective folders) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the hashing of Watson as modified with the hashing of Imai. In addition, both of the references (Watson as modified and Imai) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as file data/metadata hashing. Motivation to do so would be to improve the functioning of Watson as modified involving using hashing to determine file status with the functioning in similar reference Imai using hashing to determine file status but with added verification processing of propagated updates. Watson in view of Lee and Imai does not expressly disclose a first workload output file hash is missing. However, Penangwala addresses this by teaching: provide a copy of the first workload output file from the third-party compute system to the central storage when a first workload output file hash is missing… (Penangwala FIG. 5, ¶ 0100-0104, see primarily ¶ 0100: the process 500 can include determining whether a particular shared file includes an inconsistent file hash pairing ... In another aspect the inconsistent file hash pairing can include ... a missing a remote file hash for a remote instance of the particular shared file; see Penangwala ¶ 0103: At 506, if any files have been changed locally, the process 500 can proceed to 508 and the process 500 can further include uploading the files to the remote file system. In one aspect, the entire file that has been changed can be uploaded to the remote file system) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the hashing and file synchronization of Watson as modified with the hashing and file synchronization of Penangwala. In addition, both of the references (Watson as modified and Penangwala) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as file hashing and synchronization. Motivation to do so would be to improve the functioning of Watson as modified involving using hashing to determine file status with the functioning in similar reference Penangwala using hashing to determine file status but with the improved bidirectional synchronization. Regarding claim 9, Watson teaches: A system comprising: a central storage device; and a server configured to run a synchronization system configured to: (Watson FIGs. 2, ¶ 0031-0032: The file server 120 can include an interface component 122 and a sync controller 124 operatively coupled to a repository 121 for storing computer files ... The sync controller 124 can be configured to manage synchronization of copies of computer files in the repository 121) create a first hash of a first workload input file having a first filename, (Watson ¶ 0007: a file server can assign a read validation token and a write validation token to an uploaded computer file and notify the client device regarding the assigned read/write validation tokens … the read or write validation token can include a hash (e.g., an XOR hash) of the computer file; Watson ¶ 0034: the sync request 130a can include data representing certain information associated with the computer file 112. Such information can include, for example, file name, date/time created, authored by, file size, or other suitable information) wherein the first hash and the first workload input file are stored on a central storage; (Watson ¶ 0007: a file server can assign a read validation token and a write validation token to an uploaded computer file ... at least one of the read or write validation token can be generated and/or predicted based on a protocol followed by both a file server and client devices. For example, in one embodiment, the read or write validation token can include a hash (e.g., an XOR hash) of the computer file; Watson ¶ 0019: when metadata is inserted into a server copy, the server copy with the inserted metadata can have an updated read validation token; Watson ¶ 0039: the client device 102 can transmit another sync request 130b and in response receive another notification 131b from the file server 106, indicating that the server copy 112b′ is now associated with a read validation token of two while the write validation token stays at one) make the first workload input file accessible, from the central storage device, to a plurality of third-party compute systems; (Watson FIG. 1, ¶ 0020-0024: the computer system 100 can include a file server 106 and a workflow server 126 interconnected with one or more client devices 102 via a computer network 104 … The file server 106 can be configured to provide shared storage of documents, sound files, photographs, movies, images, databases, or other suitable types of computer files to the client devices 102 over the computer network 104. For example, users 101 utilizing corresponding client devices 102 can retrieve, edit, save, or perform other suitable file operations on computer files managed by the file server 106 [see this aligning with the claimed workload input file based on instant specification para. 0008-0009 and para. 0026-0030]) … i) compare the first hash stored on the central storage system to a first copy hash of the first copy stored on the first third-party compute system, (Watson ¶ 0007: the read or write validation token can include a hash (e.g., an XOR hash) of the computer file; Watson FIG. 4B, ¶ 0048: decision stage 211 to determine whether a read validation token of the local copy matches that of the server copy) …when the first hash is the same as the first copy hash, and (Watson ¶ 0007: the read or write validation token can include a hash (e.g., an XOR hash) of the computer file; Watson FIG. 4B, ¶ 0048: decision stage 211 to determine whether a read validation token of the local copy matches that of the server copy. In response to determining that the read validation token of the local copy matches that of the server copy, the process 210 can include indicating that file synchronization of the computer file is complete at stage 214) iii) provide a second copy of the first workload input file from the central storage system to the first third-party compute system to overwrite the first copy so the first workload is carried out using the second copy when the first hash is different than the first copy hash; (Watson ¶ 0007: the read or write validation token can include a hash (e.g., an XOR hash) of the computer file; Watson FIG. 4B, ¶ 0048: In response to determining that the read validation token of the local copy does not match that of the server copy, the process 210 can include downloading the server copy to overwrite the local copy at stage 212 before indicating that file synchronization of the computer file is complete at stage 214 [see this aligning with carrying out a first workload based on instant specification para. 0008-0009 and para. 0026-0030]) receive a notification when the first workload on the first workload file is complete and a first workload output file has been created; and (Watson FIG. 4A, ¶ 0045-0047: the process 200 can include detecting a change in a local copy of a computer file at stage 202 ... the detected change can include other suitable user operations that create and/or modify the computer file; see Watson ¶ 0047: the process 200 can include uploading the changed local copy to overwrite the server copy in the repository 121 [relevant to first workload output file]) in response to receiving the notification that the first workload is complete, provide a copy of the first workload output file from the third-party compute system to the central storage when a first workload output file … is missing from the central storage, wherein the first workload output file is one of the one or more output files. (Watson FIG. 4A, ¶ 0045-0047, see first Watson ¶ 0045: the process 200 can include detecting a change in a local copy of a computer file at stage 202 ... the detected change can include other suitable user operations that create and/or modify the computer file; see then Watson ¶ 0046: The process 200 can then include obtaining state information of a corresponding server copy of the computer file at stage 204. In certain embodiments, the state information includes an existence or non-existence of a server copy of the computer file in, for example, the repository 121 of FIG. 2A [relevant to being missing from central storage]; see then Watson ¶ 0047: The process 200 can then include a decision stage 205 to determine whether the write validation token of the changed local copy matches that of the server copy. In response to determining that the write validation tokens match, the process 200 can include uploading the changed local copy to overwrite the server copy in the repository 121 [shows providing a copy of the first workload output file to the central storage]) Watson does not expressly disclose performing steps such as a comparison “in response to a first third-party compute system of the plurality of third-party compute systems having initiated a first workload intended to employ the first workload input file to create one or more output files and the first third-party compute system having a first copy of the first workload input file stored thereon on the first third-party compute system.” Watson further does not expressly disclose: ii) allow the first third-party compute system to carry out the first workload using the first copy stored thereon when the first hash is the same as the first copy hash, Watson further does not expressly disclose a first workload output file hash is missing. However, Lee teaches: in response to a first third-party compute system of the plurality of third-party compute systems having initiated a first workload intended to employ the first workload input file to create one or more output files and the first third-party compute system having a first copy of the first workload input file stored thereon on the first third-party compute system, (Lee FIG. 2, ¶ 0049: The database environment 200 can include a client 204. Although a single client 204 is shown, the client 204 can represent multiple clients [shows a first of a plurality]; see Lee FIG. 10, ¶ 0162: generating a workload replay file [one or more output files], such as from a workload capture file [first workload input file] or other workload capture data. Workload capture data, such as a workload capture file, is received in step 1010 ... For each of the workload capture units, in step 1025, the collected execution context data and performance measure data are stored in a format replayable by a second database system; see Lee FIG. 16B, ¶ 0183: In step 1660, a request [shows having initiated] for a database operation of workload capture data...) i) compare the first hash stored on the central storage system to a first copy hash of the first copy stored on the first third-party compute system, (Lee FIG. 16A, ¶ 0182: a method 1600 for determining hash values for a captured workload ... The data is hashed in step 1620 to produce a hash value. In step 1630 the hash value is stored in a capture file with execution context data and performance data associated with the request for a database operation; Lee FIG. 16B, ¶ 0183: In step 1660, a request for a database operation of workload capture data is executed at a second database system to generate execution data. In step 1670, a hash value is calculated for the execution data. The calculated hash value is compared, in step 1680, with a stored hash value [such as Lee ¶ 0182 above] associated with the execution of the request for a database operation at a first database system) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the file hash comparison of Lee with the file hash comparison of Watson. In addition, both of the references (Watson and Lee) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as file data/metadata hashing. Motivation to do so would be to improve the functioning of Watson involving using hashing to determine file status with the functioning in similar reference Lee also using hashing to determine file status but with the improvement of storing context and performance data alongside the hash. Motivation to do so would also be the teaching, suggestion, or motivation for one of ordinary skill in the art to improve database performance (Lee ¶ 0043) and to improve accuracy in database system verification techniques (Lee ¶ 0173). Watson in view of Lee does not expressly disclose: ii) allow the first third-party compute system to carry out the first workload using the first copy stored thereon when the first hash is the same as the first copy hash, Watson in view of Lee further does not expressly disclose a first workload output file hash is missing. However, Imai teaches: ii) allow the first third-party compute system to carry out the first workload using the first copy stored thereon when the first hash is the same as the first copy hash, and (Imai FIG. 8, ¶ 0075: In step S804, the verification processor 214 compares the hash data acquired in step S802 with that acquired in step S803. As a result of comparison, if the two data are equal to each other, the process advances to step S805. If the hash data acquired in step S802 is equal to that acquired in step S803, this means that no alterations etc. have been applied to the files 404 to 407 included in the selected folder 401; see then Imai ¶ 0079 showing the claimed workload being carried out: upon verification of the presence/absence of alterations etc. for files managed by the file management system, the processing can be executed for respective folders) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the hashing of Watson as modified with the hashing of Imai. In addition, both of the references (Watson as modified and Imai) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as file data/metadata hashing. Motivation to do so would be to improve the functioning of Watson as modified involving using hashing to determine file status with the functioning in similar reference Imai using hashing to determine file status but with added verification processing of propagated updates. Watson in view of Lee and Imai does not expressly disclose a first workload output file hash is missing. However, Penangwala addresses this by teaching: provide a copy of the first workload output file from the third-party compute system to the central storage when a first workload output file hash is missing… (Penangwala FIG. 5, ¶ 0100-0104, see primarily ¶ 0100: the process 500 can include determining whether a particular shared file includes an inconsistent file hash pairing ... In another aspect the inconsistent file hash pairing can include ... a missing a remote file hash for a remote instance of the particular shared file; see Penangwala ¶ 0103: At 506, if any files have been changed locally, the process 500 can proceed to 508 and the process 500 can further include uploading the files to the remote file system. In one aspect, the entire file that has been changed can be uploaded to the remote file system) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the hashing and file synchronization of Watson as modified with the hashing and file synchronization of Penangwala. In addition, both of the references (Watson as modified and Penangwala) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as file hashing and synchronization. Motivation to do so would be to improve the functioning of Watson as modified involving using hashing to determine file status with the functioning in similar reference Penangwala using hashing to determine file status but with the improved bidirectional synchronization. Regarding claim 16, Eshghi teaches: A method comprising: hashing a plurality of workload files such that each workload file of a plurality of workload files has a respective hash associated therewith, (Watson ¶ 0007: a file server can assign a read validation token and a write validation token to an uploaded computer file and notify the client device regarding the assigned read/write validation tokens … the read or write validation token can include a hash (e.g., an XOR hash) of the computer file) wherein the plurality of workload files and each respective hash are stored on a central storage; (Watson ¶ 0007: a file server can assign a read validation token and a write validation token to an uploaded computer file ... at least one of the read or write validation token can be generated and/or predicted based on a protocol followed by both a file server and client devices. For example, in one embodiment, the read or write validation token can include a hash (e.g., an XOR hash) of the computer file; Watson ¶ 0019: when metadata is inserted into a server copy, the server copy with the inserted metadata can have an updated read validation token; Watson ¶ 0039: the client device 102 can transmit another sync request 130b and in response receive another notification 131b from the file server 106, indicating that the server copy 112b′ is now associated with a read validation token of two while the write validation token stays at one) making the plurality of workload files accessible to a plurality of third-party compute systems; (Watson FIG. 1, ¶ 0020-0024: the computer system 100 can include a file server 106 and a workflow server 126 interconnected with one or more client devices 102 via a computer network 104 … The file server 106 can be configured to provide shared storage of documents, sound files, photographs, movies, images, databases, or other suitable types of computer files to the client devices 102 over the computer network 104. For example, users 101 utilizing corresponding client devices 102 can retrieve, edit, save, or perform other suitable file operations on computer files managed by the file server 106 [see this aligning with the claimed workload input file based on instant specification para. 0008-0009 and para. 0026-0030]) … i) comparing a first hash stored on the central storage system to a first copy hash of the first copy stored on the first third-party compute system, (Watson ¶ 0007: the read or write validation token can include a hash (e.g., an XOR hash) of the computer file; Watson FIG. 4B, ¶ 0048: decision stage 211 to determine whether a read validation token of the local copy matches that of the server copy) …when the first hash is the same as the first copy hash, and (Watson ¶ 0007: the read or write validation token can include a hash (e.g., an XOR hash) of the computer file; Watson FIG. 4B, ¶ 0048: decision stage 211 to determine whether a read validation token of the local copy matches that of the server copy. In response to determining that the read validation token of the local copy matches that of the server copy, the process 210 can include indicating that file synchronization of the computer file is complete at stage 214) iii) providing a second copy of the first workload input file from the central storage system to the first third-party compute system to overwrite the first copy so the first workload is carried out using the second copy when the first hash is different than the first copy hash, (Watson ¶ 0007: the read or write validation token can include a hash (e.g., an XOR hash) of the computer file; Watson FIG. 4B, ¶ 0048: In response to determining that the read validation token of the local copy does not match that of the server copy, the process 210 can include downloading the server copy to overwrite the local copy at stage 212 before indicating that file synchronization of the computer file is complete at stage 214 [see this aligning with carrying out a first workload based on instant specification para. 0008-0009 and para. 0026-0030]) wherein the first workload file is one of the plurality of workload files, and wherein the respective hash associated with the first workload file is the first hash; (Watson ¶ 0007: the read or write validation token can include a hash (e.g., an XOR hash) of the computer file; Watson ¶ 0019: implementing a write validation token associated with individual copies of computer files in addition to a read validation token; Watson FIG. 4B, ¶ 0048: In response to determining that the read validation token of the local copy does not match that of the server copy…; Watson claim 7: the local token and the server token individually includes a hash value of the local copy and the server copy, respectively) receiving notification when the first workload on the first workload file is complete and a first workload output file has been created; and (Watson FIG. 4A, ¶ 0045-0047: the process 200 can include detecting a change in a local copy of a computer file at stage 202 ... the detected change can include other suitable user operations that create and/or modify the computer file; see Watson ¶ 0047: the process 200 can include uploading the changed local copy to overwrite the server copy in the repository 121 [relevant to first workload output file]) in response to receiving the notification that the first workload is complete, providing a copy of the first workload output file from the third-party compute system to the central storage when a first workload output file … is missing from the central storage, wherein the first workload output file is one of the one or more output files. (Watson FIG. 4A, ¶ 0045-0047, see first Watson ¶ 0045: the process 200 can include detecting a change in a local copy of a computer file at stage 202 ... the detected change can include other suitable user operations that create and/or modify the computer file; see then Watson ¶ 0046: The process 200 can then include obtaining state information of a corresponding server copy of the computer file at stage 204. In certain embodiments, the state information includes an existence or non-existence of a server copy of the computer file in, for example, the repository 121 of FIG. 2A [relevant to being missing from central storage]; see then Watson ¶ 0047: The process 200 can then include a decision stage 205 to determine whether the write validation token of the changed local copy matches that of the server copy. In response to determining that the write validation tokens match, the process 200 can include uploading the changed local copy to overwrite the server copy in the repository 121 [shows providing a copy of the first workload output file to the central storage]) Watson does not expressly disclose performing steps such as a comparison “in response to a first third-party compute system of the plurality of third-party compute systems having initiated a first workload intended to employ the first workload input file to create one or more output files and the first third-party compute system having a first copy of the first workload input file stored thereon on the first third-party compute system.” Watson further does not expressly disclose: ii) allowing the first third-party compute system to carry out the first workload using the first copy stored thereon when the first hash is the same as the first copy hash, Watson further does not expressly disclose a first workload output file hash is missing. However, Lee teaches: in response to a first third-party compute system of the plurality of third-party compute systems having initiated a first workload intended to employ the first workload input file to create one or more output files and the first third-party compute system having a first copy of the first workload input file stored thereon on the first third-party compute system, (Lee FIG. 2, ¶ 0049: The database environment 200 can include a client 204. Although a single client 204 is shown, the client 204 can represent multiple clients [shows a first of a plurality]; see Lee FIG. 10, ¶ 0162: generating a workload replay file [one or more output files], such as from a workload capture file [first workload input file] or other workload capture data. Workload capture data, such as a workload capture file, is received in step 1010 ... For each of the workload capture units, in step 1025, the collected execution context data and performance measure data are stored in a format replayable by a second database system; see Lee FIG. 16B, ¶ 0183: In step 1660, a request [shows having initiated] for a database operation of workload capture data...) i) comparing a first hash stored on the central storage system to a first copy hash of the first copy stored on the first third-party compute system, (Lee FIG. 16A, ¶ 0182: a method 1600 for determining hash values for a captured workload ... The data is hashed in step 1620 to produce a hash value. In step 1630 the hash value is stored in a capture file with execution context data and performance data associated with the request for a database operation; Lee FIG. 16B, ¶ 0183: In step 1660, a request for a database operation of workload capture data is executed at a second database system to generate execution data. In step 1670, a hash value is calculated for the execution data. The calculated hash value is compared, in step 1680, with a stored hash value [such as Lee ¶ 0182 above] associated with the execution of the request for a database operation at a first database system) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the file hash comparison of Lee with the file hash comparison of Watson. In addition, both of the references (Watson and Lee) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as file data/metadata hashing. Motivation to do so would be to improve the functioning of Watson involving using hashing to determine file status with the functioning in similar reference Lee also using hashing to determine file status but with the improvement of storing context and performance data alongside the hash. Motivation to do so would also be the teaching, suggestion, or motivation for one of ordinary skill in the art to improve database performance (Lee ¶ 0043) and to improve accuracy in database system verification techniques (Lee ¶ 0173). Watson in view of Lee does not expressly disclose: ii) allowing the first third-party compute system to carry out the first workload using the first copy stored thereon when the first hash is the same as the first copy hash, Watson in view of Lee further does not expressly disclose a first workload output file hash is missing. However, Imai teaches: ii) allowing the first third-party compute system to carry out the first workload using the first copy stored thereon when the first hash is the same as the first copy hash, and (Imai FIG. 8, ¶ 0075: In step S804, the verification processor 214 compares the hash data acquired in step S802 with that acquired in step S803. As a result of comparison, if the two data are equal to each other, the process advances to step S805. If the hash data acquired in step S802 is equal to that acquired in step S803, this means that no alterations etc. have been applied to the files 404 to 407 included in the selected folder 401; see then Imai ¶ 0079 showing the claimed workload being carried out: upon verification of the presence/absence of alterations etc. for files managed by the file management system, the processing can be executed for respective folders) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the hashing of Watson as modified with the hashing of Imai. In addition, both of the references (Watson as modified and Imai) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as file data/metadata hashing. Motivation to do so would be to improve the functioning of Watson as modified involving using hashing to determine file status with the functioning in similar reference Imai using hashing to determine file status but with added verification processing of propagated updates. Watson in view of Lee and Imai does not expressly disclose a first workload output file hash is missing. However, Penangwala addresses this by teaching: providing a copy of the first workload output file from the third-party compute system to the central storage when a first workload output file hash is missing… (Penangwala FIG. 5, ¶ 0100-0104, see primarily ¶ 0100: the process 500 can include determining whether a particular shared file includes an inconsistent file hash pairing ... In another aspect the inconsistent file hash pairing can include ... a missing a remote file hash for a remote instance of the particular shared file; see Penangwala ¶ 0103: At 506, if any files have been changed locally, the process 500 can proceed to 508 and the process 500 can further include uploading the files to the remote file system. In one aspect, the entire file that has been changed can be uploaded to the remote file system) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the hashing and file synchronization of Watson as modified with the hashing and file synchronization of Penangwala. In addition, both of the references (Watson as modified and Penangwala) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as file hashing and synchronization. Motivation to do so would be to improve the functioning of Watson as modified involving using hashing to determine file status with the functioning in similar reference Penangwala using hashing to determine file status but with the improved bidirectional synchronization. Regarding claims 2, 10, and 17, Watson in view of Lee and Imai and Penangwala teaches: in response to the first third-party compute system not having the first copy stored thereon, i) copy the first workload input file from the central storage system to the first third-party compute system so that the first third-party compute system can carry out the first workload to create the one or more output files (Penangwala FIG. 6, ¶ 0107-0110, see primarily ¶ 0107-0108: any differences between the current local hash list and the current master hash list can indicate that files have been changed, either remotely or locally … At 602, if any files have been updated remotely, or there are new files that are stored remotely, the process 500 can proceed to 604 and the process 500 can further include downloading the updated files and new files from the remote file system to the local file system. In one aspect, the entire file that has been updated, or otherwise changed, can be downloaded to the local file system) and ii) cause the first third-party compute system to create an output file hash for each of the one or more output files. (Lee FIG. 16A, ¶ 0182: a method 1600 for determining hash values for a captured workload according to this Example 4. In step 1610, execution data associated with the execution of a request for a database operation, such as query language statement or component thereof, is generated. The data is hashed in step 1620 to produce a hash value. In step 1630 the hash value is stored in a capture file with execution context data and performance data associated with the request for a database operation) Regarding claim 4, Watson in view of Lee and Imai and Penangwala teaches: determine that the first workload input file has a filename the same as the filename of the first copy. (Watson ¶ 0007: the read or write validation token can include a hash (e.g., an XOR hash) of the computer file; Watson FIG. 4B, ¶ 0048: decision stage 211 to determine whether a read validation token of the local copy matches that of the server copy. In response to determining that the read validation token of the local copy matches that of the server copy, the process 210 can include indicating that file synchronization of the computer file is complete at stage 214) Watson also teaches that the first workload input file has a filename. (Watson ¶ 0034: the sync agent 108 can detect the presence of the local copy 112a of the computer file 112 and determine that synchronization of the computer file 112 is needed based on, for example, metadata associated with the computer file 112 that indicates a lack of synchronization (e.g., having an empty last synchronized date/time) of the computer file 112 ... the sync request 130a can include data representing certain information associated with the computer file 112. Such information can include, for example, file name, date/time created, authored by, file size, or other suitable information) Regarding claim 5, Watson in view of Lee and Imai and Penangwala teaches: cause the first third-party compute system to has the second copy stored thereon to create a second copy hash stored on the first third-party compute system; and (Imai FIG. 10, ¶ 0061: In step S609, the hash processor 213 multiplexes the hash data in the folder, appends the folder name of that folder, and then executes the hash processing again. In the example of FIG. 5, the processor 213 multiplexes the hash data 504 and 508 in the folder 401 to generate hash data 509, appends the folder name of the folder 401 to the hash data 509, and then executes the hash processing again. In this way, hash data 510 is generated) compare the second copy hash to the first hash to ensure accuracy of the transfer of the second copy from the central storage to the third-party compute system. (Imai FIG. 8, ¶ 0074-0075: step S804, the verification processor 214 compares the hash data acquired in step S802 with that acquired in step S803. As a result of comparison, if the two data are equal to each other, the process advances to step S805 … the processor 214 notifies "verification OK" (displays it on the user interface 300) in step S805) Regarding claims 7 and 13, Watson in view of Lee and Imai and Penangwala teaches: wherein one or more of the plurality of third-party compute systems is a cloud computing system. (Lee FIG. 25, ¶ 0222-0223: The cloud computing services 2510 are utilized by various types of computing devices (e.g., client computing devices), such as computing devices 2520, 2522, and 2524) Regarding claim 19, Watson in view of Lee and Imai and Penangwala teaches: hashing the one or more output files transferred to the central storage and storing each respective hash on the central storage (Imai FIG. 10, ¶ 0061: In step S609, the hash processor 213 multiplexes the hash data in the folder, appends the folder name of that folder, and then executes the hash processing again. In the example of FIG. 5, the processor 213 multiplexes the hash data 504 and 508 in the folder 401 to generate hash data 509, appends the folder name of the folder 401 to the hash data 509, and then executes the hash processing again. In this way, hash data 510 is generated) Claims 8 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Watson in view of Lee and Imai and Penangwala in view of Bhatnagar et al., U.S. Patent Application Publication No. 2021/0365329 (filed May 19, 2020, prior to the instant application date of April 19, 2021; hereinafter Bhatnagar). Regarding claims 8 and 14, Watson in view of Lee and Imai and Penangwala teaches all the features with respect to claims 1 and 9 above but does not expressly disclose: wherein one or more of the plurality of third-party compute systems is a bare-metal computing system. However, Bhatnagar teaches: wherein one or more of the plurality of third-party compute systems is a bare-metal computing system. (Bhatnagar ¶ 0086: the VMs/container sets 702 comprise respective containers implemented using virtualization infrastructure 704 that provides operating system level virtualization functionality, such as support for Docker containers running on bare metal hosts, or Docker containers running on VMs) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the cloud computing systems of Watson as modified with the cloud computing systems of Bhatnagar. In addition, both of the references (Watson as modified and Bhatnagar) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as file synchronization. Motivation to do so would be to improve the functioning of Watson as modified performing data synchronization in a networked device environment with the functioning in similar reference Bhatnagar also performing data synchronization in a networked device environment but doing so with the other implementations of the processing platform comprising cloud infrastructure. Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to effectively improve the efficiency of managing cloud storage resources (Bhatnagar ¶ 0079). Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Watson in view of Penangwala. Regarding claim 20, Watson teaches: A system comprising: a server configured to run a synchronization system configured to: (Watson FIGs. 2, ¶ 0031-0032: The file server 120 can include an interface component 122 and a sync controller 124 operatively coupled to a repository 121 for storing computer files ... The sync controller 124 can be configured to manage synchronization of copies of computer files in the repository 121) identify a first workload file on a central storage; [and] hash the first workload file of the central storage, wherein the hash of the first workload file of the central storage is a first hash; (Watson ¶ 0007: a file server can assign a read validation token and a write validation token to an uploaded computer file ... at least one of the read or write validation token can be generated and/or predicted based on a protocol followed by both a file server and client devices. For example, in one embodiment, the read or write validation token can include a hash (e.g., an XOR hash) of the computer file; Watson ¶ 0019: when metadata is inserted into a server copy, the server copy with the inserted metadata can have an updated read validation token; Watson ¶ 0039: the client device 102 can transmit another sync request 130b and in response receive another notification 131b from the file server 106, indicating that the server copy 112b′ is now associated with a read validation token of two while the write validation token stays at one) identify a first workload file on a first compute system remote from the central storage; [and] cause the first workload file of the compute system to be hashed, wherein the hash of the first workload file of [the] first compute system is a second hash; (Watson ¶ 0007: the read or write validation token can include a hash (e.g., an XOR hash) of the computer file; Watson FIG. 4B, ¶ 0048: decision stage 211 to determine whether a read validation token of the local copy [shows a hash of a first workload file of a first compute system remote from the central storage] matches that of the server copy. In response to determining that the read validation token of the local copy matches that of the server copy, the process 210 can include indicating that file synchronization of the computer file is complete at stage 214; Watson claim 7: the local token and the server token individually includes a hash value of the local copy and the server copy, respectively) determine, based on a comparison of the first hash to the second hash, that the first workload file on the central storage is different than the first workload file on the first compute system; [and] automatically copy the first workload file on the central storage to the first compute system to overwrite the first workload file on the first compute system so that a compute system workload will be performed using the copy of the firs workload file from the central storage; (Watson ¶ 0007: the read or write validation token can include a hash (e.g., an XOR hash) of the computer file; Watson FIG. 4B, ¶ 0048: In response to determining that the read validation token of the local copy does not match that of the server copy, the process 210 can include downloading the server copy to overwrite the local copy at stage 212 before indicating that file synchronization of the computer file is complete at stage 214 [see this aligning with carrying out a first workload based on instant specification para. 0008-0009 and para. 0026-0030]) receive a notification that the first compute system has carried out the compute system workload on the first workload file and that [and] a first workload output file has been created; and (Watson FIG. 4A, ¶ 0045-0047: the process 200 can include detecting a change in a local copy of a computer file at stage 202 ... the detected change can include other suitable user operations that create and/or modify the computer file; see Watson ¶ 0047: the process 200 can include uploading the changed local copy to overwrite the server copy in the repository 121 [relevant to first workload output file]) determine that a first workload output file … is missing from the central stor[a]ge, [and] in response to the determination that the first workload output file … is missing from the central storage, copy the first workload output file to the central storage. (Watson FIG. 4A, ¶ 0045-0047, see first Watson ¶ 0045: the process 200 can include detecting a change in a local copy of a computer file at stage 202 ... the detected change can include other suitable user operations that create and/or modify the computer file; see then Watson ¶ 0046: The process 200 can then include obtaining state information of a corresponding server copy of the computer file at stage 204. In certain embodiments, the state information includes an existence or non-existence of a server copy of the computer file in, for example, the repository 121 of FIG. 2A [relevant to being missing from central storage]; see then Watson ¶ 0047: The process 200 can then include a decision stage 205 to determine whether the write validation token of the changed local copy matches that of the server copy. In response to determining that the write validation tokens match, the process 200 can include uploading the changed local copy to overwrite the server copy in the repository 121 [shows providing a copy of the first workload output file to the central storage]) Watson also teaches: wherein the first workload output file hash is a hash of a first workload output file; and (Watson ¶ 0007: the read or write validation token can include a hash (e.g., an XOR hash) of the computer file; Watson FIG. 4B, ¶ 0048: In response to determining that the read validation token of the local copy does not match that of the server copy… [shows workload output file]; Watson claim 7: the local token and the server token individually includes a hash value of the local copy and the server copy, respectively) Watson does not expressly disclose a first workload output file hash is missing. However, Penangwala addresses this by teaching determining determine that a first workload output file hash is missing. (Penangwala FIG. 5, ¶ 0100-0104, see primarily ¶ 0100: the process 500 can include determining whether a particular shared file includes an inconsistent file hash pairing ... In another aspect the inconsistent file hash pairing can include ... a missing a remote file hash for a remote instance of the particular shared file; see Penangwala ¶ 0103: At 506, if any files have been changed locally, the process 500 can proceed to 508 and the process 500 can further include uploading the files to the remote file system. In one aspect, the entire file that has been changed can be uploaded to the remote file system) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the hashing and file synchronization of Watson with the hashing and file synchronization of Penangwala. In addition, both of the references (Watson and Penangwala) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as file hashing and synchronization. Motivation to do so would be to improve the functioning of Watson involving using hashing to determine file status with the functioning in similar reference Penangwala using hashing to determine file status but with the improved bidirectional synchronization. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Vigil et al., U.S. Patent Application Publication No. 2021/0382727; see Vigil ¶ 0013, "the user device 110 can request the cloud computing platform 120 to launch a workload using a configuration file that includes a reference to the launched configuration container 122" and Vigil ¶ 0025, "The API server 128 can receive the request to launch the workload using the configuration file 126"; relevant to at least the independent claim limitations involving having initiated workloads employing workload input files and to the dependent claims 7 and 13 limitations involving cloud computing systems 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 nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEDIDIAH P FERRER whose telephone number is (571)270-7695. The examiner can normally be reached Monday-Friday 12:00pm-8:00pm. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kavita Stanley can be reached at (571)272-8352. 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. /J.P.F/Examiner, Art Unit 2153 December 27, 2025 /KRIS E MACKES/Primary Examiner, Art Unit 2153
Read full office action

Prosecution Timeline

Apr 18, 2022
Application Filed
Aug 05, 2023
Non-Final Rejection — §103
Oct 11, 2023
Applicant Interview (Telephonic)
Oct 11, 2023
Examiner Interview Summary
Dec 04, 2023
Response Filed
Mar 30, 2024
Final Rejection — §103
Jun 10, 2024
Response after Non-Final Action
Jul 22, 2024
Response after Non-Final Action
Aug 22, 2024
Request for Continued Examination
Aug 27, 2024
Response after Non-Final Action
Jun 14, 2025
Non-Final Rejection — §103
Aug 27, 2025
Examiner Interview Summary
Aug 27, 2025
Applicant Interview (Telephonic)
Sep 17, 2025
Response Filed
Dec 27, 2025
Final Rejection — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12585617
DYNAMIC SCRIPT GENERATION FOR AUTOMATED FILING SERVICES
2y 5m to grant Granted Mar 24, 2026
Patent 12572502
LOAD-AWARE DIRECTORY MIGRATION METHOD AND SYSTEM IN DISTRIBUTED FILE SYSTEM
2y 5m to grant Granted Mar 10, 2026
Patent 12566672
LEVERAGING BACKUP PROCESS METADATA FOR CLOUD OBJECT STORAGE SELECTIVE DELETIONS
2y 5m to grant Granted Mar 03, 2026
Patent 12517698
MAINTAINING STREAMING PARITY IN LARGE-SCALE PIPELINES
2y 5m to grant Granted Jan 06, 2026
Patent 12499120
Methods and Systems for Tracking Data Lineage from Source to Target
2y 5m to grant Granted Dec 16, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

5-6
Expected OA Rounds
52%
Grant Probability
91%
With Interview (+39.6%)
4y 1m
Median Time to Grant
High
PTA Risk
Based on 220 resolved cases by this examiner. Grant probability derived from career allow 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