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 Request for Continued Examination filed on June 22, 2026.
Claims 1-20 are pending.
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 filed June 22, 2026 have been fully considered but they are not persuasive.
In the Remarks, Applicant argues:
As an initial matter, Applicant respectfully notes a fundamental distinction between the claimed invention and the cited references. Fan is directed to upgrading a component of an electronic device by acquiring upgrade files corresponding to a plurality of versions higher than a current version and upgrading the component step-by-step until it reaches a target version. (Fan, Abstract; paragraphs [0022]-[0029].) Sobel is directed to providing direct deltas between the current and other versions of a sequential dataset, by which a client is updated to the current version or rolled back to an earlier, client-named version. (Sobel, Abstract; Column 1, line 60 - Column 2,
line 9.) Sudhakar is directed to versioning files by capturing changes to a base file at configurable intervals as deltas and storing the deltas in an archive volume. (Sudhakar, Abstract; Column 3, line 60 - Column 4, line 30.) None of Fan, Sobel, or Sudhakar identifies a particular version of a package where an error is present by examining a history of delta differences to identify the particular delta difference comprising the error, and none rebuilds the package to remove that error in the manner recited in independent claim 1.
The Office Action asserts that Sobel discloses "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," citing Column 7, lines 20-36 of Sobel. (Office Action, pp. 5-6.) Applicant respectfully disagrees. The cited and other relevant portions of Sobel provide:
It is to be noted that in some instances, clients 103 may not wish to use the current version of the dataset 303. . . . This feature can be used by the client 103 to setup a test group to vet a version of the dataset 303 prior to distribution throughout the organization. For example, a client 103 could use a test group to test the current version from the rolling incremental update system 101, while the rest of the organization uses an earlier (named) version that has already been tested and found satisfactory. When the current version has been sufficiently tested without an issue, an administrator at the client 103 can distribute the current version organization wide. 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 throughout the organization.
(Sobel, Column 7, lines 1-36.)
This describes a client-driven reversion to an earlier version that a human administrator has already selected as a "known good version." In Sobel, the client (i.e., a person) already knows that "a version . .. turns out to be problematic after the fact" and "informs the rolling incremental update system 101" which earlier version to restore - for example, electing to "roll back to version C," a "named version" that "has already been tested and found satisfactory." Sobel does not disclose "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," as recited in independent claim 1. Sobel never examines a history of delta differences (patches) to identify which version contains the error or to "identify a particular delta difference comprising the error"; instead, Sobel relies on a human administrator's prior testing to designate a "known good" named version and to inform the system of the desired rollback target. Therefore, Sobel is silent on the above-recited feature of independent claim 1.
In the Response to Arguments, the Examiner states that "[t]he system identifies that version E, and thus, the forward patch from version D to version E ... , contains an error based on knowing that previous versions, such as version C, are known good versions." (Office Action, p. 19.) Applicant respectfully disagrees. Knowing in advance that an earlier version C is a "known good version" is not "identifying a particular version of the package where an error is present based on an examination of a history of the subsequent delta difference . . . to identify a particular delta difference comprising the error," as recited in independent claim 1. Sobel's "known good version C" is "known good" only because it was previously vetted by a "test group" and "found satisfactory" by a human administrator (Sobel, Column 7, lines 9-25.), and not because Sobel performs "an examination of a history of the subsequent delta difference ... to identify a particular delta difference comprising the error," as recited in independent claim 1. Moreover, Sobel's system merges the backward patches from version E to version D and from version D to version C only to generate the rollback delta that is transmitted to the client (Sobel, Column 7, lines 30-36.); it does not examine or search the patch chain to determine which version contains the error or to "identify a particular delta difference comprising the error," as recited in independent claim 1. In Sobel, "the client 103 informs the rolling incremental update system 101" of the version to restore (Sobel, Column 7, lines 28-30.); the system does not, on its own, examine a history of delta differences to identify the particular version where the error is present or to "identify a particular delta difference comprising the error," as recited in independent claim 1. Therefore, Sobel is silent on this feature of independent claim 1.
Examiner’s Response:
Applicant argues that Sobel “never examines a history of delta differences (patches) to identify which version contains the error or to "identify a particular delta difference comprising the error" and “relies on a human administrator's prior testing to designate a "known good" named version and to inform the system of the desired rollback target.” The Examiner respectfully disagrees. As can be seen in the §103 rejection above, Sobel discloses that a user can identify that a particular version (i.e. version E) is problematic and requests to roll back to an earlier version such as version C. The identification of version E (particular version) and version C (prior particular version) to the rolling incremental update system in order to generate a backwards direct delta from version E to version C can be reasonably interpreted as the Applicant’s claim language of “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”. The current claim language does not preclude a user from identifying the particular version of the package where an error is present. The claim is also silent on what is involved in the “examination of a history of the subsequent delta difference”. Determining/deciding which version to revert to can be considered an “examination of a history” in that it identifies which version has the error and which version to revert to which does not have the error (known good version).
Further, Applicant argues in Sobel, “the system does not, on its own, examine a history of delta differences to identify the particular version where the error is present or to identify a particular delta difference comprising the error.” In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., system performs, on its own and without user intervention) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
In the Remarks, Applicant argues:
In addition, Sobel does not disclose "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," as recited in independent claim 1. As shown above, Sobel reverts a client to an earlier, user-selected named version by "generat[ing] a backwards direct delta 301 from version E to version C ... by merging the backwards patch 311 from E to D and the one from D to C" and transmitting that direct delta to the client. (Sobel, Column 7, lines 30-36.) Because Sobel does not first identify, through an examination of the delta difference history, "a prior particular version of the package without the error" or "a particular delta difference comprising the error," Sobel cannot disclose "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," as recited in independent claim 1. Therefore, Sobel is silent on this feature of independent claim 1 as well.
Fan and Sudhakar do not cure these deficiencies of Sobel. Fan upgrades a component "to a target version of the sequence of the versions" by selecting and applying upgrade files in chronological order (Fan, Abstract; paragraph [0029]), and is silent regarding any delta difference, any identification of a version where an error is present, or any rebuilding of a package to remove an error. Sudhakar captures "changes made to the base file at a second time . . . as a delta" and "stores the delta as a newer version of the base file in . . .archive storage" (Sudhakar, Column 4, lines 1-30), and is likewise silent regarding identifying a particular version where an error is present "based on an examination of a history of the subsequent delta difference . . . to identify a particular delta difference comprising the error" or "rebuilding the package, to remove the error," as recited in independent claim 1. Accordingly, the combination of Fan, Sobel, and Sudhakar fails to teach or suggest the above-recited features of independent claim 1.
Examiner’s Response:
The Examiner respectfully disagrees. Sobel discloses generating a backwards direct delta from version E (particular version where the error is present) to version C (prior particular version without the error). This can be done by merging the backwards patch from E to D and the one from D to C (associated delta difference). Further Sobel discloses transmitting the direct delta to the client, which can use it to restore earlier, known good version C. (see Column 7, lines 20-36) The restoring to an “earlier, known good version” means a prior particular version without the error is rebuilt. This disclose reads on the Applicant’s claim language of “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.”
Further, Applicant argues that “Fan and Sudhakar do not cure these deficiencies of Sobel.” As can be seen in the §103 rejection above, the Examiner has not relied on Fan or Sudhakar to disclose the “identifying a particular version of the package where an error is present…” and “rebuilding the package, to remove the error,…”.
In the Remarks, Applicant argues:
Moreover, because none of Fan, Sobel, or Sudhakar teaches or suggests the above-recited error-identification and rebuilding features of independent claim 1, the Examiner's proposed combination cannot reach independent claim 1 without impermissible hindsight reconstruction using Applicant's own claims as a template. A rejection under 35 U.S.C. § 103 must be supported by "some articulated reasoning with some rational underpinning to support the legal conclusion of obviousness." KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398, 418 (2007). The Office Action's stated rationale for incorporating Sobel-"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" (Office Action, pp. 7-8.) is directed to Sobel's user-initiated rollback to a previously designated known good version, and supplies no reason that a person of ordinary skill in the art would have been led to "an examination of a history of the subsequent delta difference . .. to identify a particular delta difference comprising the error" or to "rebuilding the package, to remove the error," as recited in independent claim 1. Because these features are absent from each of the cited references, the proposed combination fails to render independent claim 1 obvious.
Examiner’s Response:
In response to applicant's argument that the examiner's conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971).
Please see Examiner’s response above with respect to Applicant’s argument that Sobel does not disclose "an examination of a history of the subsequent delta difference . .. to identify a particular delta difference comprising the error" or to "rebuilding the package, to remove the error".
In the Remarks, Applicant argues:
Independent claims 8 and 15 recite similar limitations and are thus allowable for similar reasons as independent claim 1.
Dependent claims 2-5, 9-12, and 16-19 depend from independent claims 1, 8, and 15, respectively, and incorporate their respective base claim's allowable features. Thus, dependent claims 2-5, 9-12, and 16-19 are allowable for similar reasons as their respective independent claims, as well as for the additional distinguishing features that they recite.
Dependent claims 6, 13 and 20 depend from independent claims 1, 8, and 15,
respectively, and incorporate their respective base claim's allowable features. Chen (cited against claims 6, 13, and 20) does not cure, and is not cited to cure, the above-noted deficiencies of Fan, Sobel, and Sudhakar with respect to the independent claims. Thus, dependent claims 6, 13 and 20 are allowable for similar reasons as their respective independent claims, as well as for the additional distinguishing features that they recite.
Dependent claims 7 and 14 depend from independent claims 8 and 15 respectively, and incorporate their respective base claim's allowable features. Perez-Riverol (cited against claims 7 and 14) does not cure, and is not cited to cure, the above-noted deficiencies of Fan, Sobel, and Sudhakar with respect to the independent claims. Thus, dependent claims 7 and 14 are allowable for similar reasons as their respective independent claims, as well as for the additional distinguishing features that they recite.
Examiner’s Response:
Please see response to arguments above with respect to Claim 1.
Conclusion
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 6:30am-3:30pm.
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/Primary Examiner, Art Unit 2197
Prosecution Insights