DETAILED ACTION
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 .
This Office Action is in response to amendments filed on January 26, 2026.
Claims 1-20 are pending.
Claims 1, 8 and 15 have been amended.
Response to Amendment
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-5, 8-12 and 15-19 are rejected under 35 U.S.C. 103 as being unpatentable over Fan et al. (US 2016/0070578) in view of Sobel et al. (US 8,762,980) and in further view of Sudhakar et al. (US 9,563,640).
With respect to Claim 1, Fan et al. disclose:
in response to determining that a first subsequent version of a plurality of subsequent versions of a package is available, generating a repository corresponding to the package; (server contains a database/repository of update files that contains update file from version one to version two (first subsequent version) and version two to version three (plurality of subsequent version) and version three to version four (plurality of subsequent version), Paragraph 23)
generating a [upgrade file] between a current version of the package and the first subsequent version of the package; (in order for server to have a database/repository of upgrade file from version one (current version) to version two (first subsequent version), it must have been generated at some point, Paragraph 23)
committing, by a processing device, the [upgrade file] between the current version of the package and the first subsequent version of the package to the repository; (the server database/repository of upgrade file from version one (current version) to version two (first subsequent version) must have been stored (committed) at some point in order for it to be acquired by the processing component, Paragraph 23)
and for each further subsequent version of the plurality of subsequent versions of the package that is determined to be available: (server contains a database/repository of upgrade files that contains update file from version one to version two and version two to version three (further subsequent version) and version three to version four (further subsequent version), Paragraph 23)
generating a [upgrade file] between the further subsequent version of the package and an immediately preceding version of the package; (in order for server to have a database/repository of upgrade file from version two (immediately preceding version) to version three (further subsequent version), it must have been generated at some point, Paragraph 23; same goes for upgrade file from version three to version four)
Fan et al. do not disclose:
[upgrade file] is a delta difference file
wherein a volume of discreet repositories comprising a delta difference history is created within the repository, wherein the delta difference history includes the delta difference between each existing version, such that the processing device is to compile a prior version of the package by removal of changes made by subsequent versions of the package on the current version of the package based on the delta difference between the prior version of the package and the current version of the package;
committing, to the repository, each subsequent delta difference between the further subsequent version of the package and a corresponding immediately preceding version of the package each time a new subsequent version of the package is released;
identifying a particular version of the package where an error is present based on an examination of a history of the subsequent delta difference between the particular version of the package comprising the error and a prior particular version of the package without the error to identify a particular delta difference comprising the error;
and rebuilding the package, to remove the error, based on the prior particular version of the package without the error and an associated delta difference between the prior particular version of the package without the error and the particular version of the package where the error is present.
However, Sobel et al. disclose:
[upgrade file] is a delta difference file (These patches 311 comprise information for performing the operations to modify one version of a sequential dataset 303 into another version (this can be called a delta, a diff or a differencing file), Column 5, lines 27-30)
wherein a volume of discreet repositories comprising a delta difference history is created within the repository, (rolling incremental update system comprises a patches database which includes a plurality of forward and backward patches 311 (delta difference history) such as backward patches from E to D and D to C, Column 7, lines 28-36) wherein the delta difference history includes the delta difference between each existing version, (patches 311 comprises information for performing the operations to modify one version of a sequential dataset to another version (this is called a delta, a diff or a differencing file), Column 5, lines 27-30) such that the processing device is to compile a prior version of the package by removal of changes made by subsequent versions of the package on the current version of the package based on the delta difference between the prior version of the package and the current version of the package (if the client 103 rolled out version E (current version) but wants to roll back to version C (prior version), the client 103 informs the rolling incremental update system 101 of this. The rolling incremental update system 101 then generates a backwards direct delta 301 from version E to version C (delta difference between the prior version and the current version) as described above by merging the backwards patch 311 from E to D and the one from D to C (compiling a prior version of the package which removes changes made in version E and version D (subsequent versions)). The transmitting module 315 transmits the direct delta 301 to the client 103, which can use it to restore earlier, known good version C throughout the organization (compile a prior version), Column 7, lines 26-35)
identifying a particular version of the package where an error is present based on an examination of a history of the subsequent delta difference between the particular version of the package comprising the error and a prior particular version of the package without the error to identify a particular delta difference comprising the error; (To recover from the distribution of a version that turns out to be problematic after the fact (identify a particular version of the package where an error is present), the client 103 can request an earlier version (e.g., the named version) from the rolling incremental update system 101 (examination of a history/identify that the forward patch from version D to version E contains the error). For example, if the client 103 rolled out version E (particular version with the error) but wants to roll back to version C (prior particular version without the error), the client 103 informs the rolling incremental update system 101 of this., Column 7, lines 20-36)
and rebuilding the package, to remove the error, based on the prior particular version of the package without the error and an associated delta difference between the prior particular version of the package without the error and the particular version of the package where the error is present. (To recover from the distribution of a version that turns out to be problematic after the fact, the client 103 can request an earlier version (e.g., the named version) from the rolling incremental update system 101. For example, if the client 103 rolled out version E but wants to roll back to version C, the client 103 informs the rolling incremental update system 101 of this. The rolling incremental update system 101 then generates a backwards direct delta 301 from version E to version C as described above by merging the backwards patch 311 from E to D and the one from D to C. (rebuilding the package) The transmitting module 315 transmits the direct delta 301 to the client 103, which can use it to restore earlier, known good version C (remove the error) throughout the organization., Column 7, lines 20-36)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Sobel et al. into the teaching of Fan et al. to include [upgrade file] is a delta difference file and wherein a volume of discreet repositories comprising a delta difference history is created within the repository, wherein the delta difference history includes the delta difference between each existing version, such that the processing device is to compile a prior version of the package by removal of changes made by subsequent versions of the package on the current version of the package based on the delta difference between the prior version of the package and the current version of the package, identifying a particular version of the package where an error is present based on an examination of a history of the subsequent delta difference between the particular version of the package comprising the error and a prior particular version of the package without the error to identify a particular delta difference comprising the error;
and rebuilding the package, to remove the error, based on the prior particular version of the package without the error and an associated delta difference between the prior particular version of the package without the error and the particular version of the package where the error is present in order to allow a client to recover from a distribution of a version that turns out to be problematic after the fact and rollback to any earlier version and to maintain multiple versions of a file without storing the full file set for each version. (Sobel et al., Abstract and Column 7, lines 1-3 and lines 22-25 respectively)
Fan et al. and Sobel et al. do not explicitly disclose:
committing, to the repository, each subsequent delta difference between the further subsequent version of the package and a corresponding immediately preceding version of the package each time a new subsequent version of the package is released.
However, Sudhakar et al. disclose:
committing, to the repository, each subsequent delta difference between the further subsequent version of the package and a corresponding immediately preceding version of the package each time a new subsequent version of the package is released. (the versioning service captures changes made to the base file at a second time or interval (package is released). The changes are noted as a delta file or data structure between the file associated with a first snapshot (immediately preceding version) and the file associated with the new or second snapshot (further subsequent version). [T]he versioning service may iterate the processing for yet more changes at more times (or intervals) to capture still more deltas (each time a new subsequent version of the package is released). Each new delta represents a different version of the base file and each delta is stored in the versioning or the archive storage (committing to the repository)., Columns 3 and 4, lines 62-67 and 1-30 respectively)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Sudhakar et al. into the teaching of Fan et al. and Sobel et al. to include committing, to the repository, each subsequent delta difference between the further subsequent version of the package and a corresponding immediately preceding version of the package each time a new subsequent version of the package is released in order to quickly locate and upgrade or revert a file’s version after changes have been made.
With respect to Claim 2, all the limitations of Claim 1 have been addressed above; and Fan et al. further disclose:
further comprising:
in response to receiving a request to update the package to a particular subsequent version of the package, (request to acquire files corresponding to a plurality of upgrading versions higher than the current version, Paragraph 22, lines 7-11) retrieving from the repository, [an upgrade file] corresponding to the particular subsequent version of the package and [an upgrade file] corresponding to each subsequent version of the package before the particular subsequent version of the package; (receiving the upgrade files corresponding to the plurality of upgrading versions higher than the current version, Paragraph 24)
and building the particular subsequent version of the package based on the current version of the package and each of the retrieved [upgrade file]. (Fan et al., see Figure 1; upgrading the current version to the target version using the upgrade file(s), Paragraph 29)
Fan et al. do not disclose:
[upgrade file] is a delta difference file
However, Sobel et al. and/or Sudhakar et al. disclose:
[upgrade file] is a delta difference file (Sobel et al., These patches 311 comprise information for performing the operations to modify one version of a sequential dataset 303 into another version (this can be called a delta, a diff or a differencing file), Column 5, lines 27-30; Sudhakar et al., Thus, the archive volume includes deltas that represent the versions of the files and a file version history and does not include entire copies of files with slight changes or modifications., Column 4, lines 6-16)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Sobel et al. and/or Sudhakar et al. into the teaching of Fan et al. to include the [upgrade file] is a delta difference file in order to maintain multiple versions of a file without storing the full file set for each version (Sobel et al., Abstract, lines 1-4) and to save a considerable amount of storage space in the archive volume and is more processor efficient since the archive server that maintains the archive volume does not have to index, store, retrieve and process entire files for a new version; rather a delta is used to reflect a particular version. (Sudhakar et al., Column 4, lines 11-16)
With respect to Claim 3, all the limitations of Claim 2 have been addressed above; and Fan et al. further disclose:
wherein building the particular subsequent version of the package comprises:
adding changes indicated by each of the retrieved [upgrade file] to the current version of the package. (component upgrades can provide new version of components and enhancements (adding changes), Paragraphs 4 and Abstract)
Fan et al. do not disclose:
[upgrade file] is a delta difference file
However, Sobel et al. and/or Sudhakar et al. disclose:
[upgrade file] is a delta difference file (Sobel et al., These patches 311 comprise information for performing the operations to modify one version of a sequential dataset 303 into another version (this can be called a delta, a diff or a differencing file), Column 5, lines 27-30; Sudhakar et al., Thus, the archive volume includes deltas that represent the versions of the files and a file version history and does not include entire copies of files with slight changes or modifications., Column 4, lines 6-16)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Sobel et al. and/or Sudhakar et al. into the teaching of Fan et al. to include the [upgrade file] is a delta difference file in order to maintain multiple versions of a file without storing the full file set for each version (Sobel et al., Abstract, lines 1-4) and to save a considerable amount of storage space in the archive volume and is more processor efficient since the archive server that maintains the archive volume does not have to index, store, retrieve and process entire files for a new version; rather a delta is used to reflect a particular version. (Sudhakar et al., Column 4, lines 11-16)
With respect to Claim 4, all the limitations of Claim 1 have been addressed above; and Fan et al. and Sudhakar et al. do not disclose:
further comprising:
in response to receiving a request to revert to a particular previous version among a plurality of previous versions of the package, retrieving from the repository, a delta difference corresponding to the current version of the package and each previous version after the particular previous version of the package;
and building the particular previous version of the package based on the current version of the package and the retrieved delta differences.
However, Sobel et al. disclose:
further comprising:
in response to receiving a request to revert to a particular previous version among a plurality of previous versions of the package, (receiving a request to revert to a named/specific version of the sequential dataset (plurality of previous versions), Column 2, lines 38-51) retrieving from the repository, a delta difference corresponding to the current version of the package and each previous version after the particular previous version of the package; (multiple patches of the patch chain from a current version of the sequential dataset back to the named version are merged (retrieving a delta difference), Column 2, lines 38-51; patches comprise information for performing the operations to modify one version of a sequential dataset into another version (this can be called a delta, a diff or a differencing file), Column 5, lines 27-30)
and building the particular previous version of the package based on the current version of the package and the retrieved delta differences. (the direct delta is transmitted to the client so that the client can perform the reversion (build the particular previous version of the package), Column 2, lines 49-51)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Sobel et al. into the teaching of Fan et al. and Sudhakar et al. to include in response to receiving a request to revert to a particular previous version among a plurality of previous versions of the package, retrieving from the repository, a delta difference corresponding to the current version of the package and each previous version after the particular previous version of the package and building the particular previous version of the package based on the current version of the package and the retrieved delta differences in order to allow a user to revert to a previous version than the current version. (Sobel et al., Paragraph 2, lines 38-51)
With respect to Claim 5, all the limitations of Claim 4 have been addressed above; and Fan et al. and Sudhakar et al. do not disclose:
wherein building the particular previous version of the package comprises:
subtracting changes indicated by each of the retrieved delta differences from the current version of the package.
However, Sobel et al. disclose:
wherein building the particular previous version of the package comprises:
subtracting changes indicated by each of the retrieved delta differences from the current version of the package. (multiple patches of the patch chain from a current version of the sequential dataset back to the named version are merged (retrieving a delta difference), Column 2, lines 38-51; patches comprise information for performing the operations to modify one version of a sequential dataset into another version (this can be called a delta, a diff or a differencing file), Column 5, lines 27-30; reverting means removing the newest content and rolling back to older content (subtracting changes), Columns 5 and 6, lines 64-67 and 1-8 respectively)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Sobel et al. into the teaching of Fan et al. and Sudhakar et al. to include subtracting changes indicated by each of the retrieved delta differences from the current version of the package in order to revert to a previous version where the oldest content is maintained and the newest content is not preserved. (Sobel et al., Columns 5 and 6, lines 64-67 and 1-8 respectively)
Claims 8-12 are system claims corresponding to the method claims above (Claims 1-5) and, therefore, are rejected for the same reasons set forth in the rejections of Claims 1-5.
Claims 15-19 are non-transitory computer-readable medium claims corresponding to the method claims above (Claims 1-5) and, therefore, are rejected for the same reasons set forth in the rejections of Claims 1-5.
Claims 6, 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Fan et al. (US 2016/0070578) in view of Sobel et al. (US 8,762,980) in view of Sudhakar et al. (US 9,563,640) and in further view of Chen (US 2012/0023373).
With respect to Claim 6, all the limitations of Claim 1 have been addressed above; and Fan et al. and Sudhakar et al. do not disclose:
using a debugging tool to select one or more particular previous versions of the package to analyze to determine a previous version where a change was introduced;
and for each of the one or more particular previous versions of the package:
retrieving from the repository, a delta difference corresponding to the current version of the package and each previous version after the particular previous version of the package;
and building the particular previous version of the package based on the current version of the package and each of the retrieved delta differences.
However, Sobel et al. disclose:
using a tool to select one or more particular previous versions of the package; (a client (tool) requests to revert to a working named version of the sequential dataset previous to the current version is received (select one or more particular previous versions) after an error or problem with an update, Columns 1 and 2, lines 31-33 and 38-51 respectively)
and for each of the one or more particular previous versions of the package:
retrieving from the repository, a delta difference corresponding to the current version of the package and each previous version after the particular previous version of the package; (multiple patches of the patch chain from a current version of the sequential dataset back to (revert) the named version are merged (retrieving a delta difference), Column 2, lines 38-51; patches comprise information for performing the operations to modify one version of a sequential dataset into another version (this can be called a delta, a diff or a differencing file), Column 5, lines 27-30)
and building the particular previous version of the package based on the current version of the package and each of the retrieved delta differences. (the direct delta is transmitted to the client so that the client can perform the reversion, Column 2, lines 49-51)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Sobel et al. into the teaching of Fan et al. and Sudhakar et al. to include using a tool to select one or more particular previous versions of the package and for each of the one or more particular previous versions of the package, retrieving from the repository, a delta difference corresponding to the current version of the package and each previous version after the particular previous version of the package and building the particular previous version of the package based on the current version of the package and each of the retrieved delta differences in order to allow a user to rollback to any previous version that they desire.
Fan et al., Sobel et al. and Sudhakar et al. do not disclose:
using a debugging tool to analyze to determine a previous version where a change was introduced
However, Chen discloses:
using a debugging tool to analyze to determine a previous version where a change was introduced (One benefit of performing the partial run from the latest change to the earliest change is that, (previous version) in some cases, a given version may fail a test due to an early change, later pass due to a later change (e.g., a fix), and then fail again due to an even later change, Paragraph 36; a using a working system (debugger tool) to identify a change that caused a failure when the version that first introduced that change (e.g., change 98) failed one or more tests that were different from the tests failed by the previous version that failed (e.g., the version containing change 99), Paragraph 36)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Chen into the teaching of Fan et al., Sobel et al. and Sudhakar et al. to include using a debugging tool to analyze to determine a previous version where a change was introduced in order to notify a developer that a previous version where a change was introduced may have caused new failures. (Chen, Paragraph 36, lines 32-34)
Claim 13 is a system claim corresponding to the method claim above (Claim 6) and, therefore, is rejected for the same reasons set forth in the rejection of Claim 6.
Claim 20 is a non-transitory computer-readable medium claim corresponding to the method claim above (Claim 6) and, therefore, is rejected for the same reasons set forth in the rejection of Claim 6.
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Fan et al. (US 2016/0070578) in view of Sobel et al. (US 8,762,980) in view of Sudhakar et al. (US 9,563,640) and in further view of Yasset Perez-Riverol et al. (“Ten Simple rules for Taking Advantage of Git and GitHub”, July 2016).
With respect to Claim 7, all the limitations of Claim 1 have been addressed above; and Fan et al., Sobel et al. and Sudhakar et al. do not disclose:
wherein the repository is a Git repository.
However, Yasset Perez-Riverol et al. disclose:
wherein the repository is a Git repository. (using a GIT repository, Page 4, Paragraph 1, lines 1-6)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Yasset Perez-Riverol et al. into the teaching of Fan et al., Sobel et al. and Sudhakar et al. to include wherein the repository is a Git repository in order to take advantage of the benefits of GIT repository such as being a distributed version control system which allows for collaboration and work to continue between users if the remote GitHub server is unavailable and being fault-tolerant which are advantages over centralized version control systems. (Yasset Perez-Riverol et al., Page 4, Paragraph 1, lines 1-6)
Claim 14 is a system claim corresponding to the method claim above (Claim 7) and, therefore, is rejected for the same reasons set forth in the rejection of Claim 7.
Response to Arguments
Applicant’s arguments, see Pages 10-12, filed January 26, 2026, with respect to §101 rejection of claims 1-20 have been fully considered and are persuasive. The §101 rejection of claims 1-20 has been withdrawn.
Applicant's arguments with respect to §103 filed January 26, 2026 have been fully considered but they are not persuasive.
Examiner’s Response:
The Examiner would first like to note that the Applicant has not provided a response/remarks to the §103 rejection of claims 1-20 in the Applicant’s arguments filed January 26, 2026. In light of the amendments to the independent claims, it is the Examiner’s position that previously cited prior art Sobel discloses the newly amended claim language. Specifically, Sobel discloses that in order to “recover from the distribution of a version that turns out to be problematic after the fact, the client 103 can request an earlier version (e.g., the named version) from the rolling incremental update system 101. For example, if the client 103 rolled out version E but wants to roll back to version C, the client 103 informs the rolling incremental update system 101 of this. The rolling incremental update system 101 then generates a backwards direct delta 301 from version E to version C as described above by merging the backwards patch 311 from E to D and the one from D to C. The transmitting module 315 transmits the direct delta 301 to the client 103, which can use it to restore earlier, known good version C (remove the error) throughout the organization.” (see Column 7, lines 20-36) The system identifies that version E, and thus, the forward patch from version D to version E (identify a delta difference comprising the error), contains an error based on knowing that previous versions, such as version C, are known good versions (examination of a history). A client can request to restore to known a good version C by executing a backwards direct delta that consists of backward patches from E to D and D to C (prior particular versions without the error).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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 LANNY N UNG whose telephone number is (571)270-7708. The examiner can normally be reached Mon-Thurs 6am-4pm.
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, Bradley Teets can be reached at 571-272-3338. 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.
/LANNY N UNG/Examiner, Art Unit 2197