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 .
This office action is in response to the amendment filed June 30, 2025.
The current application is a §371 application claiming the benefit of PCT/CN2021/106161 filed July 14, 2021, which claims benefit under §119 to Chinese Application No. 202010951997.7 filed September 11, 2020. The claims herein are examined as entitled to the earlier effective filing date.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Response to Arguments
Applicant's arguments filed June 30, 2025 have been fully considered but they are not persuasive. Specifically regarding applicant’s remarks related to the §103 rejection, the Examiner respectfully disagrees. In response to applicant's arguments against the references individually, one cannot show non-obviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Here, Applicants arguments on pages 8-12 argue the teachings of Lu and Rajagopalan separately without considering the teaching of the combination of references. Specifically, while applicant argues Lu does not teach the amended parsing limitations, the combination of Rajagopalan and Lu teach or suggest the limitations of the claims as presently amended. Specifically regarding the amended limitations related to file name correspondence, storage and map ping Rajagopalan teaches storage and comparison of a version number represented by e.g. an 80 byte segment or sub segments as descrbied in Rajagopalan as cited below, the version number storage, correspondence and comparison teaches or suggests the claimed file name correspondence and comparsion. As such the argument is unpersuasive and the rejection is maintained.
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.
Claim(s) 1-6, and 8-15 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Lu” (US PG Pub 2017/0115984) in view of “Rajagopalan” (US PG Pub 2014/0344797).
Regarding Claim 1, Lu teaches:
1. A method for updating firmware, applied to a first device comprising an application processor (AP) and a security processor (SP), the method comprising:
by the AP, obtaining an AP firmware update file and a SP firmware update file set by the AP, the AP firmware update file and the SP firmware update file set models of the SP matching with the AP…(See Figs. 4-7 and associated text,of Lu, including an application processor and security processor, including an embodiment where firmware updates for both the AP and SP are process in ¶168, 408-410 Fig. 4, and ¶169 describing requesting and receiving firmware update from the server to the AP including embodiment updating both AP and SP firmware, including SP model corresponding to the AP)
by the AP, updating a system firmware of the AP according to the AP firmware update file (See Figs. 4-7 and associated text, e.g. 604, Fig. 7 ¶220 teaches the AP storing the firmware update in the application firmware storage area to install the updated firmware)
and sending a target firmware update file… to the SP; (See e.g. Figs. 4-7, 411, Fig. 4 and further 417, ¶180 teaches the AP sending the firmware update file to the SP)
by the SP, updating a system firmware of the SP according to the target firmware update file.(See e.g. Figs. 4-6, 501-503, SP stores new security firmware in the security firmware storage area)
wherein said by the AP, sending the target firmware update file parsed from the SP firmware update file set to the SP comprises: sending, by the AP, a model acquisition request to the SP; (See Lu 401 F. 4 ¶157 AP requesting verion reading instruction to SP)
sending, by the SP, a model of the SP to the AP, after receiving the model acquisition request from the AP; (See Lu 403 F. 4 ¶¶158-160 SP sending firmware version information to AP in response)
and sending, by the AP, the target firmware update file to the SP; (Lu See e.g. Figs. 4-7, 411, Fig. 4 and further 417, ¶180 teaches the AP sending the firmware update file to the SP)
Lu does not explicitly teach, but Rajagopalan teaches:
…from a firmware releasing platform, wherein …are obtained by parsing a same system firmware update file that has been released by the firmware releasing platform, the [AP] firmware update file and the [SP] firmware update file set are combined into the system firmware update file by the firmware releasing platform, (Rajagopalan 310-330, fig. 3, ¶¶36-42 teaches receiving a firmware file from a distribution point (e.g. manufacturer as in ¶32) parsing the file to identify distinct firmware updates and match the header configuration identifiers with the target to be updated). [Here, while Rajagopalan does not explicitly teach the combination of AP and SP firmware updates, it’s multiple combine firmware update files of different versions would be obvious to combine with the AP/SP updates of Lu for at least the reasons set forth below]
parsed from the SP firmware update file set (Rajagopalan 310-330, fig. 3, ¶¶36-42 teaches receiving a firmware file from a distribution point (e.g. manufacturer as in ¶32) parsing the file to identify distinct firmware updates and match the header configuration identifiers with the target to be updated).
the target firmware update file supports the all different models of the SP; (Rajagopalan 310-330, fig. 3, ¶¶36-42 teaches receiving a firmware file from a distribution point (e.g. manufacturer as in ¶32) parsing the file to identify distinct firmware updates and match the header configuration identifiers with the target to be updated). [Here, while Rajagopalan does not explicitly state that the update file includes “all” versions, it discloses including a plurality of versions in the UBFs of the file package such that all of a finite set of versions of a firmware could be included in the multiple-version packaged disclosed in Rajagopalan]
parsing out, by the AP, the target firmware update file supporting the model of the SP from the SP firmware update file set after receiving the model of the SP; (Rajagopalan Fig. 6, 610-640, ¶¶43-45 describes parsing the firmware file to match configurations of the device to be updated with firmware versions identified in the headers)
wherein said parsing out, by the AP, the target firmware update file supporting the model of the SP from the SP firmware update file set comprises: obtaining, by the AP, a file name label corresponding to the model of the SP from a pre-stored correspondence relationship between SP models and file name labels, and taking the obtained file name label as a first label, wherein the file name label corresponding to the model of the SP in this correspondence relationship indicates the file name of the firmware update file of the system firmware for updating the SP corresponding to the model of the SP, the file name label is the same as the file name of the firmware update file or be a part of character strings of the file name of the firmware update file; (610, Fig. 6, ¶43 describes retrieving the firmware version and memory capacity of the device to be updated, i.e. retrieving identifiers of the configuration to be updated, and further ¶43 describes storing this file version number in firmware etc and further in ¶¶45-46 teaches determining match between this version number and the version number of the header, where version numbers and targets are identifies in e.g. 80 byte strings of the header as in ¶38) [Here was Rajagopalan teaches storage and comparison of a version number represented by e.g. an 80 byte segment or sub segments, the version number storage, correspondence and comparison teaches or suggests the claimed file name correspondence and comparison]
parsing out, by the AP, a file name containing the first label and a file location corresponding to the file name from a source file directory area of the SP firmware update file set; (Rajagopalan 620, Fig. 6, see also Figs. 4-5, ¶¶44, and further ¶¶37-40 describing the structure of the firmware file package structure including a header for each update file which identifies the configuration for the target (502/503) and the length, 501 (i.e. the file location) for that particular update in the update file). and parsing out, by the AP, a firmware update file from a source file data area of the SP firmware update file set according to the file location corresponding to the file name and taking the parsed firm update file as the target firmware update file. (Rajagopalan 620, Fig. 6, see also Figs. 4-5, ¶¶44, and further ¶¶37-40 describing the structure of the firmware file package structure including a header for each update file which identifies the configuration for the target (502/503) and the length, 501 (i.e. the file location) for that particular update in the update file. Once the update is correctly matched, in 640-650 the ubf is retrieved from the update package and applied to the target device). In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the application to combine the teachings of Lu and Rajagopalan as each is directed to firmware update methods and Rajagopalan recognized “improved techniques for upgrading firmware residing on multiple non-volatile memory devices having diverse configurations are desirable.” (¶7).
Claim 8 is rejected on the same basis as claim 1 above.
Regarding Claim 2, Rajagopalan further teaches:
2. The method according to claim 1, wherein said by the AP, obtaining the AP firmware update file and the SP firmware update file set from the firmware releasing platform comprises: receiving, by the AP, the AP firmware update file and the SP firmware update file set sent by a second device,
wherein after the second device obtains the system firmware update file from a firmware releasing platform, the AP firmware update file and the SP firmware update file set are obtained by the second device by parsing the system firmware update file; or receiving, by the AP, the system firmware update file sent by the second device, and parsing the system firmware update file to obtain the AP firmware update file and the SP firmware update file set; the system firmware update file is obtained by the second device from a firmware releasing platform. (Rajagopalan Fig. 2, 250, ¶¶32-35 teaches a Host 250 which relays the firmware update to controller 110, wherein the update file is parsed in process 120, Fig. 1, see e.g. ¶28). In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the application to combine the teachings of Lu and Rajagopalan as each is directed to firmware update methods and Rajagopalan recognized “improved techniques for upgrading firmware residing on multiple non-volatile memory devices having diverse configurations are desirable.” (¶7).
Regarding Claim 5, Rajagopalan further teaches:
5. The method according to claim 3, wherein said parsing out, by the AP, the target firmware updateftakAP, a file header label corresponding to the model of the SP from a stored correspondence relationship between SP models and file header labels, and taking the file obtained header label as a second label; (610, Fig. 6, ¶43 describes retrieving the firmware version and memory capacity of the device to be updated, i.e. retrieving identifiers of the configuration to be updated)
parsing out, by the AP, a firmware update file which has a file header containing the second label from a source file data area of the SP firmware update file set and taking the firmware update file as the target firmware update file. (Rajagopalan 620, Fig. 6, see also Figs. 4-5, ¶¶44, and further ¶¶37-40 describing the structure of the firmware file package structure including a header for each update file which identifies the configuration for the target (502/503) and the length, 501 (i.e. the file location) for that particular update in the update file. Once the update is correctly matched, in 640-650 the ubf is retrieved from the update package and applied to the target device). In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the application to combine the teachings of Lu and Rajagopalan as each is directed to firmware update methods and Rajagopalan recognized “improved techniques for upgrading firmware residing on multiple non-volatile memory devices having diverse configurations are desirable.” (¶7).
Regarding Claim 6, Rajagopalan further teaches:
6. The method according to claim 3, wherein said parsing out, by the AP, the target firmware update file supporting the model of the SP from the SP firmware update file set comprises: obtaining, by the AP, a file location corresponding to the model of the SP from a stored correspondence relationship between SP models and file locations;
(610, Fig. 6, ¶43 describes retrieving the firmware version and memory capacity of the device to be updated, i.e. retrieving identifiers of the configuration to be updated)
parsing out, by the AP, a firmware update file from a source file data area of the SP firmware update file set according to the obtained file location orresponding to the model of the SP and taking the firmware update file as the target firmware update file. (Rajagopalan 620, Fig. 6, see also Figs. 4-5, ¶¶44, and further ¶¶37-40 describing the structure of the firmware file package structure including a header for each update file which identifies the configuration for the target (502/503) and the length, 501 (i.e. the file location) for that particular update in the update file. Once the update is correctly matched, in 640-650 the ubf is retrieved from the update package and applied to the target device). In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the application to combine the teachings of Lu and Rajagopalan as each is directed to firmware update methods and Rajagopalan recognized “improved techniques for upgrading firmware residing on multiple non-volatile memory devices having diverse configurations are desirable.” (¶7).
Regarding Claim 9, Rajagopalan further teaches:
9. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable by the processor, wherein, the processor is configured to, when executing the computer program, implement the method according to any one of claims 1. (See e.g. Rajagopalan ¶13 describing an apparatus including a memory array, and controller (processor) for executing a firmware file parsing and application system) In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the application to combine the teachings of Lu and Rajagopalan as each is directed to firmware update methods and Rajagopalan recognized “improved techniques for upgrading firmware residing on multiple non-volatile memory devices having diverse configurations are desirable.” (¶7).
Regarding Claim 10, Rajagopalan further teaches:
A non-transitory computer-readable storage medium, which stores a computer program, when the computer program. that, when executed by a processor of a terminal device, causes the processor of the terminal device to implement the method according to claim 1. (See e.g. Rajagopalan ¶14 describing a non-transitory computer readable medium for executing a firmware file parsing and application system) In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the application to combine the teachings of Lu and Rajagopalan as each is directed to firmware update methods and Rajagopalan recognized “improved techniques for upgrading firmware residing on multiple non-volatile memory devices having diverse configurations are desirable.” (¶7).
Claim 11-15 are rejected on the same basis as claims 2-6 respectively above.
Claim(s) 7, and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Lu” (US PG Pub 2017/0115984) in view of “Rajagopalan” (US PG Pub 2014/0344797) as applied to Claims 1-6 above and further in view “Maibach” (US Patent 10,452,383)
Regarding Claim 7, Lu et al teach the limitations of claim 1 above, but do not further teach, but Maibach teaches:
7. The method according to any one of claims 1, wherein the first device is a payment terminal. (See payment system Fig. 1, 102, 106, and Fig. 2 system, as described in Col. 2, Ln 24 to Col. 3 Ln 47 describes various payment terminal systems, to which firmware updates may be applied).
In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the application to combine the teachings of Lu and Maibach as each is directed to firmware update techniques and Maibach recognized the need for firmware updates in payment systems that “environmental operating conditions are unique to each environment, and thus affect deployed devices differently. As such, it is difficult for a device manufacturer to ameliorate such issues since they may only affect a specific device.” (Col. 1, Ln 13-24).
Claim 16 is rejected on the same basis as claim 7 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The prior art cited in the attached PTO-892 form includes prior art relevant to applicant’s disclosures related to dual-processor firmware update systems.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW J BROPHY whose telephone number is (571)270-1642. The examiner can normally be reached Monday-Friday, 9am-4:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Wei Zhen can be reached on 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.
MJB
9/30/2025
/MATTHEW J BROPHY/Primary Examiner, Art Unit 2191