DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The instant application having application No. 18/864,256 filed on November 8, 2024, with a preliminary amendment filed the same day, presents claims 1-19 and 21 for examination. The instant application is a national stage entry of the international application having application no. PCT/CN2023/089849, filed on October 2, 2025, and claims priority to the foreign-filed application having application no. CN202210501784.0, filed on May 9, 2022.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: in claim 1, “… an update triggering module and a data receiving module, … a data processing module, … detecting, by the update triggering module, a triggering event … acquiring, by the data receiving module, transmission data … and processing, by the data processing module, received update data according to the update mode information to obtain new firmware data, to apply the new firmware data from a partition storing the new firmware data during running of the bootloader program”
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Objections
Claims 2-16, 19, and 21 are objected to because of the following informalities:
With respect to claims 3-4, “the received patch data” lacks antecedent basis (see line 4 of claim 3, and lines 2-3 and 9-10 of claim 4).
With respect to claims 2-16, each recites “The firmware update method for an embedded device according to claim ...”, which appears to be a typographical error that should recite “The firmware update method for [[an]] the embedded device according to claim …”. Furthermore, claim 3 inherits the deficiency of claim 2, claim 4 inherits the deficiency of claim 2, claims 13-16 inherit the deficiency of claim 12, and claim 16 inherits the deficiency of claim 15.
With respect to claim 16, “preforming” on lines 7 and 9 are typographical errors that should each recite “performing”. Furthermore, “the operation” on line 8 and 10 lack antecedent basis.
With respect to claims 19 and 21, each recites “The firmware update method for an embedded device according to claim …”, which appears to be a typographical error that should recite “The firmware update method for [[an]] the embedded device according to claim …”.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-17 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
With respect to claim 1-17, lines 10-15 of claim 1 recite, with emphasis added, “acquiring, by the data receiving module, transmission data from a source device, the transmission data at least comprising update data … and writing the update data into a partition storing the transmission data; and processing, by the data processing module, received update data …”. This is ambiguous because it is unclear whether the “received update data” is the same as the previously recited “update data” that is acquired by the receiving module. The scope of the claim is therefore indefinite. For purposes of compact prosecution only, Examiner has interpreted claim 1 as reciting “acquiring, by the data receiving module, transmission data from a source device, the transmission data at least comprising update data … and writing the update data into a partition storing the transmission data; and processing, by the data processing module, the update data”. Claims 2-17 inherit deficiency of claim 1.
Furthermore, to the extent that claims 3, 6, and 11 also recite “the received update data”, these claims are indefinite for the same reason as claim 1 (see above). For the same reason set forth above regarding claim 1, Examiner has interpreted claims 3, 6, and 11 as reciting “the for purposes of compact prosecution only. Claim 4 inherits the deficiency of claim 3.
Moreover, to the extent that claims 2, 5, 7, 10, 11, and 12 each also recite “the update data”, these claims are indefinite because it is unclear whether “update data” and “received update data” are the same, as explained above. Claims 3-4 inherit the deficiency of claim 2, claim 4 inherits the deficiency of claim 3, and claims 13-16 inherit the deficiency of claim 12. As indicated above with respect to claim 1, Examiner has interpreted “received update data” in claim 1 as meaning “the update data”, which renders the scope of the claims definite for purposes of compact prosecution only.
With respect to claims 2, 5, 7, 10, 11, and 12, each recites “the update data” which is indefinite because as explained above with respect to parent claim 1, it is unclear whether “update data” and “received update data” are the same, and thus it is unclear what is meant by “the update data” as recited in claims 2, 5, 7, 10, 11, and 12.
Claims 3-4 inherit the deficiency of claim 2, claim 4 inherits the deficiency of claim 3, and claims 13-16 inherit the deficiency of claim 12.
As indicated above with respect to claim 1, Examiner has interpreted “received update data” in claim 1 as meaning “the update data” when renders the scope of claims definite for purposes of compact prosecution only.
With respect to claims 3, 4, 6, and 7, each recites multiple instances of “new firmware data”. It is unclear if these are the same as “new firmware data” and “the new firmware data” recited in parent claim 1. The scope of the claim is therefore indefinite. For purposes of compact prosecution only, Examiner has interpreted each instance “new firmware data” recited in claims 3, 4, 6, 7 as reciting “the new firmware data”. Claim 4 also inherits the deficiency of claim 3.
With respect to claim 4, it is unclear if “differential decoding”, as recited on lines 2 and 9 is the same as “differential decoding” as recited in parent claim 3. The scope of the claim is therefore indefinite. For purposes of compact prosecution only, Examiner has interpreted the claim as reciting “the differential decoding … the differential decoding”.
With respect to claims 3 and 4, lines 4-5 of claim 3 recites “the old firmware data”. There is no previous recitation of “old firmware data” and it is unclear what this might refer to, which renders the scope of the claim indefinite. Claim 4 inherits this deficiency and also recites “the old firmware data” on lines 3, 6, and 10, which is likewise indefinite.
For purposes of compact prosecution only, Examiner has interpreted lines 4-5 of claim 3 as reciting “[[the]] old firmware data”.
With respect to claim 8, it is unclear whether “a triggering event” is the same “triggering event” as recited in parent claim 1. The scope of the claim is therefore indefinite. For purposes of compact prosecution only, Examiner has interpreted claim 8 as reciting “the triggering event”.
With respect to claim 9, lines 1-6 recite, with emphasis added, “wherein after the data receiving module acquiring transmission data from a source device, the method further comprises: determining, by the data receiving module, whether the received transmission data is encapsulated data; if yes, acquiring update mode information from the transmission data”. This is ambiguous because (1) parent claim 1 also recite “transmission data” and “a source device” and it is unclear if these are the same in claim 9, (2) there is no previous recitation of “received transmission data” and it is unclear if this is the same as the previously recited “transmission data”, and (3) it is unclear whether “update mode information”, as recited in claim 9, is the same as “update mode information” recited in parent claim 1. For purposes of compact prosecution only, Examiner has interpreted claim 9 as reciting “wherein after the data receiving module acquiring the transmission data from [[a]] the source device, the method further comprises: determining, by the data receiving module, whether the [[received]] acquired transmission data is encapsulated data; if yes, acquiring the update mode information from the acquired transmission data”.
With respect to claim 3, 4, 6, 13, 14, 15, and 16, claims 3, 6, 13, 14, and 15 each recite “a partition storing the new firmware data” and it is unclear if this is the same “a partition storing the new firmware data”, as recited in parent claim 1. The scope of claims 3, 6, 13, 14, and 15 is therefore indefinite. . For purposes of compact prosecution only, Examiner has interpreted claims 3, 6, 13, 14, and 15 as reciting “[[a]] the partition storing the new firmware data”.
Claim 4 inherits the above deficiency of claim 3 and claim 16 inherits the above deficiency of claim 15.
With respect to claim 17, lines 1-4 recite, with emphasis added, “An embedded device comprising a first memory and a first processor, wherein the first memory is configured to store a computer program, and the first processor is configured to implement the firmware update method for an embedded device according to claim 1”. It is unclear whether “an embedded device” is the same “embedded device” as recited in claim 1. The scope of the claim is therefore indefinite. For purposes of compact prosecution only, Examiner has interpreted claim 17 as reciting “A first embedded device comprising a first memory and a first processor, wherein the first memory is configured to store a computer program, and the first processor is configured to implement the firmware update method according to claim 1”.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 18, 19, and 21 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by McDonald et al. (US 20140173579 A1, hereinafter McDonald).
With respect to claim 18, McDonald discloses A firmware update method for an embedded device, the method being applied to a development end device (e.g., Figs. 1-6 and associated text, e.g., [0012], the utility node device may receive the update package and selectively install one or more of the multiple update items based on a type of the software/firmware that is currently installed on the device; claim 11, under control of a head-end device of a utility node network, the head-end device being configured with specific executable instructions; receiving an update package including a plurality of update items for updating different types of utility node software and/or utility node firmware; see also Abstract.), and comprising:
determining an update mode adopted for firmware update and generating update mode information (e.g., Figs. 1-6 and associated text, e.g., [0025], the package 112 may include an update item (e.g., file image) to upgrade an operating system of a utility node from version 2 to version 3 and another update item to upgrade the operating system from version 3 to version 4; [0026] In some instances, an update item of the update package 112 may comprise a delta file that contains differences between different versions of the software/firmware, such as sequential versions of the software/firmware; [0035] Information identifying an installation path. The installation path may indicate which update items need to be installed and/or in what order; [0066], At 406, the head-end service 106 may repackage the update package 112 to form the repackaged package 118. The package 118 may include one or more update items that are applicable to updating the one or more identified utility nodes, such as one or more update items that are applicable to a version of software/firmware that is already installed on a device and/or that are applicable to hardware of a device. The repackaging may be based on the PDD 114 and/or the information received at 404 related to updating the one or more identified utility nodes (e.g., current version installed on node, device type, hardware, end-version, etc.); Examiner notes that the invention of McDonald, as illustrated in the portions quoted above, disclose two types of updating including a full update or delta update and determining what should be install and then creating the update package, i.e. determining an update mode adopted for firmware update and generating update mode information.);
generating corresponding update data according to the update mode information (Id., particularly, [0066], At 406, the head-end service 106 may repackage the update package 112 to form the repackaged package 118. The package 118 may include one or more update items that are applicable to updating the one or more identified utility nodes, such as one or more update items that are applicable to a version of software/firmware that is already installed on a device and/or that are applicable to hardware of a device. The repackaging may be based on the PDD 114 and/or the information received at 404 related to updating the one or more identified utility nodes (e.g., current version installed on node, device type, hardware, end-version, etc.).); and generating transmission data for firmware update of the embedded device based on the update data and the update mode information (Id., particularly, [0066], At 406, the head-end service 106 may repackage the update package 112 to form the repackaged package 118; [0067], The package 112 and/or 118 may be sent along with the PDD 114 to enable a node to identify contents of the package 112 and/or 118.).
With respect to claim 19, McDonald also discloses wherein generating corresponding update data according to the update mode information comprises: in response to that the update mode information is differential update, the generated update data is patch data (e.g., Figs. 1-6 and associated text, e.g., [0026] In some instances, an update item of the update package 112 may comprise a delta file that contains differences between different versions of the software/firmware, such as sequential versions of the software/firmware … A delta file may be relatively small in size in comparison to a full version of software/firmware. To illustrate, if version 3 of an operating system includes a new module, but is otherwise the same as version 2 of the operating system, the update package 112 may include a delta file that includes only the new module [patch data].); (Examiner notes that since claim 19 is a method, this limitation is not required under the broadest reasonable interpretation of claim because it is a contingent limitation that need not occur. See MPE 2111.04(II) citing Ex parte Schulhauser Appeal 2013-007847 (PTAB April 28, 2016).); (Examiner notes that claim 19 is a method, this limitation is not required under the broadest reasonable interpretation of claim because it is a contingent limitation that need not occur. See MPE 2111.04(II) citing Ex parte Schulhauser Appeal 2013-007847 (PTAB April 28, 2016).).
With respect to claim 21, McDonald also discloses wherein after the generating transmission data for firmware update of the embedded device based on the update data and the update mode information, the method further comprises: sending the transmission data to a source device for storage (e.g., Figs 1-6 and associated text, e.g., [0067] At 408, the head-end service 106 may cause the repackaged package 118 and/or the update package 112 to be sent to the one or more nodes identified at 404. The package 112 and/or 118 may be sent along with the PDD 114 to enable a node to identify contents of the package 112 and/or 118. The package 112 and/or 118 may be sent to the one or more nodes through an edge (e.g., cellular relay, cellular router, edge router, DODAG root, etc.) which serves as a connection point of a utility node network. As illustrated in the example of FIG. 4, the package 118, package 112, and/or PDD 114 may be sent to the node 102A.).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2, 3, 5, 6, 7, 9, 11, 12, 13, 15, 16, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Hou et al. (CN112910714A, hereinafter Hou; see the IDS dated 8/15/25)1 in view of Li et al. (CN113986313A, hereinafter Li; see the IDS dated 8/15/25)2.
With respect to claim 1, Hou discloses A firmware update method for an embedded device, the method being applied to the embedded device, the embedded device comprising a bootloader program and a firmware update acquisition program (e.g., Abstract, The invention discloses a remote firmware upgrading method of an Internet of things terminal device with a master-slave machine structure, which at least comprises a master machine and a plurality of slave machines; the plurality of slave machines are in serial or parallel communication connection with the host machine, each host machine or slave machine at least comprises two program memories and a nonvolatile memory, and the first program memory is used for storing equipment parameters and a bootstrap program);
the bootloader program being stored in a bootloader partition (e.g., p. 8, the BOOT program in the first program memory; p. 10, 7th full para., Correspondingly, in the method, after each host and each slave are restarted, the operation is started from a BOOT program area.), the firmware update acquisition program being stored in a corresponding firmware partition (e.g., p. 8, second-to-last para., the BOOT program is responsible for detecting whether the APP program in the second program memory needs to be updated.), the firmware update acquisition program comprising an update triggering module (e.g., p. 11, 1st full para., When the host runs the APP program, if a firmware upgrading instruction of the server is received, starting firmware upgrading operation.) and a data receiving module (e.g., p. 11, 2nd full para., and after the host analyzes and verifies the firmware upgrading instruction issued by the server, the host starts to execute the firmware downloading operation The host requests to complete the downloading of the firmware for multiple times, each request command comprises the index information of the firmware, and the server returns the firmware content at the designated index to the host.), the bootloader program comprising (e.g., p. 8, second-to-last para., the BOOT program in the first program memory; p. 10, Correspondingly, in the method, after each host and each slave are restarted, the operation is started from a BOOT program area.) a data processing module (e.g., p. 10, 7th full para., Correspondingly, in the method, after each host and each slave are restarted, the operation is started from a BOOT program area; p. 11, 8th para., after the BOOT program completes the firmware verification in the nonvolatile memory and the verification passes, the APP program in the second program memory is firstly erased, and then the firmware data in the nonvolatile memory is sequentially written into the second program memory), and the method comprising:
detecting, by the update triggering module, a triggering event for updating firmware of the embedded device (e.g., p. 11, 1st full para., When the host runs the APP program, if a firmware upgrading instruction of the server is received, starting firmware upgrading operation.);
acquiring, by the data receiving module, transmission data from a source device, the transmission data at least comprising update data for firmware update of the embedded device ; and writing the update data into a partition storing the transmission data (Id.; p. 11, The host stores the downloaded firmware data in a designated position of the nonvolatile memory); and
processing, by the data processing module, received update data firmware data from a partition storing the new firmware data during running of the bootloader program (e.g., p. 10, 7th full para., Correspondingly, in the method, after each host and each slave are restarted, the operation is started from a BOOT program area; p. 11, 8th para., after the BOOT program completes the firmware verification in the nonvolatile memory and the verification passes, the APP program in the second program memory is firstly erased, and then the firmware data in the nonvolatile memory is sequentially written into the second program memory.).
Hou does not appear to disclose the following, which is taught in analogous art, Li: and update mode information identifying an update mode adopted for the firmware this time … according to the update mode information to obtain new firmware data, to apply the new (e.g., p. 4, 4th-9th paras., acquiring upgrading data of software to be upgraded, wherein the upgrading data comprises a first upgrading identifier and an upgrading packet; determining a target upgrading mode corresponding to the upgrading packet according to the first upgrading identification; determining the current local upgrading mode of the software to be upgraded; determining a target storage area of an upgrade package in a firmware partition according to a local upgrade mode, wherein the firmware partition is a storage area of software to be upgraded in terminal equipment; and storing the upgrade package in the target storage area, and upgrading the software to be upgraded by adopting a target upgrading mode based on the upgrade package … the upgrading data acquisition module is used for acquiring upgrading data of the software to be upgraded, and the upgrading data comprises a first upgrading identifier and an upgrading packet; the upgrading mode determining module is used for determining a target upgrading mode corresponding to the upgrading packet according to the first upgrading identification and determining the current local upgrading mode of the software to be upgraded; and the upgrading processing module is used for determining a target storage area of the upgraded package in the
firmware partition according to the local upgrading mode, storing the upgraded package in the target storage area, and upgrading the software to be upgraded by adopting a target upgrading mode based on the upgraded package, wherein the firmware partition is a storage area of the software to be upgraded in the terminal equipment.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Hou with the invention of Li because it would be efficient to only send a differential update when possible.
With respect to claim 2, Li further teaches wherein in response to the update mode information identifying that the update mode adopted for the firmware this time is differential update, the update data is patch data (e.g., p. 9, 3rd para., the targe upgrade mode is a differential upgrade mode, the upgrade package is a differential package, and differential reduction can be performed based on the differential package stored in the target storage area and the old firmware (i.e., the current firmware of the software to be upgraded) stored in the firmware partition, so as to obtain the target firmware of the software to be upgraded, thereby implementing upgrade.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Hou with the invention of Li for the same reason set forth above.
With respect to claim 3, Li further teaches wherein the data processing module processing the received update data to obtain new firmware data comprises: performing differential decoding on the received patch data and the old firmware data to obtain new firmware data (e.g., p. 9, 3rd para., the targe upgrade mode is a differential upgrade mode, the upgrade package is a differential package, and differential reduction can be performed based on the differential package stored in the target storage area and the old firmware (i.e., the current firmware of the software to be upgraded) stored in the firmware partition, so as to obtain the target firmware of the software to be upgraded, thereby implementing upgrade.); after the data processing module processing the received update data to obtain new firmware data, the method further comprises: writing, by the data processing module, the new firmware data into a partition storing the new firmware data, and setting the partition storing the new firmware data as a to-be-booted partition, to apply the new firmware data from the to-be-booted partition during the running of the bootloader program (e.g., p. 8, 2nd full para., When the local upgrade mode is a dual-system upgrade mode, since the firmware partition includes two partitions, in order to determine which partition is upgraded for the upgrade, the second upgrade identifier is further used to identify the upgrade partition targeted by the upgrade, that is, which partition of the firmware partition is to be upgraded. Correspondingly, if the local upgrade mode and the target upgrade mode are both dual-system upgrade modes, after the software to be upgraded is upgraded, the upgrade partition identified by the second upgrade identifier also needs to be updated. For example, the dual system upgrade mode is an AB upgrade mode, the firmware partition includes an a partition and a B partition, the first firmware of the software to be upgraded is stored in the a partition, the second firmware of the software to be upgraded is stored in the B partition, if the upgrade partition of the second upgrade identifier before the upgrade is the a partition, the first firmware of the a partition is upgraded, and after the upgrade is completed, the upgrade partition identified by the second upgrade identifier needs to be updated to the B partition, so as to identify the upgrade to the B partition when the upgrade is performed next time.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Hou with the invention of Li for the same reason set forth above.
With respect to claim 5, Li further teaches wherein in response to the update mode information identifying that the update mode adopted for the firmware this time is compression update, the update data is compressed data (e.g., p. 13, 4th para., If the target upgrading mode is a compression upgrading mode, the upgrading package is a compression package, the upgrading does not depend on old firmware, and after the exchange, the compression package is located at the tail part of the whole firmware area upwards, new firmware can be obtained by direct decompression, and the new firmware can be sequentially burned in the whole firmware area to realize the upgrading; Examiner notes this limitation is not required under the broadest reasonable interpretation of claim because it is a contingent limitation that need not occur. See MPE 2111.04(II) citing Ex parte Schulhauser Appeal 2013-007847 (PTAB April 28, 2016).).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Hou with the invention of Li for the same reason set forth above.
With respect to claim 6, Li further teaches wherein the data processing module processing the received update data to obtain new firmware data comprises: decompressing the compressed data to obtain new firmware data (e.g., p. 13, 4th para., If the target upgrading mode is a compression upgrading mode, the upgrading package is a compression package, the upgrading does not depend on old firmware, and after the exchange, the compression package is located at the tail part of the whole firmware area upwards, new firmware can be obtained by direct decompression, and the new firmware can be sequentially burned in the whole firmware area to realize the upgrading; see also p. 3, top para.); after the data processing module processing the received update data to obtain new firmware data, the method further comprises: writing, by the data processing module, the new firmware data into a partition storing the new firmware data, and setting the partition storing the new firmware data as a to-be-booted partition, to apply the new firmware data from the to-be-booted partition during the running of the bootloader program (Id.; p. 21, 1st full para., the target storage area of the upgrading package in the firmware partition can be determined according to the local upgrading mode, the upgrading package can be stored in the target storage area, and further, the target upgrading mode can be adopted to realize software upgrading. Based on the method, whether the local upgrading mode and the target upgrading mode of the software are the same or not can be realized, and the actual application requirements can be better met; see also p. 82nd full para.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Hou with the invention of Li for the same reason set forth above.
With respect to claim 7, Li further teaches wherein in response to the update mode information identifying that the update mode adopted for the firmware this time is full update, the update data is new firmware data, and the partition storing the transmission data is the partition storing the new firmware data (e.g., p. 10, If the target upgrading mode is a dual-system upgrading mode, such as an AB upgrading mode, since the target upgrading mode is a full-scale upgrading mode, after the target storage area is determined, the upgrade package may be stored in the target storage area from the start position of the target storage area; Examiner notes that this limitation is not required under the broadest reasonable interpretation of claim because it is a contingent limitation that need not occur. See MPE 2111.04(II) citing Ex parte Schulhauser Appeal 2013-007847 (PTAB April 28, 2016).).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Hou with the invention of Li for the same reason set forth above.
With respect to claim 9, Li further teaches wherein after the data receiving module acquiring transmission data from a source device, the method further comprises: determining, by the data receiving module, whether the received transmission data is encapsulated data; if yes, acquiring update mode information from the transmission data to determine the update mode adopted for the firmware this time (e.g., p. 7, 1st -2nd full paras., where a packet header (i.e., a Head) includes information such as a distinguishing identifier (i.e., a first upgrade identifier) and a content check of the upgrade package, and a packet body is an upgrade package corresponding to an upgrade manner identified by the first upgrade identifier [header and body, i.e., encapsulated data] … after determining a target
upgrade mode according to the first upgrade identifier in the packet header by parsing the software upgrade package, store the upgrade package in the target storage area; Examiner notes the limitation “if yes, acquiring update mode information from the transmission data to determine the update mode adopted for the firmware this time” is not required under the broadest reasonable interpretation of claim because it is a contingent limitation that need not occur. See MPE 2111.04(II) citing Ex parte Schulhauser Appeal 2013-007847 (PTAB April 28, 2016).).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Hou with the invention of Li for the same reason set forth above.
With respect to claim 11, Hou also discloses wherein before the data receiving module writing the update data into a partition storing the transmission data, the method further comprises: verifying, by the data receiving module, whether the received update data is complete according to integrity verification parameter information in the transmission data (e.g., claim 2, described firmware integrity check refers to according to the check algorithm of convention, carries out calculation check to all firmware contents except firmware check value, obtains checksum. The verification value is compared with the verification value stored in the specified position of the firmware. If the two are the same, the integrity verification is passed; the firmware ID verification refers to obtaining the firmware ID from the specified position of the firmware and storing it in the first program memory; p. 5, 8th -10th paras., entering the boot program again, verifying the firmware in the second program memory by the boot program, jumping to the second program memory after the verification is passed, and starting to run the firmware program; if the verification is not passed, the firmware in the second program memory is considered to be failed to be upgraded in the last firmware upgrade, so that the firmware is damaged, the boot program verifies the data packet stored in the nonvolatile memory and renews the data packet to the second program memory to update the firmware after the data packet passes the verification … The invention clearly proposes that the obtained firmware needs to be verified before the firmware of the equipment is updated.).
With respect to claim 12, Hou also discloses wherein after the data receiving module writing the update data into a partition storing the transmission data, the method further comprises: setting, by the data receiving module, the partition storing the transmission data as a to-be-booted partition, to enable the data processing module to acquire the transmission data from the partition storing the transmission data (e.g., after the host is restarted, the BOOT program is first entered, and the APP program update flag is detected to be
1, after the BOOT program sets the flag to 0, the BOOT program starts to check the firmware content in the nonvolatile memory, and the checking at least includes: checking the integrity of the firmware and checking the ID of the firmware; further, after the BOOT program completes the firmware verification in the nonvolatile memory and the verification passes, the APP program in the second program memory is firstly erased, and then the firmware data in the nonvolatile memory is sequentially written into the second program memory. After the writing is finished, the host is automatically restarted … after the firmware of the APP program area is verified by the BOOT program area and passes, the BOOT program area jumps to a second program memory.).
With respect to claim 13, Hou also discloses wherein before the data processing module applying the new firmware data from a partition storing the new firmware data during the running of the bootloader program, the method further comprises: acquiring, by the data processing module, file header information from the transmission data, and verifying the file header information (e.g., p. 6, 5th para., the host sends the firmware upgrading data packet downloaded from the server to the target slave in a subpackaging manner; each packet data at least comprises a target device ID, a firmware upgrading command, a total length of a firmware packet, a firmware packet subpackaging index sent this time, firmware packet subpackaging data sent this time and verification of the data packet.).
With respect to claim 15, Hou also discloses wherein after the data processing module applying the new firmware data from a partition storing the new firmware data during the running of the bootloader program, the method further comprises: acquiring, by the data processing module integrity verification parameter information from the transmission data, and verifying whether the data written into the partition storing the new firmware data is complete (e.g., claim 2, described firmware integrity check refers to according to the check algorithm of convention, carries out calculation check to all firmware contents except firmware check value, obtains checksum. The verification value is compared with the verification value stored in the specified position of the firmware. If the two are the same, the integrity verification is passed; the firmware ID verification refers to obtaining the firmware ID from the specified position of the firmware and storing it in the first program memory; p. 5, 8th -10th paras., entering the boot program again, verifying the firmware in the second program memory by the boot program, jumping to the second program memory after the verification is passed, and starting to run the firmware program; if the verification is not passed, the firmware in the second program memory is considered to be failed to be upgraded in the last firmware upgrade, so that the firmware is damaged, the boot program verifies the data packet stored in the nonvolatile memory and renews the data packet to the second program memory to update the firmware after the data packet passes the verification … The invention clearly proposes that the obtained firmware needs to be verified before the firmware of the equipment is updated.).
With respect to claim 16, Hou discloses acquiring integrity verification parameters from the transmission data and verifying whether the data written into the partition storing the new firmware data is complete, the method further comprises: in response to that the integrity verification passes, preforming, by the data processing module, the operation of setting the partition storing the new firmware data as a to-be-booted partition; in response to that the integrity verification fails, not preforming, by the data processing module, the operation of setting the partition storing the new firmware data as a to-be-booted partition (e.g., claim 2, described firmware integrity check refers to according to the check algorithm of convention, carries out calculation check to all firmware contents except firmware check value, obtains checksum. The verification value is compared with the verification value stored in the specified position of the firmware. If the two are the same, the integrity verification is passed; the firmware ID verification refers to obtaining the firmware ID from the specified position of the firmware and storing it in the first program memory; p. 5, 8th -10th paras., entering the boot program again, verifying the firmware in the second program memory by the boot program, jumping to the second program memory after the verification is passed, and starting to run the firmware program; if the verification is not passed, the firmware in the second program memory is considered to be failed to be upgraded in the last firmware upgrade, so that the firmware is damaged, the boot program verifies the data packet stored in the nonvolatile memory and renews the data packet to the second program memory to update the firmware after the data packet passes the verification … The invention clearly proposes that the obtained firmware needs to be verified before the firmware of the equipment is updated.) and Li further teaches wherein in response to the update mode information identifying that the update mode adopted for the firmware this time is differential update or compression update, after the data processing module (e.g., p. 7, 2nd-3rd paras., where a packet header (i.e., a Head) includes information such as a distinguishing identifier (i.e., a first upgrade identifier) and a content check of the upgrade package, and a packet body is an upgrade package corresponding to an upgrade manner identified by the first upgrade identifier, such as a differential upgrade differential package (diffackage) … When software to be upgraded (namely old firmware of the software) needs to be upgraded, the embedded device can acquire the software upgrade package from the server through communication with the server.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Hou with the invention of Li for the same reason set forth above.
With respect to claim 17, Hou discloses An embedded device comprising a first memory and a first processor, wherein the first memory is configured to store a computer program, and the first processor is configured to implement the firmware update method for an embedded device (e.g., Abstract, The invention discloses a remote firmware upgrading method of an Internet of things terminal device with a master-slave machine structure, which at least comprises a master machine and a plurality of slave machines) and Hou in view of Li discloses according to claim 1 when executing the computer program (see the rejection of claim 1 above).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Hou with the invention of Li for the same reason set forth above with respect to claim 1.
Claims 4 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Hou in view of Li, as applied to claim 3 and 1 above, and further in view of Zhang et al. (US 20200371777 A1, hereinafter Zhang).
With respect to claim 4, Hou does not appear to disclose the following, which is taught in analogous art, Zhang: wherein before the data processing module performing differential decoding on the received patch data and the old firmware data to obtain new firmware data, the method further comprises: acquiring, by the data processing module, version verification information or digest verification information of the old firmware data from the transmission data, and determining whether the patch data matches the old firmware data according to the version verification information or digest verification information (e.g., Figs. 2-11, particularly, Fig. 6, and associated text, e.g., Abstract, A firmware update method including receiving a first message from an update server, where the first message includes first data and a signature of the first data, verifying the first message, and obtaining digest data included in the first data after the first message is successfully verified. The digest data includes digest information of a differential installation package between a first installation package and a second installation package and at least one of, digest information of the first installation package, or digest information of the second installation package. A second message is received from the update server and includes the differential installation package. The digest data is verified, and firmware of an embedded universal integrated circuit card (eUICC) is updated based on the differential installation package after the digest data is successfully verified; see also [0119]-[0161] and [0209].); and if yes, performing the operation of performing differential decoding on the received patch data and the old firmware data to obtain new firmware data (Id.; Examiner notes that claim 19 is a method, this limitation is not required under the broadest reasonable interpretation of claim because it is a contingent limitation that need not occur. See MPE 2111.04(II) citing Ex parte Schulhauser Appeal 2013-007847 (PTAB April 28, 2016).).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Hou with the invention of Zhang because it can help “ensure security” of a firmware update, as suggested by Zhang (see [0005]).
With respect to claim 10, Hou does not appear to disclose the following, which is taught in analogous art, Zhang: wherein before the data receiving module writing the update data into a partition storing the transmission data, the method further comprises: determining, by the data receiving module, whether the update data has been encrypted; if yes, decrypting the update data according to encryption type information in the transmission data (e.g., e.g., Figs. 2-11 and associated text, e.g., [0108], the differential installation package between the first installation package and the second installation package that is stored by the update server is a differential installation package sent by the EUM to the update server after the EUM performs encryption by using the private key of the EUM. Therefore, the first differential installation package obtained by the user equipment is the encrypted differential installation package. After obtaining the first differential installation package, the user equipment decrypts the first differential installation package by using the prestored public key of the EUM, to obtain the decrypted differential installation package.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Hou with the invention of Zhang because it can help “ensure security” of a firmware update, as suggested by Zhang (see [0005]).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Hou in view of Li, as applied to claim 1 above, and further in view of Bandakka et al. (US 20130125107 A1, hereinafter Bandakka).
With respect to claim 8, Hou also discloses wherein the update triggering module detecting a triggering event for updating firmware of the embedded device comprises: the update triggering module receives a push message sent by the source device indicating that there is an updated version of the firmware (e.g., pp. 8-9, After the equipment initialization is completed, the firmware version information of the local machine is actively reported to an internet server, and then at least two subtask modules are established: the system comprises a wireless communication task module and a serial communication task module. The wireless communication module is responsible for receiving the issued command [push message] of the internet server and the events of the host and the slave. The serial communication task module is responsible for periodically polling the slave machines, transmitting the issuing instructions of the internet server and acquiring the response data of the slave machines.); and the update triggering module Id.; p. 11, 1st full para., When the host runs the APP program, if a firmware upgrading instruction of the server is received, starting firmware upgrading operation.).
Hou does not appear to disclose the following, which is taught in analogous art, Bandakka: sends a query request to the source device as to whether there is an updated version of the firmware, and receives a reply message from the source device indicating that there is an updated version (e.g., Fig. 6 and associated text, e.g. [0107] the firmware update application generates and sends a check-in request [query] to the remote management server in operation 605 … In response to receiving the check-in request, the remote management server checks whether any firmware updates are available or scheduled for the identified client device in operation 607; [0109], if one or more updates are determined to be available or scheduled, the remote management server proceeds with operations 609b1-609b4 … if the package verification is a success (i.e., the package verification indicates that all identified packages are stored by the repository server and have the identified package sizes), the remote management server sends a check-in response [reply] including the firmware update configuration file to the firmware update module of the client device in operation 609b4.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Hou with the invention of Bandakka because “a need therefore exists for methods and systems to enable network administrators to efficiently and reliably update firmware on large numbers of thin client devices”, as suggested by Bandakka.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Hou in view of Li, as applied to claim 12 above, and further in view of Lindh “Delta Updates for Embedded Systems: An Implementation of Firmware Patching for Zephyr RTOS” (hereinafter Lindh).
With respect to claim 14, Hou does not appear to disclose the following, which is taught in analogous art, Lindh: wherein before the data processing module applying the new firmware data from a partition storing the new firmware data during the running of the bootloader program, the method further comprises (e.g., p. 2, § 1.2.1, 3rd para., A boot loader is a piece of software used for starting the operating system, or main application, of a unit[4]. It also enables device firmware upgrades, which makes it a focal point of this thesis. Zephyr uses a boot loader called MCUboot … The device tree labels for these partitions are: boot_partition, the partition containing the the MCUboot image; slot0_partition, the primary partition, containing the Zephyr image; slot1_partition, the secondary partition, which stores firmware upgrade images and therefore must be the same size as slot0_partition; and lastly, the scratch partition, which is used as temporary storage while swapping the contents of slot0_partition and slot1_partition): acquiring, by the data processing module, signature information of update data from the transmission data, and verifying the signature information (p. 1, 1st para., firmware upgrades are preferably transferred using Firmware Over-the-air, FOTA; p. 3, 2nd full para., Before booting the new firmware, the MCUBoot performs an integrity check by reading some data placed at the end of the image - the image trailer. The trailer contains a cryptographic hash signature used for authentication and metadata about the image used for ensuring compatibility. MCUboot supports several options for signing an image, but in this work we will use a set of RSA keys).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Hou with the technique of Lindh because it would improve security by helping to ensure that the update is authentic.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Specifically, De Atley US 20190227784 A1 discloses a system with multiple levels of verification are implemented to enable components of a software update and asset delivery system to verify other components within the system.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEPHEN DAVID BERMAN whose telephone number is (571) 272-7206. The examiner can normally be reached M-F, 9-6 Eastern.
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, Hyung S. Sough can be reached on 571-272-6799. 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.
/STEPHEN D BERMAN/ Examiner, Art Unit 2192
1 The rejection is based on the attached Google Patents English language translation of CN112910714A.
2 The rejection is based on the attached Google Patents English language translation CN113986313A.
