DETAILED ACTION
The Office Action is in response to Remarks filed 11/10/2025.
Claims 1-12 are currently pending.
Claims 11-12 are currently amended.
The objection to claim 12 is withdrawn in view of applicant’s amendments to claim 12.
The rejection of claims 3, 6, 9, and 10-12 under 35 U.S.C. 112 have been withdrawn in view of applicant’s amendments and remarks.
The rejection of claims 7-10 under 35 U.S.C. 101 have been withdrawn in view of examiner’s further consideration of the claims.
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 .
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-6 and 11-12 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1 and 4 as drafted recites a process, under its broadest reasonable interpretation, that can be performed in the human mind with the aid of pen and paper, but for the recitation of generic computer/computing components. That is, the limitations " determining an existing feature set of software and all existing patches present in a system; and creating a software patch as an accretive patch that includes only features that are absent from the existing feature set in the software and all existing patches in the system, such that when the software patch is applied, the software together with all existing patches, that include the software patch, provides the desired feature set" can be practically performed by the human mind through observation, evaluation, judgement, and/or opinion with the aid of pen and paper. Thus, these limitations fall under the "Mental Processes" group of abstract ideas.
Claim 4 further recite additional elements that are not integrated into a practical application. That is, the claim recites the additional element " the system comprising a processor configured to which is recited at a high level of generality such that it amounts to no more than a mere generic computer/computing component to apply the abstract idea (See MPEP 2106.05(f)). Accordingly, the additional elements recited in the claims do not integrate the abstract idea into a practical application because they do not impose any meaningful limits upon practicing the abstract idea.
Claim 4 recites an additional element that does not amount to significantly more than the abstract idea. That is, the claim recites the additional element " the system comprising a processor... which is recited at a high level of generality such that it amounts to no more than a mere generic computer/computing component to apply the abstract idea (See MPEP 2106.05(f)). Accordingly, the additional element recited in the claim does not provide an inventive concept nor does it amount to significantly more. Thus, the claims are not patent eligible.
Claims 2 and 5 recite additional elements that are not integrated into a practical application. That is, the claims recite the additional element " in one-time programmable memory or random access memory of a target device" which is recited at a high level of generality such that it amounts to no more than mere generic computer/computing components to apply the abstract idea (See MPEP 2106.05(f)). The claims further recite the additional element "wherein the software patch is configured to be stored for the software patch" which is directed to the insignificant extra solution activity of mere data gathering (See MPEP 2106.05(g)). Accordingly, the additional elements recited in the claims do not integrate the abstract idea into a practical application because they do not impose any meaningful limits upon practicing the abstract idea.
The claims recite additional elements that do not amount to significantly more than the abstract idea. That is, the claims recite the additional element " in one-time programmable memory or random access memory of a target device" which is recited at a high level of generality such that it amounts to no more than mere generic computer/computing components to apply the abstract idea (See MPEP 2106.05(f)). The claims further recite "wherein the software patch is configured to be stored for the software patch" which has been determined as a well understood, routine, and/or conventional activity of electronic recordkeeping (See MPEP 2106.05(d)(II)). Accordingly, the additional elements recited in the claims cannot provide an inventive concept nor amount to significantly more. Thus, the claims are not patent eligible.
Claims 3 and 6 recite a process, under its broadest reasonable interpretation, that can be performed by the human mind with the aid of pen and paper. That is, the claims recite the limitation "creating the software patch such that executable code of the software patch updates a jump table stored in random access memory of a target device for the software patch to reference the desired feature set without altering jump table entries associated with the plurality of previously-applied patches." which is a process that can be practically performed by the human mind through observation, evaluation, judgement, and/or opinion with the aid of pen and paper. Thus, the limitation falls under the "Mental Processes" group of abstract ideas and the claims are not patent eligible.
Claims 11-12 recite a process, under its broadest reasonable interpretation, that can be performed by the human mind with the aid of pen and paper. That is, the claims recite the limitation "applying the software patch does not overwrite, delete, or disable any portion of the existing patches" which is a process that can be practically performed by the human mind through observation, evaluation, judgement, and/or opinion with the aid of pen and paper. Thus, the limitation falls under the "Mental Processes" group of abstract ideas and the claims are not patent eligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 4-5, and 7-8 are rejected under 35 U.S.C. 103 as being unpatentable over US 20070274598 hereinafter "Dahms" in view of US 20190369981 A1 hereinafter “Shan”.
With regards to claim 1, Dahms teaches
A method for generating a software patch with a desired feature set comprising one or more features, the method comprising:
determining an existing feature set of software and all existing patches present in a system; (Dahms [0017], “An incremental patch is generated as a series of delta files or sector-specific patches, intended to be applied incrementally to the old binary image [A method for generating a software patch with a desired feature set comprising one or more features]. Each sector-specific patch contains the commands for generating one sector of a new binary image. Each sector-specific patch takes into account changes to the binary image made by previous patches in the series since the image memory will contain a mixture of the old image and the new image at each incremental step of the patch process [determining an existing feature set of software]. The observation that the current image will often have useful information that can be referenced by a binary patch allows this method to produce smaller patches than systems that only refer to the old image. The sector-specific patches are generated by applying a binary difference algorithm to the then-current partially patched image, until each sector has a corresponding delta file.”) (Dahms [0039], “The incremental patch comprises the patches p1 to Pn· In some cases, the individual sector-based patches p1 to Pn [and all existing patches present in a system] may be referred to as "difference files" or "delta files". It will be appreciated that each sector-specific patch in the series of patches relies upon the then-current partially patched image 30 instead of the original old binary image 12.”)
creating a software patch as an accretive patch that includes only features that are absent from the existing feature set in the software and all existing patches in the system, (Dahms [0041], “In step 104, a delta file δ is computed from the current_image and sector bi of the new binary image. The delta file δ, or "difference file", is the sector-specific patch Pi used to obtain sector bi from the current_image. The delta file δ may be obtained by way of applying a suitable binary difference algorithm. The various binary difference algorithms available will be understood by those of ordinary skill in the art.”) (Dahms [0046], “The current_image at this stage of the method 200 is the old binary image. At step 204, a binary difference Is calculated between the current_image and the new binary image. The binary difference between the two images may be calculated using a binary difference algorithm in a manner that will be understood by those of ordinary skill in the art.”) [Examiner’s Note: A binary difference algorithm is used to determine missing features from the existing set of software in the system in order to generate the plurality of delta files. The delta files contain the set of software that is absent from the existing features.]
Dahms teaches all existing patches
However, Dahms does not explicitly teach,
such that when the software patch is applied, the software together with […] the software patch, provides the desired feature set.
However, in an analogous art Shan teaches such that when the software patch is applied, the software together with […] the software patch, provides the desired feature set. (Shan [0048-49], “The processing method further includes updating the target application from the first application version to the second application version according to the incremental update data of the target application relative to the first application version (at 302). In this way, the target application can be upgraded to from the first application version to the second application version [the software together … provides the desired feature set]. For example, the incremental update data may be a differential update package, and the differential update package records the difference between the installation data of the first application version and the installation data of the second application version. The target application can be upgraded from the first application version to the second application version by executing the incremental update data [such that when the software patch is applied]. For another example, the incremental update data may be a differential update file, and the differential update package records the difference between the application file of the first application version and the application file of the second application version.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Shan into the teachings of Dahms. This combination of teachings would have resulted in a system to create an incremental or accretive patch, as in Dahms, such that the application of a differential update package will apply the difference between versions to update the application accordingly, as in Shan. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of updating the application version while keeping the storage location unchanged (Shan [0029]).
With regards to claim 2, the rejection of claim 1 is incorporated.
Dahms further teaches wherein the software patch is configured to be stored in one-time programmable memory or random-access memory of a target device for the software patch. (Dahms [0054], "The incremental patch is stored in temporary memory in step 304. In one embodiment, the incremental patch may be stored in RAM memory resident on the mobile electronic device.")
Claims 4-5 are directed to a system corresponding to the method limitations as disclosed in claims 1-2 respectively. Thus, claims 4-5 are rejected for the same reasons set forth in claims 1-2.
With regards to claim 7, Dahms teaches
A method for using a software patch with a desired feature set comprising one or more features, the method comprising:
applying a software patch comprising an accretive patch that includes only features that are absent from an existing feature set in software and all existing patches in a system, (Dahms [0017], “An incremental patch is generated as a series of delta files or sector-specific patches, intended to be applied incrementally to the old binary image [A method for generating a software patch with a desired feature set comprising one or more features]. Each sector-specific patch contains the commands for generating one sector of a new binary image. Each sector-specific patch takes into account changes to the binary image made by previous patches in the series since the image memory will contain a mixture of the old image and the new image at each incremental step of the patch process [determining an existing feature set of software]. The observation that the current image will often have useful information that can be referenced by a binary patch allows this method to produce smaller patches than systems that only refer to the old image. The sector-specific patches are generated by applying a binary difference algorithm to the then-current partially patched image, until each sector has a corresponding delta file.”) (Dahms [0039], “The incremental patch comprises the patches p1 to Pn· In some cases, the individual sector-based patches p1 to Pn [and all existing patches present in a system] may be referred to as "difference files" or "delta files". It will be appreciated that each sector-specific patch in the series of patches relies upon the then-current partially patched image 30 instead of the original old binary image 12.”)
Dahms teaches all existing patches but does not explicitly teach: such that when the software patch is applied, the software together with [all existing patches, that include the software patch,] provides the desired feature set.
However, in an analogous art Shan teaches such that when the software patch is
applied, the software together […] provides the desired feature set. (Shan [0048-49], “The processing method further includes updating the target application from the first application version to the second application version according to the incremental update data of the target application relative to the first application version (at 302). In this way, the target application can be upgraded to from the first application version to the second application version [the software together … provides the desired feature set]. For example, the incremental update data may be a differential update package, and the differential update package records the difference between the installation data of the first application version and the installation data of the second application version. The target application can be upgraded from the first application version to the second application version by executing the incremental update data [such that when the software patch is applied]. For another example, the incremental update data may be a differential update file, and the differential update package records the difference between the application file of the first application version and the application file of the second application version.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Shan into the teachings of Dahms. This combination of teachings would have resulted in a system to create an incremental or accretive patch, as in Dahms, such that the application of a differential update package will apply the difference between versions to update the application accordingly, as in Shan. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of updating the application version while keeping the storage location unchanged (Shan [0029]).
With regards to claim 8, the rejection of claim 7 is incorporated.
Dahms further teaches wherein the software patch is configured to be stored in one-time programmable memory or random-access memory of a target device for the software patch. (Dahms [0054], "The incremental patch is stored in temporary memory in step 304. In one embodiment, the incremental patch may be stored in RAM memory resident on the mobile electronic device.")
Claims 3, 6, 9 are rejected under 35 U.S.C. 103 as being unpatentable over Dahms in view of Shan, as applied to claims 1, 4, and 7 respectively, in view of US 6260157 B1 hereinafter "Schurecht" and further in view of US 20070157178 A1 hereinafter "Kogan".
With regards to claim 3, the rejection of claim 1 is incorporated.
The combination of Dahms and Shan does not teach: creating the software patch such that executable code of the software patch updates a jump table stored in random access memory of a target device for the software patch to reference the desired feature set without altering jump table entries associated with the plurality of previously-applied patches.
However, in an analogous art Schurecht teaches creating the software patch such that executable code of the software patch updates a jump table stored in random access memory of a target device (Schurecht Column 6 Lines 35-40, "a new or updated patch vector table may be loaded from, for example, the external memory 7, into the data RAM 65 and the updated patch vector table may cause one or more patch programs (which are loaded into the program RAM 50) to be executed at the appropriate time.") for the software patch to reference the desired feature set [without altering jump table entries associated with the plurality of previously-applied patches.] (Schurecht Column 3 Lines 18-26, "A processor executes the program instructions in the program ROM and uses the patch vector table to execute the patch program when the processor reaches one of the jump instructions. If desired, the patch program may be initially stored in the RAM and the patch vector table may point to the address in the RAM at which the patch program is stored. In this case, the processor jumps directly to the RAM to execute the patch program when it reaches a jump instruction at which a patch is to be performed")
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Schurecht into the teachings of Dahms in view of Shan. This combination of teachings would have resulted in a system to create an incremental or accretive patch, as in Dahms, such that the application of a differential update package will apply the difference between versions to update the application accordingly, as in Shan, the patch referencing the differential reference set, as in Schurecht. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of using the software update to identify and locate a patch program using the addresses in a data table (Schurecht Column 3 Lines 35-40).
The combination of Dahms, Shan, and Schurecht teaches creating the software patch such that executable code of the software patch updates a jump table stored in random access memory of a target device for the software patch to reference the desired feature set but docs not explicitly teach: [creating the software patch such that executable code of the software patch updates a jump table stored in random access memory of a target device for the software patch to reference the desired feature set] without altering jump table entries associated with the plurality of previously-applied patches.
However, in an analogous art Kogan teaches […] without altering jump table entries associated with the plurality of previously-applied patches. (Kogan [0027], "The profile provided for each module contains an execution count of every basic block in the program and every edge of the corresponding control flow graph (CFG). An incremental disassembly method may be used to dissect the code into its basic blocks, as described in the above-mentioned articles by Haber et al. and by Henis et al., for example. For this purpose, addresses of instructions within the executable code are extracted from a variety of sources, in order to form a list of "potential entry points." The sources typically include program/DLL entry points, the symbol table (for functions and labels), and relocation tables (through which pointers to the code can be accessed). The processor traverses the program by following the control flow starting from these entry points--while resolving all possible control flow paths--and adding newly-discovered addresses of additional potential entry points to the list, such as targets of JUMP and CALL instructions.") [Examiner Note: By simply adding new addresses to jump to the code module this does not alter the addresses currently in the list added by previous patches]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Kogan into the teachings of Dahms, in view of Shan, and further in view of Schurecht. This combination of teachings would have resulted in a system to create an incremental or accretive patch, as in Dahms, such that the application of a differential update package will apply the difference between versions to update the application accordingly, as in Shan, the patch referencing the differential reference set, as in Schurecht, and new features/code modules to be applied in a new patch appends new addresses or entry points to a jump table that references the differential reference set, as in Kogan. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of providing a table of contents and procedure linkage table that defines access to functions and modules that are imported to the target device (Kogan [0022]).
With regards to claim 6, the rejection of claim 4 is incorporated.
The combination of Dahms and Shan does not teach: creating the software patch such that executable code of the software patch updates a jump table stored in random access memory of a target device for the software patch to reference the desired feature set without altering jump table entries associated with the plurality of previously-applied patches.
However, in an analogous art Schurecht teaches creating the software patch such that
executable code of the software patch updates a jump table stored in random access
memory of a target device (Schurecht Column 6 Lines 35-40, "a new or updated patch vector
table may be loaded from, for example, the external memory 7, into the data RAM 65 and the
updated patch vector table may cause one or more patch programs (which are loaded into the
program RAM 50) to be executed at the appropriate time.") for the software patch to reference
the desired feature set [without altering jump table entries associated with the plurality of
previously-applied patches.] (Schurecht Column 3 Lines 18-26, "A processor executes the
program instructions in the program ROM and uses the patch vector table to execute the patch
program when the processor reaches one of the jump instructions. If desired, the patch program
may be initially stored in the RAM and the patch vector table may point to the address in the
RAM at which the patch program is stored. In this case, the processor jumps directly to the RAM to execute the patch program when it reaches a jump instruction at which a patch is to be
performed")
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Schurecht into the teachings of Dahms in view of Shan. This combination of teachings would have resulted in a system to create an incremental or accretive patch, as in Dahms, such that the application of a differential update package will apply the difference between versions to update the application accordingly, as in Shan, the patch referencing the differential reference set, as in Schurecht. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of using the software update to identify and locate a patch program using the addresses in a data table (Schurecht Column 3 Lines 35-40).
The combination of Dahms, Shan, and Schurecht teaches creating the software patch such that executable code of the software patch updates a jump table stored in random access memory of a target device for the software patch to reference the desired feature set but docs not explicitly teach: [creating the software patch such that executable code of the software patch updates a jump table stored in random access memory of a target device for the software patch to reference the desired feature set] without altering jump table entries associated with the plurality of previously-applied patches.
However, in an analogous art Kogan teaches […] without altering jump table entries associated with the plurality of previously-applied patches. (Kogan [0027], "The profile provided for each module contains an execution count of every basic block in the program and every edge of the corresponding control flow graph (CFG). An incremental disassembly method may be used to dissect the code into its basic blocks, as described in the above-mentioned articles by Haber et al. and by Henis et al., for example. For this purpose, addresses of instructions within the executable code are extracted from a variety of sources, in order to form a list of "potential entry points." The sources typically include program/DLL entry points, the symbol table (for functions and labels), and relocation tables (through which pointers to the code can be accessed). The processor traverses the program by following the control flow starting from these entry points--while resolving all possible control flow paths--and adding newly-discovered addresses of additional potential entry points to the list, such as targets of JUMP and CALL instructions.") [Examiner Note: By simply adding new addresses to jump to the code module this does not alter the addresses currently in the list added by previous patches]
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Kogan into
the teachings of Dahms, in view of Shan, and further in view of Schurecht. This combination of teachings would have resulted in a system to create an incremental or accretive patch, as in Dahms, such that the application of a differential update package will apply the difference between versions to update the application accordingly, as in Shan, the patch referencing
the differential reference set, as in Schurecht, and new features/code modules to be applied in a
new patch appends new addresses or entry points to a jump table that references the differential
reference set, as in Kogan. One of ordinary skill in the art would have been motivated to
combine these teachings for the purpose of providing a table of contents and procedure linkage
table that defines access to functions and modules that are imported to the target device (Kogan
[0022]).
With regards to claim 9, the rejection of claim 7 is incorporated.
The combination of Dahms and Shan does not teach: creating the software patch such that executable code of the software patch updates a jump table stored in random access memory of a target device for the software patch to reference the desired feature set without altering jump table entries associated with the plurality of previously-applied patches.
However, in an analogous art Schurecht teaches creating the software patch such that
executable code of the software patch updates a jump table stored in random access
memory of a target device (Schurecht Column 6 Lines 35-40, "a new or updated patch vector
table may be loaded from, for example, the external memory 7, into the data RAM 65 and the
updated patch vector table may cause one or more patch programs (which are loaded into the
program RAM 50) to be executed at the appropriate time.") for the software patch to reference
the desired feature set [without altering jump table entries associated with the plurality of
previously-applied patches.] (Schurecht Column 3 Lines 18-26, "A processor executes the
program instructions in the program ROM and uses the patch vector table to execute the patch
program when the processor reaches one of the jump instructions. If desired, the patch program
may be initially stored in the RAM and the patch vector table may point to the address in the
RAM at which the patch program is stored. In this case, the processor jumps directly to the RAM
to execute the patch program when it reaches a jump instruction at which a patch is to be
performed")
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of Schurecht into
the teachings of Dahms in view of in view of Shan. This combination of teachings would have resulted in a system to create an incremental or accretive patch, as in Dahms, such that the application of a differential update package will apply the difference between versions to update the application accordingly, as in Shan, the patch referencing the differential reference set, as in Schurecht. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of using the software update to identify and locate a patch program using the addresses in a data table (Schurecht Column 3 Lines 35-40).
The combination of Dahms, Shan, and Schurecht teaches creating the software patch such that executable code of the software patch updates a jump table stored in random access memory of a target device for the software patch to reference the desired feature set but docs not explicitly teach: [creating the software patch such that executable code of the software patch updates a jump table stored in random access memory of a target device for the software patch to reference the desired feature set] without altering jump table entries associated with the plurality of previously-applied patches.
However, in an analogous art Kogan teaches […] without altering jump table entries associated with the plurality of previously-applied patches. (Kogan [0027], "The profile provided for each module contains an execution count of every basic block in the program and every edge of the corresponding control flow graph (CFG). An incremental disassembly method may be used to dissect the code into its basic blocks, as described in the above-mentioned articles by Haber et al. and by Henis et al., for example. For this purpose, addresses of instructions within the executable code are extracted from a variety of sources, in order to form a list of "potential entry points." The sources typically include program/DLL entry points, the symbol table (for functions and labels), and relocation tables (through which pointers to the code can be accessed). The processor traverses the program by following the control flow starting from these entry points--while resolving all possible control flow paths--and adding newly-discovered addresses of additional potential entry points to the list, such as targets of JUMP and CALL instructions.") [Examiner Note: By simply adding new addresses to jump to the code module this does not alter the addresses currently in the list added by previous patches]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Kogan into
the teachings of Dahms, in view of Shan, and further in view of Schurecht. This combination of teachings would have resulted in a system to create an incremental or accretive patch, as in Dahms, such that the application of a differential update package will apply the difference between versions to update the application accordingly, as in Shan, the patch referencing the differential reference set, as in Schurecht, and new features/code modules to be applied in a new patch appends new addresses or entry points to a jump table that references the differential reference set, as in Kogan. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of providing a table of contents and procedure linkage
table that defines access to functions and modules that are imported to the target device (Kogan [0022]).
Claims 10, 11, and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Dahms in view of Shan, as applied to claims 1, 4, 7 respectively, in view of US 20230112734 A1 hereinafter "Suryanarayana"
With regards to claim 10, the rejection of claim 7 is incorporated.
The combination of Dahms and Shan does not explicitly teach: applying the software patch does not overwrite, delete, or disable any portion of the existing patches.
However, in an analogous art Suryanarayana teaches applying the software patch does
not overwrite, delete, or disable any portion of the existing patches (Suryanarayana [0051],
"In some embodiments, the information handling system may perform the update at a word level,
such as updating only four character hexadecimal words that are different in the firmware update
from the current contents of the firmware module. Thus, the firmware update may be applied to
individual firmware modules of the information handling system. Updating firmware modules,
instead of overwriting an entire firmware volume or image including one or more firmware
modules to be updated, may reduce an amount of time required to implement the firmware
update. For example, some firmware modules may not require a system reboot for application of
a firmware update, but overwriting an entire firmware volume including the firmware modules
may require such a reboot. Thus, modular firmware updates may allow an information handling
system to update one or more modules of a firmware without overwriting an entire firmware
image or an entire firmware volume on a SPI flash firmware memory of the information
handling system.")
Therefore, it would have been obvious to one of ordinary skill in the art before the
effective filing date of the claimed invention to have incorporated the teachings of
Suryanarayana into the teachings of Dahms in view of Shan. This combination of teachings would have resulted in a system to create an incremental or accretive patch, as in Dahms, such that the application of a differential update package will apply the difference between versions to update the application accordingly, as in Shan, only using differential changes without overwriting previous modular updates, as in Suryanarayana. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of only updating the portions of the firmware module that differ from the current firmware image in memory to maintain efficiency by reducing system downtime for a firmware update (Suryanarayana [0010]).
With regards to claim 11, the rejection of claim 1 is incorporated.
The combination of Dahms and Shan does not explicitly teach: Such that when the software patch is applied, the software patch does not overwrite, delete, or disable any portion of the existing patches.
However, in an analogous art Suryanarayana teaches Such that when the software patch is applied, the software patch does not overwrite, delete, or disable any portion of the existing patches. (Suryanarayana [0051], "In some embodiments, the information handling system may perform the update at a word level, such as updating only four character hexadecimal words that are different in the firmware update from the current contents of the firmware module. Thus, the firmware update may be applied to individual firmware modules of the information handling system. Updating firmware modules, instead of overwriting an entire firmware volume or image including one or more firmware modules to be updated, may reduce an amount of time required to implement the firmware update. For example, some firmware modules may not require a system reboot for application of a firmware update, but overwriting an entire firmware volume including the firmware modules may require such a reboot. Thus, modular firmware updates may allow an information handling system to update one or more modules of a firmware without overwriting an entire firmware image or an entire firmware volume on a SPI flash firmware memory of the information handling system.")
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Suryanarayana into the teachings of Dahms in view of Shan. This combination of teachings would have resulted in a system to create an incremental or accretive patch, as in Dahms, such that the application of a differential update package will apply the difference between versions to update the application accordingly, as in Shan, only using differential changes without overwriting previous modular updates, as in Suryanarayana. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of only updating the portions of the firmware module that differ from the current firmware image in memory to maintain efficiency by reducing system downtime for a firmware update (Suryanarayana [0010]).
Claim 12 is directed to a system corresponding to the method limitations set forth in claim 11. Thus claim 12 is rejected for the same reasons set forth in claim 11.
Response to Arguments
In the Remarks, Applicant Argues
The claims reflect this specific technological solution to the technological problem faced by information handling systems. The independent claims recite: (i) determining an existing feature set of software and all existing patches present in a system, (ii) creating an accretive software patch that includes only features absent from the existing feature set, (iii) such that when the software patch is applied, the software together with all existing patches, that include the software patch, provides the desired feature set. The dependent claims further implement this architecture in the context of one-time programmable memory or random access memory, specify that the software patch does not overwrite, delete, or disable any portion of the existing patches, and further require that executable code of the software patch updates a jump table stored in random access memory of a target device for the software patch to reference the desired feature set without altering jump table entries associated with the plurality of previously-applied patches. (see, e.g., Claims 2, 3, 5, 6, 8-12). Thus, the claims as a whole are directed to creating accretive software patches such that the amount of storage space used by such patches in OTP memory or other ROM storage is minimized, thereby addressing the technological problem of inefficient memory use in a limited-memory system.
Examiner’s Response:
Applicant recites the following cases: Enfish, LLC v. Microsoft Corp., McRO, Inc. v. Bandai Namco Games Am. Inc., Visual Memory LLC v. NVIDIA Corp., Finjan Inc. v. Blue Coat Systems, Inc., and SRI Int'l, Inc. v. Cisco Systems, Inc. which describe how claims are allowable if they provide an improvement over the functionality of a computer. While the limitations are an improvement over the functionality of a computer, the recited limitations are not indicative of these improvements. In the present case, one could mentally/manually perform (with the aid of pen and paper) the determining and creating steps of claims 1 and 4 with a generic processor to apply the abstract idea in claim 4. The aforementioned steps do not require any manipulation of underlying computer operations/functionalities. Therefore, under its broadest reasonable interpretation, the process of “(i) determining an existing feature set of software and all existing patches present in a system, (ii) creating an accretive software patch that includes only features absent from the existing feature set, (iii) such that when the software patch is applied, the software together with all existing patches, that include the software patch, provides the desired feature set” encompasses a process that can be performed by the human mind through observation, evaluation, judgement, and/or opinion with the aid of pen and paper. Manipulation of underlying computer operations/functionality require “execution” or “application” of the patch in order to reflect any improvement over the existing computer technology.
Therefore, for at least the reasons set forth above, the rejections made under 35 U.S.C. 101 with respect to claims 1-6 and 11-12 are proper and therefore, maintained.
In the Remarks, Applicant Argues:
However, the disclosure that the "sector-specific path takes into account changes to the binary image made by previous patches in the series" does not suggest or imply that deletion of previous patches is avoided. Whereas Claims 1, 4, and 7 recite "existing patches in the system," indicating that patches are retained in the system (e.g., not deleted or overwritten), Dahms provides no indication one way or another that the previous patches were not deleted or overwritten. Rather, as shown in Figures 3A-3D, Dahms merely discloses that a first patch pi is created based on the old binary image and a first sector bi. Dahms at [0035], FIG. 3A. Then, a second patch p2 is generated based on a second sector b2 of the new binary image and a partially patched image 30. Id. at [0036], FIG. 3B. Notably, "[t]he partially patched image 30 is the old binary image 12 with the previously generated patches applied to it, which in this case includes only the first patch p1." Id. Then, a third patch p3 is generated based on a third sector b3 of the new binary image and partially patched image 30. Id. at [0037], FIG. 3C. Again, "the partially patched image 30 is obtained from the application of the first patch pi and the second patch p2," such that the partially patched image contains sectors bi and b2 of the new binary image. Id. However, the change made by the patch is not the same as the patch itself.
In sum, Dahms discloses an incremental patch that, at most, considers the application of (i.e., the changes made by) the previous patch to the partially patched image. Such disclosure in no way teaches, suggests, or discloses, either expressly or inherently, that the patches (i.e., pi, p2,p3,...., pn) remain in the system after their application. Indeed, Dahms suggests the opposite, as the fully patched image will form the basis for the generation of the next incremental patch, along with the new binary image.
Accordingly, the Examiner's interpretation of "an incremental patch" as "the process of differential software updates while avoiding deletion of previous patches" is erroneous. For at least this reason, Dahms fails to disclose "creating a software patch as an accretive patch that includes only features that are absent from the existing feature set in the software and all existing patches in the system, such that when the software patch is applied, the software together with all existing patches, that include the software patch, provides the desired feature set," as recited in Claim 1 and as similarly recited in Claims 4 and 7.
Examiner’s Response:
Examiner respectfully disagrees for the following reasons:
With regards to applicant’s argument that Dahms fails to disclose "creating a software patch as an accretive patch that includes only features that are absent from the existing feature set in the software and all existing patches in the system, such that when the software patch is applied, the software together with all existing patches, that include the software patch, provides the desired feature set," Examiner asserts that Dahms [0039] teaches all existing patches that include the software patch (p1 to Pn). By taking into account previous patches to generate the difference/delta files for incremental application, Dahms describes the process of creating a software patch as an accretive patch that includes only features that are absent from the existing feature set in the software and applying only features that are absent from the existing set such that all patches in combination will provide the desired feature set.
With respect to the applicant’s argument that “patches (i.e., pi, p2,p3,...., pn) remain in the system after their application” the applicant’s argument is not commensurate in scope with the claim language. It is noted that the claims do not require that the existing patches are present in the system regardless of whether they are applied or not. Applicant is reminded that in order for claim limitations to be considered, the claims are required to explicitly recite the limitations. Otherwise, it would be proper to use the broadest reasonable interpretation of the broadly claimed limitations.
Applicant’s arguments with respect to claims 1-12 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TRAVIS VIET TRAN whose telephone number is (571)272-3720. The examiner can normally be reached Monday-Friday 8:30AM-5PM.
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, Wei Mui can be reached at 571-272-3708. 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.
/T.V.T./Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191