DETAILED ACTION
Claims 1-10 and 12-21 are pending in the current application
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 .
Election/Restrictions
Applicant’s election without traverse of claims 1-4, 9-10, 12-15 and 20 in the reply filed on 3/30/26 is acknowledged.
Claims 5-8, 16-19 and 21 are withdrawn from further consideration pursuant to 37 CFR 1.142(b), as being drawn to a nonelected Group 2 claims 5-8, 16-19 and 21, there being no allowable generic or linking claim. Applicant timely traversed the restriction (election) requirement in the reply filed on 3/30/36.
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.
Claims 1-3, 9-10, 12-14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Jamadagni et al. (Pub. No. US 2014/0366012 A1), and further in view of Blankenburg et al. (Pub. No. US 2018/0031632 A1).
As to claim 1, Jamadagni discloses a device operation method applied for execution by a first device, the method comprising: acquiring, from a second device associated with the first device, first firmware data required to be loaded by a chip of the first device (Jamadagni [0004] lines 10-14, [0008] lines 4-15, [0030] lines 4-11, [0041] lines 1-5 and [0042] lines 30-32; which shows that a firmware version update/first firmware data is downloaded to a base station device/second device and then provided/acquire by the user equipment/first device and loading/installing the firmware update of the user device the specifics of the firmware data loaded onto a chip of a device seen specifically disclosed in the teachings of Blankenburg below).
Jamadagni does not specifically disclose the specifics of loading the first firmware data into the chip without going through a local nonvolatile memory of the first device.
However, Blankenburg discloses the specifics of loading the first firmware data into the chip without going through a local nonvolatile memory of the first device (Blankenburg [0018] lines 1-6, [0028] lines 9-12, [0039] lines 7-10, [0041] line 1-6 and [0050] lines 1-4; which shows the specifics of being able to load firmware into a target chip directly by going through another chip/host chip, that acquires the image from another source and host/stores in memory that can be some other host/store of the firmware update image asides from non-volatile memory to then load directly into the RAM of the target chip, thus viewed as being able to load the firmware data for the chip without going through local non-volatile memory that in light of the teachings of Jamadagni above showing the specifics of the sending of the acquired firmware update data to the first/user equipment to be used can together be viewed as disclosing the specifics of loading the first firmware data into the chip without going through a local nonvolatile memory of the first device).
Therefore, it would have been obvious to one of ordinary skill in the art to incorporate the teachings of Blankenburg showing firmware updating a device directly to chip ram without requiring non-volatile memory into the firmware update of a device of Jamadagni for the purpose of reducing the cost associated with firmware devices, as taught by Blankenburg [0050] lines 1-4
As to claim 2, Jamadagni discloses wherein the step of acquiring, from a second device associated with the first device, first firmware data required to be loaded by a chip of the first device comprises: sending a firmware request to the second device associated with the first device (Jamadagni [0008] lines 4-15 and [0039] lines 1-9; which a request for the firmware update/firmware data from the user device/first device where the firmware update is stored/cached in the base station/second device viewed as associated with the user device/first device); and
receiving the first firmware data corresponding to the firmware request sent by the second device, wherein the first firmware data is pre-stored in the second device, or the first firmware data is acquired by the second device from a firmware resource pool located in a cloud (Jamadagni [0008] lines 4-15 and [0039] lines 1-9; which shows in response to a request for the firmware update/firmware data from the user device/first device where the firmware update is stored/cached in the base station/second device, viewed as a type of pre-stored being able to transmit the firmware update/data to the first/user device thus showing receiving the first firmware data corresponding to the firmware request sent by the second device, wherein the first firmware data is at least pre-stored in the second device).
As to claim 3, Jamadagni discloses further comprising: receiving second firmware data sent by the second device, wherein the second firmware data is firmware data corresponding to firmware customization information, wherein the firmware customization information comprises at least one of version customization information or parameter configuration information, and the firmware customization information is generated for the first device by a firmware management platform (Jamadagni [0008] lines 4-15, [0029] lines 5-10, [0030] lines 4-11 and [0034] lines 1-6; which shows being and to receive firmware update/data corresponding to specific identifier/customization information that corresponding to a specific firmware version update where the identifier/customization information is generated/provided from a device management server associated with firmware management, viewed as a type of firmware management platform where there can be a plurality of firmware updates thus viewed as including a second firmware data).
Jamadagni does not specifically disclose loading the second firmware data into the chip without going through the local nonvolatile memory of the first device.
However, Blankenburg discloses loading the second firmware data into the chip without going through the local nonvolatile memory of the first device (Blankenburg [0018] lines 1-6, [0028] lines 9-12, [0039] lines 7-10, [0041] line 1-6 and [0050] lines 1-4; which shows the specifics of being able to load firmware into a target chip directly by going through another chip/host chip, that acquires the image from another source and host/stored in memory that can be some other memory source of the firmware update image asides from non-volatile memory to then load directly into the RAM of the target chip, thus viewed as being able to load the firmware data for the chip without going through local non-volatile memory that in light of the teachings of Jamadagni above showing the specifics of the second firmware update/data being sent to the target/first device to be used can together be viewed as showing the specifics of loading the second firmware data into the chip without going through the local nonvolatile memory of the first device).
Therefore, it would have been obvious to one of ordinary skill in the art to incorporate the teachings of Blankenburg showing firmware updating a device directly to chip ram without requiring non-volatile memory into the firmware update of a device of Jamadagni for the purpose of reducing the cost associated with firmware devices, as taught by Blankenburg [0050] lines 1-4.
As to claim 9, Jamadagni discloses a server firmware management system, comprising: an access device connected with a server; (Jamadagni [0008] lines 12-15; which shows a base station/access device connected to user equipment viewed as including server)
a firmware resource pool (Jamadagni [0008] lines 9-12 and [0029] lines 8-10; which shows a FOTA server storing firmware updates for the plurality of user equipment, viewed as a type of resource pool); and
a firmware management platform (Jamadagni [0008] lines 4-7; which show a device management server that is associating with managing firmware updates to user devices, viewed as a type of firmware management platform),
wherein the access device is respectively connected with the firmware resource pool and the firmware management platform (Jamadagni [0008] lines 4-15; which shows the base station/access device is in communication and thus connected with the FOTA server/firmware resource pool and device management server/firmware management platform),
the firmware management platform customizes at least one of a version or a parameter of a firmware for the server and sends customization information to the access device (Jamadagni [0008] lines 4-15 and [0030] lines 4-11; which shows the device management server sends to the base station/access device a notification of availability of a new version of firmware for the user equipment along with the firmware update resource identifier viewed as a customization of at least a version of a firmware for the sever/user equipment),
the access device acquires firmware data consistent with at least one of the version or the parameter characterized by the customization information from the firmware resource pool according to the customization information (Jamadagni [0008] lines 4-15, [0030] lines 4-11, [0041] lines 1-5 and [0042] lines 30-32; which shows the base station/access device is able to acquire/receive firmware update data associated with/according to the new firmware version/customization information from the resource pool/ FOTA server), and
sends acquired firmware data to the server so that the server loads the firmware data (Jamadagni [0008] lines 4-15, [0030] lines 4-11, [0041] lines 1-5 and [0042] lines 30-32; which shows that the base station/access device acquires/fetches from the FOTA server/firmware resource pool the firmware update associated with the new firmware version associated with the firmware update resource identifier, viewed as firmware data consistent with the at least one version characterized by the customization/request and then send/transmits that acquired firmware information to the respective user equipment/server for upgrading the firmware, viewed as loading the firmware version update information).
Jamadagni does not specifically disclose the specifics of sends acquired firmware data to the server so that the server loads the firmware data into a chip without going through a local nonvolatile memory.
However, Blankenburg discloses the specifics of sends acquired firmware data to the server so that the server loads the firmware data into a chip without going through a local nonvolatile memory (Blankenburg [0018] lines 1-6, [0028] lines 9-12, [0039] lines 7-10 , [0041] line 1-6 and [0050] lines 1-4; which shows the specifics of being able to load firmware into a target chip directly by going through another chip/host chip, that acquires the image from another source and host/stores in memory that can be some other host/store of the firmware update image asides from non-volatile memory to then load directly into the RAM of the target chip, thus viewed as being able to load the firmware data for the chip without going through local non-volatile memory that in light of the teachings of Jamadagni above showing the specifics of the sending of the acquired firmware data to the server can together be viewed as disclosing the specifics of sends acquired firmware data to the server so that the server loads the firmware data into a chip without going through a local nonvolatile memory)
Therefore, it would have been obvious to one of ordinary skill in the art to incorporate the teachings of Blankenburg showing firmware updating a device directly to chip ram without requiring non-volatile memory into the firmware update of a device of Jamadagni for the purpose of reducing the cost associated with firmware devices, as taught by Blankenburg [0050] lines 1-4.
As to claim 10, Jamadagni discloses a computing device comprising: a processor (Jamadagni [0051] lines 1-4); and
a memory having an executable code stored thereon that, when executed by the processor, causes the processor to (Jamadagni [0051] lines 1-4 and [0054] lines 5-8)
The remaining limitation of this claim are comparable to claim 1 above and rejected under the same reasoning.
As to claim 12, Jamadagni discloses a non-transitory machine-readable storage medium having an executable code stored thereon that, when executed by a processor of an electronic device, causes the processor to (Jamadagni [0054] lines 5-16)
The remaining limitation of this claim are comparable to claim 1 above and rejected under the same reasoning.
As to claim 13 it is comparable to claim 2 above and rejected under the same reasoning.
As to claim 14 it is comparable to claim 3 above and rejected under the same reasoning.
As to claim 20 it is comparable to claim 2 above and rejected under the same reasoning.
Claims 4 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Jamadagni and Blankenburg as applied to claims 3 and 14 above, and further in view of Kushwaha et al. (Pub. No. US 2020/0218531 A1).
As to claims 4 and 15, Jamadagni does not specifically disclose, however, Blankenburg disclose reloading the first firmware data to the chip without going through the local nonvolatile memory of the first device (Blankenburg [0018] lines 1-6, [0028] lines 9-12, [0039] lines 7-10, [0041] line 1-6 and [0050] lines 1-4; which shows the specifics of being able to load/reload firmware into a target chip directly by going through another chip/host chip, that acquires the image from another source and host/stored in memory that can be some other memory source of the firmware update image asides from non-volatile memory to then load/reload directly into the RAM of the target chip, thus viewed as being able to load/reload the firmware data for the chip without going through local non-volatile memory that in light of the teachings of Jamadagni above showing the specifics of the first firmware update/data being sent to the target/first device can together be viewed as showing the specifics of reloading the first firmware data to the chip without going through the local nonvolatile memory of the first device, where the specifics of keep stored the old/past version of firmware available for loading is seen specifically disclosed below in the teachings of Kushwaha below).
Therefore, it would have been obvious to one of ordinary skill in the art to incorporate the teachings of Blankenburg showing firmware updating a device directly to chip ram without requiring non-volatile memory into the firmware update of a device of Jamadagni for the purpose of reducing the cost associated with firmware devices, as taught by Blankenburg [0050] lines 1-4
Jamadagni as modified by Blankenburg do not specifically disclose sending a downgrade request to the second device; receiving the first firmware data sent by the second device.
However, Kushwaha discloses sending a downgrade request to the second device (Kushwaha [0035] lines 1-21 and [0044] lines 6-8; which shows being able to download updated software/firmware component separately from the update manager datastore in response to a request from the first device/vehicle, where the data store also stores older versions of the software/firmware as well, thus responsive for a specific request for the older version of firmware/downgrade request being able to send the older/past firmware version);
receiving the first firmware data sent by the second device (Kushwaha [0035] lines 1-21 and [0044] lines 6-8; which shows being able to target and download to the vehicle/first device specific updated software/version component where the updated software components can be past/older version of firmware thus the specifics of first firmware version seen specifically disclosed in Jamadagni above).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the teachings of Kushwaha showing the specifics of keeping old firmware version stored in a database where devices can request specific firmware version from the database into the firmware update of a device from a firmware repository of Jamadagni as modified by Blankenburg for the purpose of increasing the adaptability of firmware update so can request older or updated version of firmware as needed Kushwaha [0035] lines 1-21 and [0044] lines 6-8.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRADFORD F WHEATON whose telephone number is (571)270-1779. The examiner can normally be reached Monday-Friday 8:00-5:00 EST.
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, Chat Do can be reached at 571-272-3721. 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.
/BRADFORD F WHEATON/Examiner, Art Unit 2193
Prosecution Insights