DETAILED ACTION
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 .
Claims 16-30 are pending.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claim 16 is provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 16 and 18 of copending Application No. 18/292443 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because claim 16 of the instant application are anticipated by patent claims 16 and 18 in that the patent claims contain all the limitations of the instant application.
Instant Application
Copending Application 18/292443
Sibert et al. (US 10936719)
Claim 16: A method for loading and personalizing a software, including an operating system, OS, in a secure element, SE, the method comprising:
Claim 16: A method for updating an installed software, including an operating system, OS, in a secure element, SE, the method comprising:
loading an update agent into the SE;
Claim 16:providing an update agent in the SE;
loading software personalization data into the SE;
Claim 16: securing specific data required for operating the installed software in a memory of the update agent;
storing the software personalization data in the update agent;
Claim 16: securing specific data required for operating the installed software in a memory of the update agent;
loading a software image into the SE;
Claim 16: loading a software image into the SE
personalizing the loaded software image using the software personalization data.
Claim 18: wherein the installed software has been personalized with the personalization data and the installed software is updated in that the software image is made operable by personalizing the software image using the personalization data.
Claim 22: A secure element, SE, comprising an update agent and an operating system, OS,wherein the update agent and the operating system are
Claim 16: securing specific data required for operating the installed software in a memory of the update agent;
configured to communicate with each other through an Application Programming Interface, API, wherein the update agent comprises
col. 27, lines 18-36, “An SMP broker component of device 112 may be configured to manage secure communication authentication with device 110 (e.g., secure element 230 of device 100). An operating system or other application of device 110 may be configured to call specific application programming interfaces (“APIs”) and an SMP broker component may be configured to process requests of those APIs and respond with data that may derive the user interface of device 100 and/or respond with application protocol data units (“APDUs”) that may communicate with secure element 230 of device 110 (e.g., via a communication path between device 112 and device 110).
a first memory storing authentication data for authenticating a software image;
Claim 16:wherein the installed software is stored together with the specific data in a memory area of the SE and claim 17: in the step of securing, specific data which comprises personalization data of the installed software is secured, secure credentials and/or cryptographic keys.
a second memory storing personalization data of the software image.
Claim 16:securing specific data required for operating the installed software in a memory of the update agent; and claim 18: in the step of securing, specific data which comprises personalization data of the installed software is secured, secure credentials and/or cryptographic keys.
Claim 29: An electronic device, comprising: at least one processor; at least one memory including computer program code;
Claim 16: including an operating system, OS, in a secure element, SE,
a secure element;
Claim 16: including an operating system, OS, in a secure element, SE,
wherein the at least one processor with the at least one memory and the computer program code, being arranged to cause the electronic device to at least perform: providing to the secure element, SE, a software image, to be loaded and stored thereon;
Claim 16: loading a software image into the SE
instructing the SE to perform authentication and/or decryption of the software image using authentication data stored in the SE; and
(col. 14, lines 55 – col. 15, line 1, “Execution of one or more preflight scripts of an update package at operation 304 may include any suitable operations, including, but not limited to, verifying or otherwise decrypting any portion of the received update package (e.g., using any suitable decryption key), identifying at least one other version (e.g., previously loaded version) of a current/source secure element asset to be updated by the package (e.g., identify SE OS 232 in response to receiving package 233 with new SE OS 233c), exporting any trust data from each identified current secure element asset (e.g., obtaining, serializing, and/or exporting any suitable OS trust data of SE OS 232 for preservation purposes during an SE OS update), and uninstalling each identified current secure element asset”)
instructing the SE to obtain personalization data stored in the SE, to perform personalization of the software image using the personalization data, and to store the personalized software image in the SE.
Claim 18: wherein the installed software has been personalized with the personalization data and the installed software is updated in that the software image is made operable by personalizing the software image using the personalization data.
Claim 18 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 17 of copending Application No. 18/292443 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because claim 18 of the instant application are anticipated by patent claims 17 in that the patent claims contain all the limitations of the instant application.
Claim 19 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 23 of copending Application No. 18/292443 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because claim 19 of the instant application are anticipated by patent claims 23 in that the patent claims contain all the limitations of the instant application.
Claims 22 and 27 is provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 16-18 of copending Application No. 18/292443 in view of Sibert et al. (US 10936719).
Although the claims at issue are not identical, they are not patentably distinct from each other because claim 22 of the instant application are an obvious combination of patent claim 16-18 and Sibert in that the patent claims in combination with Sibert contain all the limitations of the instant application.
Sibert is cited to teach a similar concept of secure loading of firmware into a system. Sibert teaches using decryption and authentication to securely download updated firmware. Based on Sifert, it would have been obvious before the effective filing date of the invention to a person having ordinary skill in the art to which said subject matter pertains to have modified Application 18292542 claim 22 to use decryption and authentication to securely download updated firmware. Furthermore, being able to use decrypt and authenticate when downloading updated firmware improves on Application 18292542 claim 22 by being able securely download the firmware. To one of ordinary skill in the art before the effective filing data of the invention it would have been advantageous to make this modification where “Execution of one or more preflight scripts of an update package at operation 304 may include any suitable operations, including, but not limited to, verifying or otherwise decrypting any portion of the received update package (e.g., using any suitable decryption key)”, (col. 14, lines 55-62) to provide security to the system.
As to claim 27, Application 18292443 and Sibert teach these claims according to the reasoning provided in claim 22.
Claims 29 and 30 is provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 16 and 18 of copending Application No. 18/292443 in view of Sibert et al. (US 10936719).
Although the claims at issue are not identical, they are not patentably distinct from each other because claim 29 of the instant application are an obvious combination of patent claim 16 and 18 and Sibert in that the patent claims in combination with Sibert contain all the limitations of the instant application.
Sibert is cited to teach a similar concept of secure loading of firmware into a system. Sibert teaches using decryption and authentication to securely download updated firmware. Based on Sifert, it would have been obvious before the effective filing date of the invention to a person having ordinary skill in the art to which said subject matter pertains to have modified Application 18292542 claim 29 to use decryption and authentication to securely download updated firmware. Furthermore, being able to use decrypt and authenticate when downloading updated firmware improves on Application 18292542 claim 29 by being able securely download the firmware. To one of ordinary skill in the art before the effective filing data of the invention it would have been advantageous to make this modification where “Execution of one or more preflight scripts of an update package at operation 304 may include any suitable operations, including, but not limited to, verifying or otherwise decrypting any portion of the received update package (e.g., using any suitable decryption key)”, (col. 14, lines 55-62) to provide security to the system.
Although the claims at issue are not identical, they are not patentably distinct from each other because claim 30 of the instant application are an obvious combination of patent claim 9 and 12 and Sibert in that the patent claims in combination with Sibert contain all the limitations of the instant application.
As to claim 30, Application 18292443 and Sibert teach these claims according to the reasoning provided in claim 29.
Claim 16 is provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 and 4 of copending Application No. 18/411563 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because claim 16 of the instant application are anticipated by patent claims 1 and 4 in that the patent claims contain all the limitations of the instant application.
Instant Application
Copending Application 18/411563
Sibert et al. (US 10936719)
Claim 16: A method for loading and personalizing a software, including an operating system, OS, in a secure element, SE, the method comprising:
Claim 1: A method for changing and restoring personalization data of an installed software during a Full Reflash in a secure element, SE, the method comprising:
loading an update agent into the SE;
Claim 1:providing an update agent in the SE;
loading software personalization data into the SE;
Claim 4: the personalization data is stored together with the installed software in a memory area of the SE
storing the software personalization data in the update agent;
Claim 4: copying the personalization data from the memory area of the secure element to a memory of the update agent.
loading a software image into the SE;
Claim 1: loading a software image into the secure element
personalizing the loaded software image using the software personalization data.
Claim 1: personalizing the software image by the personalization data secured in the memory of the update agent.
Claim 29: An electronic device, comprising: at least one processor; at least one memory including computer program code;
Claim 9: the installed software to the memory and Claim 12: a processor of the security element.
a secure element;
Claim 12: providing an update agent in the SE;
wherein the at least one processor with the at least one memory and the computer program code, being arranged to cause the electronic device to at least perform: providing to the secure element, SE, a software image, to be loaded and stored thereon;
Claim 9 : loading a software image into the SE, and claim 12: and/or is realized as an executable software product configured to be installed on a security element comprising an installed software,
instructing the SE to perform authentication and/or decryption of the software image using authentication data stored in the SE; and
(col. 14, lines 55 – col. 15, line 1, “Execution of one or more preflight scripts of an update package at operation 304 may include any suitable operations, including, but not limited to, verifying or otherwise decrypting any portion of the received update package (e.g., using any suitable decryption key), identifying at least one other version (e.g., previously loaded version) of a current/source secure element asset to be updated by the package (e.g., identify SE OS 232 in response to receiving package 233 with new SE OS 233c), exporting any trust data from each identified current secure element asset (e.g., obtaining, serializing, and/or exporting any suitable OS trust data of SE OS 232 for preservation purposes during an SE OS update), and uninstalling each identified current secure element asset”)
instructing the SE to obtain personalization data stored in the SE, to perform personalization of the software image using the personalization data, and to store the personalized software image in the SE.
Claim 12: loading a software image into the secure element, wherein the software image represents an updated version of the installed software; and personalizing the software image by the personalization data secured in the memory of the update agent; and/or is realized as an executable software product configured to be installed on a security element comprising an installed software
Claim 17 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 and 3 of copending Application No. 18/411563 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because claim 17 of the instant application are anticipated by patent claims 1 and 3 in that the patent claims contain all the limitations of the instant application.
Claim 19 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 3 of copending Application No. 18/411563 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because claim 19 of the instant application are anticipated by patent claim 3 in that the patent claims contain all the limitations of the instant application.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claims 29 and 30 is provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 9 and 12 of copending Application No. 18/411593 in view of Sibert et al. (US 10936719).
Although the claims at issue are not identical, they are not patentably distinct from each other because claim 29 of the instant application are an obvious combination of patent claim 9 and 12 and Sibert in that the patent claims in combination with Sibert contain all the limitations of the instant application.
Sibert is cited to teach a similar concept of secure loading of firmware into a system. Sibert teaches using decryption and authentication to securely download updated firmware. Based on Sifert, it would have been obvious before the effective filing date of the invention to a person having ordinary skill in the art to which said subject matter pertains to have modified Application 18292542 claim 29 to use decryption and authentication to securely download updated firmware. Furthermore, being able to use decrypt and authenticate when downloading updated firmware improves on Application 18292542 claim 29 by being able securely download the firmware. To one of ordinary skill in the art before the effective filing data of the invention it would have been advantageous to make this modification where “Execution of one or more preflight scripts of an update package at operation 304 may include any suitable operations, including, but not limited to, verifying or otherwise decrypting any portion of the received update package (e.g., using any suitable decryption key)”, (col. 14, lines 55-62) to provide security to the system.
Although the claims at issue are not identical, they are not patentably distinct from each other because claim 30 of the instant application are an obvious combination of patent claim 9 and 12 and Sibert in that the patent claims in combination with Sibert contain all the limitations of the instant application.
As to claim 30, Application 18411563 and Sibert teach these claims according to the reasoning provided in claim 29.
Claim 27 is provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 16 of copending Application No. 18/292398 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because claim 27 of the instant application are anticipated by patent claims 16 in that the patent claims contain all the limitations of the instant application.
Instant Application
Copending Application 18/292398
Sibert et al. (US 10936719)
Claim 22: A secure element, SE, comprising an update agent and an operating system, OS,wherein the update agent and the operating system are
Claim 16: A secure element, SE, comprising an update agent, wherein the update agent comprises: a communication interface
configured to communicate with each other through an Application Programming Interface, API, wherein the update agent comprises
col. 27, lines 18-36, “An SMP broker component of device 112 may be configured to manage secure communication authentication with device 110 (e.g., secure element 230 of device 100). An operating system or other application of device 110 may be configured to call specific application programming interfaces (“APIs”) and an SMP broker component may be configured to process requests of those APIs and respond with data that may derive the user interface of device 100 and/or respond with application protocol data units (“APDUs”) that may communicate with secure element 230 of device 110 (e.g., via a communication path between device 112 and device 110).
a first memory storing authentication data for authenticating a software image;
Claim 16: a first memory storing authentication data for authenticating software images;
a second memory storing personalization data of the software image.
Claim 16: a second memory storing credentials for personalizing software images.
Claim 27: An update agent for use in a secure element, comprising: a first memory for storing authentication data for authenticating software images;
Claim 16: A secure element, SE, comprising an update agent, a first memory storing authentication data for authenticating software images;
a second memory for storing personalization data of software images.
Claim 16: a second memory storing credentials for personalizing software images.
Claims 22 is provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 16 of copending Application No. 18/292398 in view of Sibert et al. (US 10936719). Although the claims at issue are not identical, they are not patentably distinct from each other because claim 22 of the instant application are an obvious combination of patent claim 16 and Sibert in that the patent claims in combination with Sibert contain all the limitations of the instant application.
Sibert is cited to teach a similar concept of secure loading of firmware into a system. Sibert teaches using decryption and authentication to securely download updated firmware. Based on Sifert, it would have been obvious before the effective filing date of the invention to a person having ordinary skill in the art to which said subject matter pertains to have modified Application 18292542 claim 22 to use decryption and authentication to securely download updated firmware. Furthermore, being able to use decrypt and authenticate when downloading updated firmware improves on Application 18292542 claim 22 by being able securely download the firmware. To one of ordinary skill in the art before the effective filing data of the invention it would have been advantageous to make this modification where “Execution of one or more preflight scripts of an update package at operation 304 may include any suitable operations, including, but not limited to, verifying or otherwise decrypting any portion of the received update package (e.g., using any suitable decryption key)”, (col. 14, lines 55-62) to provide security to the system.
Claims 23 is provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 17 of copending Application No. 18/292398 in view of Sibert et al. (US 10936719). Although the claims at issue are not identical, they are not patentably distinct from each other because claim 23 of the instant application are an obvious combination of patent claim 17 and Sibert in that the patent claims in combination with Sibert contain all the limitations of the instant application.
Claims 24 is provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 21 of copending Application No. 18/292398 in view of Sibert et al. (US 10936719). Although the claims at issue are not identical, they are not patentably distinct from each other because claim 24 of the instant application are an obvious combination of patent claim 21 and Sibert in that the patent claims in combination with Sibert contain all the limitations of the instant application.
This is a provisional nonstatutory double patenting rejection.
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.
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 is configured to perform” in claim 23,
“the update agent is configured to decrypt” in claim 24,
“the secure element is configured to instruct” in claim 25,
“the secure element is configured to retrieve” in claim 26,
“the update agent is configured to perform” in claim 28,
“the SE to perform” in claim 29,
“the SE to obtain” in claim 29,
“instructions for receiving” in claim 30,
“instructions for authenticating and/or decrypting” in claim 30,
“instructions for personalizing” in claim 30,
“instructions for installing” in claim 30.
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 § 102
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 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.
Claim(s) 16-30 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Sibert et al. (US 10936719).
Regarding claim 16, Sibert teaches
A method for loading and personalizing a software, including an operating system, OS, (Fig. 2 (232 – operating system)) in a secure element, SE, (Fig. 2 (230 – secure element))) the method comprising:
loading an update agent (Fig. 2 (234 – updating operating system)) into the SE; (col. 11, lines 17-29, “Alternatively or additionally, one or more of the aforementioned operations that may be performed by main SE operating system 232 may be performed by an updating SE operating system 234 (e.g., a high-end boot loader) that may be executed by the processor (e.g., SE processor 231 or any other suitable processor, which may be specifically associated with or uniquely used by updating SE operating system 234) in secure element 230. Updating SE operating system 234 may be separate from main SE operating system 232, which may perform other functions of secure element 230. Updating SE operating system 234 may update portions of main SE operating system 232 and/or software associated with one or more of applets 236.”)
loading software personalization data into the SE; (col. 4, lines 10-36, “In addition, in some embodiments, a user of electronic device 110 may have previously customized or personalized the previous version with user data and/or device 110 may have previously automatically generated other trusted data for the previous version. For example, various types of SE OS trust data (“trust data”) may be associated with a secure element operating system (“SE OS”), including, but not limited to, core OS trust data and user OS trust data. Core OS trust data (“core OS data”) of an SE OS may be any suitable data relevant for the security of a system built around the SE, including, but not limited to, data that may facilitate pairing the SE to a secure enclave processor (“SEP”), data that may facilitate secure provisioning of applets on the SE, data that may facilitate secure provisioning of service provider (“SP”) keys on the SE, data that may facilitate secure signing of any suitable SE information (e.g., serial number, platform identifier, etc.), and/or the like. Core OS data may be data that is essential for the viability of the SE OS. Core OS data may include any SE OS data that may be necessary to manage lifecycle data (e.g., credential lifecycle/production state data), secrets data (e.g., key mask data), applet data (e.g., package/applet/security domain registry data and/or security domain data (e.g., instances, native structures, key objects, certificates, applet migration data, etc.)), user trust data (e.g., personalization data), communication data (e.g., contactless parameters), and/or any other suitable data.”)
storing the software personalization data in the update agent; (col. 11, lines 41-47, “Next, updating SE operating system 234 may uninstall the at least one previous (e.g., currently existing) version of main SE operating system 232, and may export any suitable OS trust data (e.g., core OS trust data and/or user OS trust data) that may be associated with the at least one previous version of the main SE operating system 232.” And col. 4, lines 10-36, “In addition, in some embodiments, a user of electronic device 110 may have previously customized or personalized the previous version with user data and/or device 110 may have previously automatically generated other trusted data for the previous version. For example, various types of SE OS trust data (“trust data”) may be associated with a secure element operating system (“SE OS”), including, but not limited to, core OS trust data and user OS trust data. Core OS trust data (“core OS data”) of an SE OS may be any suitable data relevant for the security of a system built around the SE, including, but not limited to, data that may facilitate pairing the SE to a secure enclave processor (“SEP”), data that may facilitate secure provisioning of applets on the SE, data that may facilitate secure provisioning of service provider (“SP”) keys on the SE, data that may facilitate secure signing of any suitable SE information (e.g., serial number, platform identifier, etc.), and/or the like. Core OS data may be data that is essential for the viability of the SE OS. Core OS data may include any SE OS data that may be necessary to manage lifecycle data (e.g., credential lifecycle/production state data), secrets data (e.g., key mask data), applet data (e.g., package/applet/security domain registry data and/or security domain data (e.g., instances, native structures, key objects, certificates, applet migration data, etc.)), user trust data (e.g., personalization data), communication data (e.g., contactless parameters), and/or any other suitable data.”)
loading a software image into the SE; and (col. 11, lines 47-49, “ Furthermore, updating SE operating system 234 may install the update to the main SE operating system (e.g., the new main SE operating system 232)”)
personalizing the loaded software image using the software personalization data.(col. 11, lines 49-52, “may personalize the main SE operating system using at least a portion of any of the OS trust data that may have been exported.”)
Regarding claim 17, Sibert teaches wherein the software personalization data is loaded together with the update agent into the SE during a production phase of the SE, and stored in a memory of the update agent. (col. 4 lines 10-38 and lines 48-53, “a user of electronic device 110 may have previously customized or personalized the previous version with user data and/or device 110 may have previously automatically generated other trusted data for the previous version. For example, various types of SE OS trust data (“trust data”) may be associated with a secure element operating system (“SE OS”), including, but not limited to, core OS trust data and user OS trust data. … user trust data (e.g., personalization data), communication data (e.g., contactless parameters), and/or any other suitable data. Such core OS data may be stored in any suitable memory area of the secure element, … User OS trust data (“user OS data”) of an SE OS may be any suitable data relevant to a specific user of the SE, including, but not limited to, personalization data and keys, such as secure channel keys for SPs, SP certificates, and any other security relevant data” and col. 26, lines 66 – col. 27, lines 46, “Other device 112 of FIG. 1 may be any suitable device that may be controlled or otherwise managed by any suitable entity, such as a commercial entity subsystem, such as a manufacturer of electronic device 110 … Although not shown, device 112 of FIG. 1 may be a secure platform system and may include a secure mobile platform (“SMP”) broker component, an SMP trusted services manager (“TSM”) component, an SMP crypto services component, an identity management system (“IDMS”) component, a fraud system component, a hardware security module (“HSM”) component (e.g., a factory HSM) … An SMP TSM component of device 112 may be configured to use an HSM component to protect its keys and generate new keys. An SMP crypto services component of device 112 may be configured to provide key management and cryptography operations that may be required for user authentication and/or confidential data transmission between various components of system 100. Such an SMP crypto services component may utilize an HSM component of device 112 for secure key storage and/or opaque cryptographic operations.”)
Regarding claim 18, Sibert teaches wherein the software personalization data comprises secure credentials, including a set of cryptographic keys. (col. 4, lines 28-36, “Core OS data may include any SE OS data that may be necessary to manage lifecycle data (e.g., credential lifecycle/production state data), secrets data (e.g., key mask data), applet data (e.g., package/applet/security domain registry data and/or security domain data (e.g., instances, native structures, key objects, certificates, applet migration data, etc.)), user trust data (e.g., personalization data), communication data (e.g., contactless parameters), and/or any other suitable data.” And (col. 27, lines 36-45, “An SMP TSM component of device 112 may be configured to use an HSM component to protect its keys and generate new keys. An SMP crypto services component of device 112 may be configured to provide key management and cryptography operations that may be required for user authentication and/or confidential data transmission between various components of system 100. Such an SMP crypto services component may utilize an HSM component of device 112 for secure key storage”)
Regarding claim 19, Sibert teaches wherein the software image is loaded into the SE in a subsequent phase after a production phase of the SE. (Fig. 3 and col. 14, col. 14, lines 33-46, “updating at least one asset (e.g., an applet and/or an operating system) installed on an electronic device (e.g., electronic device 110 in FIG. 1), which may be performed by a processor in a secure element in the electronic device (e.g., processor 231 of secure element 230). For example, the processor may execute a program module that may include instructions for operations in process 300. During operation 302, the processor may receive, from an updating device, an update package that may have a digital signature, where the update package may include an update to the asset installed on the secure element. For example, at operation 302, update package 233 may be received by secure element 230, where processor 231 (e.g., in conjunction with updating OS 234) may be operative to process received update package 233.”)
Regarding claim 20, Sibert teaches wherein the update agent comprises a further memory for storing authentication data for authenticating a software image, wherein the method comprises further performing authentication and/or decryption of the software image using authentication data stored in the further memory. (col. 14, lines 55 – col. 15, line 1, “Execution of one or more preflight scripts of an update package at operation 304 may include any suitable operations, including, but not limited to, verifying or otherwise decrypting any portion of the received update package (e.g., using any suitable decryption key), identifying at least one other version (e.g., previously loaded version) of a current/source secure element asset to be updated by the package (e.g., identify SE OS 232 in response to receiving package 233 with new SE OS 233c), exporting any trust data from each identified current secure element asset (e.g., obtaining, serializing, and/or exporting any suitable OS trust data of SE OS 232 for preservation purposes during an SE OS update), and uninstalling each identified current secure element asset”)
Regarding claim 21, Sibert teaches further comprising, obtaining the software personalization data from the update agent through an Application Programming Interface, API. (col. 27, lines 18-36, “An SMP broker component of device 112 may be configured to manage secure communication authentication with device 110 (e.g., secure element 230 of device 100). An operating system or other application of device 110 may be configured to call specific application programming interfaces (“APIs”) and an SMP broker component may be configured to process requests of those APIs and respond with data that may derive the user interface of device 100 and/or respond with application protocol data units (“APDUs”) that may communicate with secure element 230 of device 110 (e.g., via a communication path between device 112 and device 110). An SMP TSM component of device 112 may be configured to provide GlobalPlatform-based services that may be used to carry out operations on device 110. GlobalPlatform, or any other suitable secure channel protocol, may enable such an SMP TSM component to properly communicate and/or provision sensitive account data between secure element 230 of device 110 and a TSM for secure data communication.”)
Regarding claim 22, Sibert teaches
A secure element, SE, comprising an update agent and an operating system, OS,wherein the update agent and the operating system are configured to communicate with each other through an Application Programming Interface, API, wherein the update agent comprises:
a first memory storing authentication data for authenticating a software image; and (col. 12, lines 11-18 and 26-33, “New SE OS 233c may include or otherwise be associated with a manifest 233d that may include any suitable data, such as an encoded structure with a signature and public key inserted with one or more fields in clear text but with a capability of encrypting certain fields, where the data fields may include tags that may contain measurement data attesting to one or more image(s) of new SE OS 233c. … SE memory 235 may be any suitable memory or combinations of different types of memories that may be operative to at least temporarily hold some or all data of secure subsystem 218, such as non-volatile memory (“NVM”) or flash memory, permanent memory such as read-only memory (“ROM”), semi-permanent memory such as random access memory (“RAM”), any other suitable type of storage component, or any combination thereof.” And col. 11, lines 29-41, “when update package 233 may be configured for updating an operating system type secure element asset, updating SE operating system 234 may verify a digital signature of such an update package 233 using an encryption key that may be associated with a vendor of secure element 230 (e.g., a key associated with ISD 237) or the vendor of the secure element operating system. In some embodiments, updating SE operating system 234 may decrypt update package 233 using a second encryption key that may be associated with the vendor of secure element 230 or the vendor of the secure element operating system. This second encryption key may be the same as or different from the encryption key.”)
a second memory storing personalization data of the software image. (col. 3, lines 2-17, “Each SE OS may be associated with a data format version such that, when the source and target SE OSs have different data format versions, the difference may be identified by the secure element of the device (e.g., a bootloader of the secure element) and a migration operating system (“MOS”) associated with the target SE OS may then be utilized to migrate the trust data from the source SE OS to a format that may be imported into the target SE OS. A portion of memory of the secure element of the device may be made available by replacing the source SE OS with the smaller MOS and then that memory portion may be used to temporarily hold a transformed copy of the trust data prior to replacing the original trust data with that transformed trust data in another portion of the memory, such that any interruption to the process may not result in any loss of any trust data.” col. 11, 44-52, “may export any suitable OS trust data (e.g., core OS trust data and/or user OS trust data) that may be associated with the at least one previous version of the main SE operating system 232. Furthermore, updating SE operating system 234 may install the update to the main SE operating system (e.g., the new main SE operating system 232), and may personalize the main SE operating system using at least a portion of any of the OS trust data that may have been exported.”, col. 19, lines 53-59, “DSM and/or DCM migration operations by loaded MOS 233b may be carried out that may include MOS 233b transforming certain ones or each object of core OS trust data and/or of user OS trust data. Each transformed object may be stored in a temporary SE OS code area of a portion of SE memory 235 (e.g., as shown with respect to FIG. 8).”, col. 20, lines 1-10, “One or various portions of SE memory 235 may be resized by secure element 230, and/or native variables and/or other suitable data may be added, modified, and/or deleted by secure element 230 if necessary or appropriate or desired. Then, each transformed object from the temporary SE OS code area portion of SE memory 235 may be copied back into the original object data portion of SE memory 235, such as in place of the object data that has since been transformed (e.g., as shown with respect to FIG. 8)” And
Regarding claim 23, Sibert teaches wherein the update agent is configured upon receiving the software image, to perform authentication of the software image using the authentication data stored in the first memory of the update agent. (col. 4, line 65 – col. 5, line 1, “the secure element may authenticate the update package by verifying a digital signature, which may be associated with a vendor of the secure element or a trusted partner of device 110. Alternatively, the digital signature may be associated with a provider of electronic device 110 or a secure element asset installed on a secure element in electronic device 110.”)
Regarding claim 24, Sibert teaches wherein the update agent is configured upon receiving the software image, to decrypt the software image using the authentication data stored in the first memory of the update agent. (col. 5, lines 7-16, “ the secure element may decrypt the update package using a second encryption key, which may be the same or different from the encryption key. In an exemplary embodiment, a public-private encryption-key technique may be used. In particular, an update package may be signed using a private encryption key of the vendor, and the digital signature may be verified and/or the update package may be decrypted using the public encryption key of the vendor.”)
Regarding claim 25, Sibert teaches wherein the secure element is configured to instruct the operating system to retrieve the personalization data stored in the second memory of the update agent, to perform personalization of the software image using the personalization data, and to store the personalized software image in a memory of the SE. (col. 11, 40-54, “This second encryption key may be the same as or different from the encryption key. Next, updating SE operating system 234 may uninstall the at least one previous (e.g., currently existing) version of main SE operating system 232,may export any suitable OS trust data (e.g., core OS trust data and/or user OS trust data) that may be associated with the at least one previous version of the main SE operating system 232. Furthermore, updating SE operating system 234 may install the update to the main SE operating system (e.g., the new main SE operating system 232), and may personalize the main SE operating system using at least a portion of any of the OS trust data that may have been exported.”)
Regarding claim 26, Sibert teaches wherein the secure element is configured to retrieve the personalization data by instructing the OS to perform a data recovery procedure with the update agent through the API. (col. 27, lines 18-36, “An SMP broker component of device 112 may be configured to manage secure communication authentication with device 110 (e.g., secure element 230 of device 100). An operating system or other application of device 110 may be configured to call specific application programming interfaces (“APIs”) and an SMP broker component may be configured to process requests of those APIs and respond with data that may derive the user interface of device 100 and/or respond with application protocol data units (“APDUs”) that may communicate with secure element 230 of device 110 (e.g., via a communication path between device 112 and device 110). An SMP TSM component of device 112 may be configured to provide GlobalPlatform-based services that may be used to carry out operations on device 110. GlobalPlatform, or any other suitable secure channel protocol, may enable such an SMP TSM component to properly communicate and/or provision sensitive account data between secure element 230 of device 110 and a TSM for secure data communication.” And col. 18, lines 64 -col. 19, line 1, “Process 300 may be operative to enable a factory reset, which may restore the initial factory settings of secure element 230 with the initial SE OS (e.g., as may have been initially defined and provisioned on secure element 230 by a manufacturer of secure element 230)”)
As to claims 29-30, Sibert teaches these claims according to the reasoning provided in claims 16 and 20.
As to claim 27, Sibert teaches these claims according to the reasoning provided in claim 22.
As to claim 28, Sibert teaches these claims according to the reasoning provided in claims 23 or 24 and 26.
Response to Arguments
Applicant's arguments filed 11/05/2025 have been fully considered but they are not persuasive. The Applicant’s representative argues that Sibert does not teach an updating agent or personalization data as defined by the applicant’s specification, loading an update agent, loading personalization data into the SE, storing the personalization data into the SE, and personalizing OS using the data stored in the agent. The Examiner respectfully disagrees.
In regard to the first argument that Sibert does not teach an updating agent or personalization data as defined by the applicant’s specification, as pointed out by the Applicant’s representative Siebert’s updating agent is an updating SE operating system and personalization data is personalized OS trust data. The Applicant’s representative then suggests that the architectures and operations are materially different. The Applicant has used very broad terms and has not added any limitations related to the architecture of the system/update agent. Based on the broadest reasonable interpretation, Siebert’s updating SE operating system 234 component and memory 235 updates the operating system and therefore may be interpreted as “an update agent”. Additionally, the personalization data is also not defined in the claim limitations other than the data is personalized. Based on broadest reasonable interpretation, “customized or personalized … user data”, col. 4, lines 11-12 of Sibert may be interpreted as the personalized data in the claim limitations. Therefore, the Applicant’s arguments are not persuasive.
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., the structure of the update agent and specifics of what personalization data means) 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).
Regarding the second argument, loading an update agent, loading personalization data into the SE, storing the personalization data into the SE and in the update agent, and personalizing OS using the data stored in the agent. The Applicant’s representative argues that Sibert does not load the updating SE operating system 234 because “it’s already installed”. The claim limitations to not require anything more than “loading an update agent” (i.e. there is no point in time where the update agent must be installed according to the claim limitations). It must just be loaded at any point in time which even the Applicant’s representative admits has happened. So the argument is not persuasive. Additionally, the Applicant’s representative argues that Sibert does not teach the personalizing the data for the new OS. Sibert teaches this limitation as recited by “updating SE operating system 234 may uninstall the at least one previous (e.g., currently existing) version of main SE operating system 232, and may export any suitable OS trust data (e.g., core OS trust data and/or user OS trust data) that may be associated with the at least one previous version of the main SE operating system 232. Furthermore, updating SE operating system 234 may install the update to the main SE operating system (e.g., the new main SE operating system 232), and may personalize the main SE operating system using at least a portion of any of the OS trust data that may have been exported.” col. 11, lines 41-52. Clearly, the “update agent”/SE operating system 234 personalizes the date for the new main OS 232. Finally, the Applicants representative argues that Sibert does not teach the storing of personalization data in an update agent. As recited in Fig. 3, col. 4, lines 30-38, “Core OS data may include any SE OS data that may be necessary to manage lifecycle data … user trust data (e.g., personalization data), …core OS data may be stored in any suitable memory area” and additionally in col. 17, lines 58-62, “updating SE operating system 234 of secure element 230 may be utilized as the primary control of process 300 (e.g., as a bootloader in conjunction with processor 231 and memory 235 of secure element 230”. In other words, the personalized data is stored in the update agent (i.e. updating SE OS and memory). Based on this information, the personalized data is stored in a memory of the update agent. None of the Applicant’s arguments are persuasive and the rejection is maintained.
Conclusion
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 CHERI L. HARRINGTON whose telephone number is (571)270-0468. The examiner can normally be reached Generally, M-F, 7:30a-4p.
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, Jaweed Abbaszadeh can be reached at 571-270-1640. 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.
/CHERI L HARRINGTON/Examiner, Art Unit 2176 February 10, 2026
/JAWEED A ABBASZADEH/Supervisory Patent Examiner, Art Unit 2176