Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
2. This office action has been issued in response to a reply filed on 12/29/2025. Applicants' arguments have been carefully and respectfully considered and found not persuasive. Accordingly, this action has been made FINAL.
Status of Claims
3. Claims 16-30 are pending, of which claims, of which claim 16, 29 and 30 are in independent form.
The Office's Note:
4. The Office has cited particular paragraphs / columns and line numbers in the reference(s) applied to the claims above for the convenience of the Applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim(s), other passages and figures may apply as well. It is respectfully requested from the Applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the cited passages as taught by the prior art or relied upon 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.
5. Claim 29 invoked 112(f).
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: the update agent handler claim 29.
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 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.
6. Claim 16-30 rejected under 35 U.S.C. 103(a) as being unpatentable over Olinsky US 20180165157 (hereinafter Olinsky – IDS of records) and further in view David US 20200174779 (hereinafter David).
Claim 1 rejected, Olinsky teaches a method for updating software loaded on a secure element (Olinsky, para [0004], second and third sentence), SE, wherein the SE comprises an update agent handler (Olinsky, para [0052]-[0053]: daemon) and an update agent (Olinsky, implicit: the code on the IoT device performing the update), the method comprising (Olinsky, abstract and summary):
receiving at the SE from a device a request to backup a current version of software loaded on the SE(Olinsky, para [ 0055] describes backing up the current version);
performing at the SE a secure backup of the current software version, and returning the software backup to the device (Olinsky, para [ 0055] describes backing up the current version; [0056] discloses that these backups may be encrypted, thus making them a secure backup. Para [0069], the saved backup may also be encrypted.), to be stored thereon;
performing at the SE an update process of the current software version, to obtain an updated software version(Olinsky, para [ 0057], the IoT device updates to the received release in a way that is self-managing and which is robust to failures in the IoT device update. Para [0059-0064], updated release and the updated release becomes the current release); and
if the update process failed, performing a rollback to restore the software backup as a new current software version on the SE(Olinsky, para [0065-0066], buggy release or unstable release. Para [ 0067], use the previous release to rollback).
The Office would like to use prior art David to backup Olinsky to further teach limitation
returning the software backup to the device(David, US 20200174779, para [0029-0030], storage media 224 on which backup software 226 for the updatable electronic component(s) 110 may be stored. Para [0055], vehicle data store 212. Para [0056], the OTA updater device 108 may request a backup software version from another source (e.g., a remote computer system). )
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate David into Olinsky to receive a software update package from a remote computer system via a wireless communication network. The software update package includes a first software update for the first updatable electronic component. The first software update is then installed in the first updatable electronic component. If the installation of the first software update is determined to be successful, the first software update is stored in a storage medium in the vehicle computer system as a current backup software version for the first updatable electronic component as suggested by David (See abstract and summary).
Claim 17 is rejected for the reasons set forth hereinabove for claim 16, Olinsky and David teach the method according to claim 16, wherein performing a secure backup comprises the update agent handler instructing the update agent to create a restore image, corresponding to the current software version(Olinsky, para [ 0055] describes backing up the current version; [0056] discloses that these backups may be encrypted, thus making them a secure backup. Para [0069], the saved backup may also be encrypted.).
Claim 18 is rejected for the reasons set forth hereinabove for claim 17, Olinsky and David teach the method according to claim 17, wherein the update agent is configured to create the restore image by encapsulating the current software version and securing it with cryptographic keys (Olinsky, para [ 0055] describes backing up the current version; [0056] discloses that these backups may be encrypted, thus making them a secure backup. Para [0069], the saved backup may also be encrypted.); and
wherein the update agent handler is configured to return the restore image as the backup software to the device(David, para [0029-0030], storage media 224 on which backup software 226 for the updatable electronic component(s) 110 may be stored. Para [0055], vehicle data store 212. Para [0056], the OTA updater device 108 may request a backup software version from another source (e.g., a remote computer system). ).
Claim 19 is rejected for the reasons set forth hereinabove for claim 16, Olinsky and David teach the method according to claim 16, further comprising receiving at the SE a request to update the current software version, the update request comprising a software update, wherein the update process is performed using the software update(Olinsky, para [ 0057], the IoT device updates to the received release in a way that is self-managing and which is robust to failures in the IoT device update. Para [0059-0064], updated release and the updated release becomes the current release).
Claim 20 is rejected for the reasons set forth hereinabove for claim 19, Olinsky and David teach the method according to claim 19, wherein upon receiving at the SE the update request, the method comprise further verifying the update request, and if the request is allowed, performing the update process(Olinksky, para [0004], if the updated release is determined to be valid, the updated release is made the current release. Para [0053], upon receiving the indication related to the update for the IoT device, the IoT device validates the update. In some examples, the IoT device validates the update by validating that the update is properly signed.).
Claim 21 is rejected for the reasons set forth hereinabove for claim 20, Olinsky and David teach the method according to claim 20, wherein verifying the update request comprises instructing the update agent handler to verify integrity and confidentiality of the update request and of the software update contained therein(Olinksky, para [0004], if the updated release is determined to be valid, the updated release is made the current release. Para [0053], upon receiving the indication related to the update for the IoT device, the IoT device validates the update. In some examples, the IoT device validates the update by validating that the update is properly signed. Para [0061-0062], the determination is a signature check that includes comparing, for each image binary in the updated release, the signature on the image binary with the corresponding signature indicated in the metadata for the image binary… a determination is made as to whether or not the updated release is a forgery. In some examples, the determination at decision block 453 includes a checksum verification.).
Claim 22 is rejected for the reasons set forth hereinabove for claim 16, Olinsky and David teach the method according to claim 16, wherein performing at the SE an update process of the current software version comprises updating the current software version based on the software update, deleting the current software version and loading the updated software version into the SE as the new current software version(Olinksy, para [0060-0064], Returning to decision block 452, if it was determined at decision block 452 that the updated release is valid, the process moves to block 458. At block 458, in some examples, the updated release is made the current release. In some examples, this is accomplished by moving the primary pointer to the updated release, so that the updated release becomes the current release. The process then advances to block 459. At block 459, in some examples, the IoT device begins execution of the current release.).
Claim 23 is rejected for the reasons set forth hereinabove for claim 22, Olinsky and David teach the method according to claim 22, wherein the update process is determined to have failed if during the performing of the software update process, the software update process is aborted before being completed(Olinksy, para [0062], At block 455, in some examples, the update is rejected and the current release is maintained. In some examples, the IoT device notifies the cloud service that the update is rejected. The process then proceeds to block 459.).
Claim 24 is rejected for the reasons set forth hereinabove for claim 22, Olinsky and David teach the method according to claim 22, wherein the update process is determined to have failed if after completing the software update process, the update agent handler reboot the new current software version and during the rebooting process a boot failure occurs(Olinsky, para [0064-00665], a release may have been determined to be valid prior to moving the pointer, but upon execution of the release, the release starts to crash. ).
Claim 25 is rejected for the reasons set forth hereinabove for claim 24, Olinsky and David teach the method of claim 24, further comprising the update agent handler instructing the update agent to perform the rollback(Olinsky, para [0065-0066], buggy release or unstable release. Para [ 0067], use the previous release to rollback).
Claim 26 is rejected for the reasons set forth hereinabove for claim 22, Olinsky and David teach the method according to claim 22, wherein the update process is determined to have failed if after completing the software update process, the new current software version is successfully booted, and the SE determines that there is a data inconsistency between data and applets stored in the SE and the new current software version(Olinsky, para [0065-0066], buggy release or unstable release. Para [0071], erratic behavior. Para [0075], an operator of the cloud service may identify a severe bug or problem with the current release and force a rollback to a prior release to prevent the current release from causing damage or being exploited.).
Claim 27 is rejected for the reasons set forth hereinabove for claim 26, Olinsky and David teach the method of claim 26, further comprising the update agent handler determining whether other updates in the SE are operational, and if other updates are not operational, instructing the update agent to perform the rollback(Olinsky, para [0050], the cloud services are capable of initiating both upgrades and downgrades in the release. In some examples, the cloud can force IoT devices to rollback to an old release. ).
Claim 28 is rejected for the reasons set forth hereinabove for claim 16, Olinsky and David teach the method according to claim 16, wherein performing a roll-back to restore the software backup as the current software version on the SE comprises ( Olinsky, para [0065-0066], buggy release or unstable release. Para [ 0067], use the previous release to rollback.):
receiving at the SE from the device the software backup (David, para [0029-0030], storage media 224 on which backup software 226 for the updatable electronic component(s) 110 may be stored. Para [0055], vehicle data store 212. Para [0056], the OTA updater device 108 may request a backup software version from another source (e.g., a remote computer system). Para [0050], the IoT devices include backup copies of previous updates. ); and
instructing by the update agent handler the update agent to perform loading of the software backup into the SE( Olinsky, para [0065-0066], buggy release or unstable release. Para [ 0067], use the previous release to rollback.).
Claim 29 rejected, Olinsky teaches a secure element(Olinsky, para [0004], IoT device), SE, comprising an update agent handler (Olinsky, para [0052]-[0053]: daemon) and an update agent(Olinsky, implicit: the code on the IoT device performing the update), wherein the update agent handler is configured to(Olinsky, abstract and summary):
receive from a device a request to backup a current version of software loaded on the SE(Olinsky, para [ 0055] describes backing up the current version), instruct the update agent to generate a software backup of the current software version, and return the software backup to the device, to be stored thereon (Olinsky, para [ 0055] describes backing up the current version; [0056] discloses that these backups may be encrypted, thus making them a secure backup. Para [0069], the saved backup may also be encrypted.);
receive from the device a request to update the current software version, the update request comprising a software update, and to instruct the update agent to perform an update process of the current software version by using the software updated(Olinsky, para [ 0057], the IoT device updates to the received release in a way that is self-managing and which is robust to failures in the IoT device update. Para [0059-0064], updated release and the updated release becomes the current release); and
if the update process failed, instruct the update agent to perform a rollback to restore the software backup as a new current software version on the SE(Olinsky, para [0065-0066], buggy release or unstable release. Para [ 0067], use the previous release to rollback).
The Office would like to use prior art David to backup Olinsky to further teach limitation
return the software backup to the device(David, US 20200174779, para [0029-0030], storage media 224 on which backup software 226 for the updatable electronic component(s) 110 may be stored. Para [0055], vehicle data store 212. Para [0056], the OTA updater device 108 may request a backup software version from another source (e.g., a remote computer system). ).
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate David into Olinsky to receive a software update package from a remote computer system via a wireless communication network. The software update package includes a first software update for the first updatable electronic component. The first software update is then installed in the first updatable electronic component. If the installation of the first software update is determined to be successful, the first software update is stored in a storage medium in the vehicle computer system as a current backup software version for the first updatable electronic component as suggested by David (See abstract and summary).
Claim 30 rejected, Olinsky teaches an apparatus, comprising at least one processor, at least one memory including computer program code, and the at least one processor with the at least one memory and the computer program code, being arranged to cause the apparatus to at least perform(Olinsky, abstract and summary):
requesting a secure element, SE, to perform backup of a current version of software loaded on the SE(Olinsky, para [0004-0005]. Para [ 0055] describes backing up the current version);
receiving from the SE a backup of the current software version loaded on the SE, and storing the software backup in the memory (Olinsky, para [ 0055] describes backing up the current version; [0056] discloses that these backups may be encrypted, thus making them a secure backup. Para [0069], the saved backup may also be encrypted.), to be stored thereon.);
requesting the SE to update the current software version, and receiving from the SE an update result(Olinsky, para [ 0057], the IoT device updates to the received release in a way that is self-managing and which is robust to failures in the IoT device update. Para [0059-0064], updated release and the updated release becomes the current release); and
if the update result indicates an update process failure, instructing the SE to perform a rollback to restore the software backup stored in the memory as a new current software version on the SE(Olinsky, para [0065-0066], buggy release or unstable release. Para [ 0067], use the previous release to rollback).
The Office would like to use prior art David to backup Olinsky to further teach limitation
storing the software backup in the memory (David, US 20200174779, para [0029-0030], storage media 224 on which backup software 226 for the updatable electronic component(s) 110 may be stored. Para [0055], vehicle data store 212. Para [0056], the OTA updater device 108 may request a backup software version from another source (e.g., a remote computer system). )
It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate David into Olinsky to receive a software update package from a remote computer system via a wireless communication network. The software update package includes a first software update for the first updatable electronic component. The first software update is then installed in the first updatable electronic component. If the installation of the first software update is determined to be successful, the first software update is stored in a storage medium in the vehicle computer system as a current backup software version for the first updatable electronic component as suggested by David (See abstract and summary).
Response to Argument
7. With respect to claims 16, 29 and 30, On page 7-8, applicant argued that “:However, neither Olinsky or David teaches or suggests a backup of a current version of software loaded on the SE that also originates from the secure element and is returned to the external device. Instead, Olinsky saves a backup copy of the release, which is not the current version of software loaded on the device, and David teaches that the OTA update device obtains the backup from a remote system.”
The Office respectfully disagreed. On para [0055], Olinsky teaches “ In some examples, the IoT device saves at least one back-up copy of the release, in addition to the primary copy. In some examples, the IoT device saves at least one back-up copy of at least a portion of the previous release. In some examples, the IoT device saves at least one back-up copy of the previous release, as well as at least one back-up copy of each of the N previous “critical” releases. In some examples, some or all of the back-up copies are compressed, and in some examples, some or all of the back-up copies are uncompressed. For instance, in some examples, for an updated application in which the application is execute-in-place (XiP) in flash, the primary copy to be executed in flash memory is uncompressed on flash memory, and two compressed back-up copies are saved.” which means the IoT device saves a backup of a current version of software before installing the new version of the software which means “performing at the SE a secure backup of the current software version, and returning the software backup to the device”.
Furthermore, on para [0050], Olinksky teaches “In some examples, the cloud services are capable of initiating both upgrades and downgrades in the release. In some examples, the cloud can force IoT devices to rollback to an old release. As discussed in greater detail below, in some examples, the IoT devices include backup copies of previous updates. In some examples, the cloud can force an IoT device to downgrade to a previous update release that is stored as a backup copy on the IoT device.” The examiner notes that “backup copies of previous updates” which include a current version of software before installing the new version of the software which means “performing at the SE a secure backup of the current software version, and returning the software backup to the device”.
In addition, on para [0007], David teaches “in response to determining that the installation of the first software update is successful, stores the first software update in a storage medium in the vehicle computer system as a current backup software version for the first updatable electronic component.” which means the a backup of a current version of software was saved before installing the new version of the software which means “performing at the SE a secure backup of the current software version, and returning the software backup to the device”.
In conclusion, Olinsky and David teaches “performing at the SE a secure backup of the current software version, and returning the software backup to the device”.
In response to applicant's argument that the references fail to show certain features of applicant’s invention, it is noted that the features upon which applicant relies (i.e., With the proposed failsafe rollback solution, the system stability in case of a faulty software/OS update is increased (paras. [011] and [063]). The solution provides flexibility and independency of the card manufacturer, as a SE OEM does not need to intervene if a rollback is needed (paras. [011] and [063]).) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Conclusion
8. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUY KHUONG THANH NGUYEN whose telephone number is (571)270-7139. The examiner can normally be reached Monday - Friday 0800-1630.
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, Lewis Bullock can be reached on 5712723759. 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.
/DUY KHUONG T NGUYEN/ Primary Examiner, Art Unit 2199
Prosecution Insights