DETAILED ACTION
The Office Action is in response to Amendments filed 05/08/2026.
Claims 10-12 are currently cancelled.
Claims 1, 4, and 7 are currently amended.
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 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; applying the software patch to the system such that the software together with all existing patches, that include the software patch, provides the desired feature set, wherein applying the software patch does not overwrite, delete, or disable any portion of the existing patches." 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” 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 claim is 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.
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 Al hereinafter "Shan" and further in view of US 20230112734 A1 hereinafter “Suryanarayana”.
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 but 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]).
The combination of Dahms and Shan teaches applying the software patch to the system such that the software together with all existing patches, that include the software patch, provides the desired feature set but does not teach: wherein applying the software patch does not overwrite, delete, or disable any portion of the existing patches.
However, in an analogous art Suryanarayana teaches […], wherein 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 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 pl to Pn: In some cases, the individual sector-based patches pl 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]).
The combination of Dahms and Shan teaches does not teach: wherein applying the software patch does not overwrite, delete, or disable any portion of the existing patches.
However, in an analogous art Suryanarayana teaches wherein 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.") [Examiner’s Note: By updating a firmware volume and not the firmware itself Suryanarayana teaches a system that can add firmware modules to new firmware volume spaces without overwriting previously written firmware areas.]
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 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.")
Allowable Subject Matter
Claims 3, 6, and are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Response to Arguments
In the Remarks: Applicant Argues:
The Examiner has already withdrawn the § 101 rejection as to Claims 7-10, acknowledging that claims reciting the application of an accretive patch to a computing system reflect patent- eligible subject matter. (See Office Action at Page 2). Notably, the Examiner provides that "[m]anipulation of underlying computer operations/functionality require 'execution' or 'application' of the patch in order to reflect any improvement over the existing computer technology." (Id. at Page 25). Without acceding to the propriety of the rejections under 35 U.S.C. § 101, Applicant has amended Claims 1 and 4 to recite application of the claimed software patch to the system. Applicant respectfully submits that such application demonstrates a practical application of the claimed software patch and does not constitute extra-solution activity. As made clear by the Specification, the technical problem addressed by the claims is the patching of a device's software where the device has limited storage space (e.g., OTP memory).
Examiner’s Response:
With respect to the applicant’s argument the examiner has “withdrawn the § 101 rejection as to Claims 7-10, acknowledging that claims reciting the application of an accretive patch to a computing system reflect patent- eligible subject matter,” Examiner asserts that claims 7-10 does not claim any process that can be practically performed by the human mind and thus does not provide any abstract subject matter. Under its broadest reasonable interpretation, an application of a software patch is a process that can be practically performed in the human mind through observation, evaluation, judgement, and/or opinion with the aid of pen and paper. Thus, the limitation still falls under the “Mental Processes” grouping of abstract ideas. Therefore, for the reasons set forth above, the rejections made under 35 U.S.C. 101 with respect to claims 1-6 are proper and therefore maintained.
In the Remarks: Applicant Argues:
In contrast, claims 1, 4, and 7 recite "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." Thus, the claim language presupposes prior patches exist as independent entities in the system and remain present alongside the base software. However, the Examiner equates "sector-based patches p1 to Pn" (also referred to as "delta files," "difference files," and "sector-based patches pi to pin" (see Dahms at [0041]-[0042])) to both the claimed "all existing patches present in a system" and the claimed "software patch"/ "accretive patch." (See Office Action at Pages 7-8). Indeed, Dahms makes explicitly clear that "the full incremental patch" is the "full set of sector-based patches pi-pn." Dahms at [0042]. But the claim language of Claims 1, 4, and 7 distinguishes between the claimed "all existing patches in the system" and the claimed "software patch." Relying on the "sector-based patches pi to pn" of Dahms as both the "all existing patches in the system" and "a software patch"/ "accretive patch" violates foundational rules of claim construction. See Becton, Dickinson & Co. v. Tyco Healthcare Grp., LP, 616 F.3d 1249, 1254 (Fed. Cir. 2010) ("Where a claim lists elements separately, 'the clear implication of the claim language' is that those elements are 'distinct component[s]' of the patented invention."); Ex parte Weideman, No. 2008-003454 (BPAI Jan. 27, 2009) ("[I]t is improper to rely on the same structure ... as being responsive to two different elements."); Ex parte Koutsky, No. 2008-0557 (BPAI Sep. 23, 2008) ("When a claim requires two separate elements, one element construed as having two separate functions will not suffice to meet the terms of the claim.").
Examiner’s Response:
With respect to the applicant’s argument that “Thus, the claim language presupposes prior patches exist as independent entities in the system and remain present alongside the base software. However, the Examiner equates "sector-based patches p1 to Pn" (also referred to as "delta files," "difference files," and "sector-based patches pi to pn" (see Dahms at [0041]-[0042])) to both the claimed "all existing patches present in a system" and the claimed "software patch"/ "accretive patch." (See Office Action at Pages 7-8). Indeed, Dahms makes explicitly clear that "the full incremental patch" is the "full set of sector-based patches pi-pn." Dahms at [0042]. But the claim language of Claims 1, 4, and 7 distinguishes between the claimed "all existing patches in the system" and the claimed "software patch." Relying on the "sector-based patches pi to pn" of Dahms as both the "all existing patches in the system" and "a software patch"/ "accretive patch" violates foundational rules of claim construction.” Examiner respectfully disagrees. Dahms is used to teach a binary difference algorithm that takes into account changes between the new and old binary image to generate the delta/difference file. The old binary image is the accumulation of changes between patches pi-pn. Shan describes the application of a difference file to generate a full feature set and Suryanarayana teaches an application of a software patch that does not overwrite any previous patches. Therefore, it would have been obvious to one of ordinary skill in the art to have combine these references for the purpose of teaching upon accretive patching. Therefore, for the reasons set forth above, the rejections made under 35 U.S.C. 103 with respect to claims 1-2, 4-5, and 7-8 are proper and therefore maintained.
In the Remarks: Applicant Argues:
Indeed, it is unclear how the system of Dahms and the system of Shan would be combined to allegedly disclose the features of Claims 1, 4, and 7. The Examiner provides no explanation of how the alleged software patch (the full incremental patch comprising sector-based patches pi-pn), "all existing patches" (sector-based patches pi-pn), and "the software" are applied to provide the desired feature set based on the teachings of Shan. Is the Examiner simply contending that any reference that describes updating a version of software is sufficient to disclose the above-recited claim feature? It appears so, especially given that the purported motivation to combine lacks an articulated reasoning as to why a person of ordinary skill in the art would combine Dahms's sector- by-sector binary image replacement with Shan's OS version-change-data-preservation technique. At most, the Examiner contends that a POSITA would be motivated to combine these teachings "for the purpose of updating the application version while keeping the storage location unchanged." (Office Action at Page 9). Such reasoning is untethered from the subject matter of the claims and the subject matter of Dahms. Put simply, the Examiner's reasoning is problematic at least because the Examiner's purported motivation to combine is no more than a general statement of the advantages of Shan with respect to the problem that Shan solves. Such reasoning is circular in nature: it suggests that the mere fact that a functionality is useful can be the sole motivation for combining such functionality with functionality of another reference. If that were the standard for obviousness, not a single invention would ever be non-obvious.
Examiner’s Response:
With respect to the applicant’s argument “Such reasoning is untethered from the subject matter of the claims and the subject matter of Dahms. Put simply, the Examiner's reasoning is problematic at least because the Examiner's purported motivation to combine is no more than a general statement of the advantages of Shan with respect to the problem that Shan solves. Such reasoning is circular in nature” Examiner respectfully disagrees. Dahms teaches finding a binary difference that allows for a differential update and thus the reasoning is not untethered from the subject matter of Dahms nor the subject matter of the claims. Shan further teaches the usage of difference/incremental update information to upgrade the firmware between versions, wherein a most recent version includes the desired features. Furthermore, Examiner has provided a clear articulation of the reasons why the claimed invention would have been obvious. When a rejection depends on a combination of prior art references, there must be some teaching, suggestion, or motivation to combine the references. See In re Geiger, 815 F.2d 686, 688, 2 USPQ2d 1276, 1278 (Fed. Cir. 1987). Therefore, the Examiner’s rejections of the claims on obviousness grounds are not based on mere conclusory statements because the teaching-suggestion-motivation (TSM) test asks not merely what the references disclose, but whether a person of ordinary skill in the art, possessed with the understandings and knowledge reflected in the prior art, and motivated by the general problem facing the inventor, would have been led to make the combination recited in the claims. See Cross Med. Prods., 424 F.3d at 1321-24. From this it may be determined whether the overall disclosures, teachings, and suggestions of the prior art, and the level of skill in the art—i.e., the understandings and knowledge of persons having ordinary skill in the art at the time of the invention—support the legal conclusion of obviousness. See Princeton Biochemicals, 411 F.3d at 1338 (pointing to evidence supplying detailed analysis of the prior art and the reasons one of ordinary skill would have possessed the knowledge and motivation to combine). Therefore, for the reasons set forth above, the rejections made under 35 U.S.C. 103 with respect to claims 1-2, 4-5, and 7-8 are proper and therefore maintained.
In the Remarks: Applicant Argues:
Suryanarayana teaches overwriting individual words within a firmware module. This is fundamentally different from the claimed feature that "applying the software patch does not overwrite, delete, or disable any portion of the existing patches." In Suryanarayana, existing firmware module content is overwritten -just more surgically. In the claimed invention, existing patches remain wholly intact; the accretive patch adds new functionality on top of them without altering or destroying any portion of the prior patches. Thus, Suryanarayana does not teach "wherein applying the software patch does not overwrite, delete, or disable any portion of the existing patches."
Examiner’s Response:
With respect to the applicant’s argument that Suryanarayana does not teach "wherein applying the software patch does not overwrite, delete, or disable any portion of the existing patches." Examiner respectfully disagrees. Suryanarayana describes a 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”. Suryanarayana discloses at [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." For one of ordinary skill in the art, when a new firmware is added, it inherently does not disable/delete/overwrite existing portion.. Therefore, for the reasons set forth above, the rejections made under 35 U.S.C. 103 with respect to claims 1-2, 4-5, and 7-8 are proper and therefore maintained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kreek (US 20100223602 Al) teaches methodologies to build Read Only Memory software images using existing patch references.
McCurdy (US 20110113070 A1) teaches methods, apparatuses, systems, and software for providing a potentially more effective way to distribute software, and updates thereto, to a plurality of SSFTDs. This may be done in a variety of ways depending upon the significance of the update. For instance, a reference, or master, software stack may be built at a reference machine and imaged, and then the imaged stack is sent to the SSFTDs. The SSFTDs then use the local image to generate a stack on their own local hard drives or other computer-readable media. Where updates are minor (e.g., involving a small number of software components in the stack), then only the updated installation components might be sent. Where the updates are larger, a delta patch file may be sent that may be utilized by the SSFTD in conjunction with the previous version of the locally-stored stack image to produce the updated stack.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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
Prosecution Insights