DETAILED ACTION
This communication is in response to Application No. 18/690,353 filed on 3/8/2024. The amendment presented on 5/4/2026, which amends claims 1 and 4-9, is hereby acknowledged. Claims 1-9 have been examined.
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 .
Claim Objections
The amendment presented on 5/4/2026 providing change to the claims is noted. All prior objections to the claims are hereby withdrawn.
Response to Arguments
Applicant’s arguments with respect to claims 1-9 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1 and 5-9 are rejected under 35 U.S.C. 103 as being unpatentable over Chastain et al. (hereinafter Chastain)(US 2015/0127938) in view Uy et al. (hereinafter Uy)(US 2016/0157092), and further in view of Shah et al. (hereinafter Shah)(US 2022/0141644).
Regarding claim 1, Chastain teaches as follows:
A method for updating a secure element cooperating with a telecommunication terminal in a telecommunication network, said updating being performed by an Over The Air (OTA) server (the process can commence with the OTA server forwarding an OTA message to the N-OIF for transmission to the UICC of the mobile device (equivalent to applicant’s secure element). This can be part of a group provisioning effort, such as a software update that is to be distributed to a group of mobile devices, see, ¶ [0035] and figure 5A), said method comprising:
Sending from said OTA server to said secure element a trigger of polling message through a Lightweight Machine-to-Machine (LwM2M) channel, in order to ask to said secure element to establish a secure Hyper Text Transfer Protocol (HTTPS) channel with said OTA server, said OTA server updating said secure element through said https channel after establishment of said https channel (at 2a, the OTA server can prepare a message for delivery to the UICC and sends it to the N-OIF. The OTA server may encrypt the message using an OTA server keyset. At 2b, the N-OIF can prepare the message for transmission to the U-OIF. This may involve the following: verifying that the UICC is registered and reachable via HTTP; converting the message protocol to HTTP; and/or encryption using an OTA IWF Keyset. At 2c, the U-OIF can receive the message… At 2h, the UICC terminating entity can receive the message and can perform actions based on the content of the message (e.g., adjusting configuration parameters, executing software updates, storing settings, and so forth), see, ¶ [0035] and figure 5A and 5B).
Chastain does not explicitly teach sending a trigger of polling message in order for the secure element to establish a HTTPS channel.
Uy teaches as follows:
The update trigger message (equivalent to applicant’s trigger of polling message) of step 301 is received in the transceiver 108 of the mobile device 13, and is processed by the baseband processor of the transceiver 108. As part of the processing the baseband processor identifies the received message as an update trigger destined for the UICC 14, and forwards the update trigger to the UICC 14 (equivalent to applicant’s secure element) in step 303 (see, ¶ [0032] and figure 3); and
in step 307, the UICC initiates establishment of a BIP link through the baseband processor with the UICC update server 30. Specifically, in step 309, the UICC 14 instructs the baseband processor to establish a BIP link, and a BIP communication link is established through network 15 with the UICC update server 30 in step 311. The UICC update is received from the UICC update server 30 by the mobile communication device 13 across the BIP link in step 313, and is forwarded to the UICC 14 for storage in the UICC 14 (see, ¶ [0033] and figure 3).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify Chastain with Uy to include sending update trigger message as taught by Uy in order for the UICC (secure element) to initiate establishment of a link for UICC update.
Chastain in view of Uy teaches all limitations as presented above except for the LwM2M channel between the OTA server and the secure element nor the well-known HTTPS.
Shah teaches as follows:
A remote SIM provisioning object may include information indicating a SIM profile update protocol supported by a LwM2M client computing device, such as a IoT device. SIM profile update protocols may be communication protocols a LwM2M client computing device, such as a IoT device, is configured to use to retrieve a SIM profile package. Examples of SIM profile update protocols may include the Constrained Application Protocol (CoAP), the secured-CoAP (CoAPs), Hypertext Transfer Protocol (HTTP) 1.1, HTTP Secure (HTTPS) 1.1, or any other suitable communication protocol (see, ¶ [0061]);
the IoT device 302 and the server 304 may be configured to communicate using one or more communication protocols, such as the User Datagram Protocol (UDP), Short Message Service (SMS), Internet Protocol (IP) protocols, Non-IP protocols, Transmission Control Protocol (TCP), etc. As an example, the IoT device 302 may be an LwM2M client computing device. As an example, the server 304 may be an LwM2M server (see, ¶ [0099] and figure 3A)(any communication using one or more communication protocols between the LwM2M client and the LwM2M server is equivalent to applicant’s LwM2M channel); and
the IoT device 302 may be configured with an LwM2M client 302a that uses the LwM2M device management protocol. The LwM2M device management protocol defines an extensible resource and data model. The LwM2M client 302a may employ a service-layer transfer protocol such as CoAP 302b and/or HTTP 302d to enable, among other things secure data transfer (see, ¶ [0100] and figure 3A).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify Chastain in view of Uy with Shah to include the LwM2M communication channel as taught by Shah in order to efficiently support M2M communications for IoT devices.
Regarding claims 5 and 8, Chastain in view of Uy and Shah teaches similar limitations as presented above, and further teaches as follows:
The OTA server and the secure element having a processor (the communication device 800 shown in FIG. 8 or portions thereof can serve as a representation of one or more of the devices of FIGS. 1-5 and 7 including end user devices (equivalent to applicant’s secure element), customer premises equipment, remote management servers, interworking functions, and/or OTA servers. The controller 806 (equivalent to applicant’s processor) can perform the functions 762 and/or 766, see, ¶ [0069] and figure 8).
Regarding claims 6-7 and 9, Chastain in view of Uy and Shah teaches similar limitations as presented above, Shah further teaches as follows:
The LwM2M server and the LwM2M client (the IoT device 302 may be configured with an LwM2M client 302a that uses the LwM2M device management protocol. The LwM2M device management protocol defines an extensible resource and data model. The LwM2M client 302a may employ a service-layer transfer protocol such as CoAP 302b and/or HTTP 302d to enable, among other things secure data transfer (see, ¶ [0100] and figure 3A).
Therefore, they are rejected for similar reason as presented above.
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Chastain et al. (hereinafter Chastain)(US 2015/0127938) in view of Uy et al. (hereinafter Uy)(US 2016/0157092) and Shah et al. (hereinafter Shah)(US 2022/0141644), and further in view of Loreskar et al. (hereinafter Loreskar)(US 2022/0210652).
Regarding claim 2, Chastain in view of Uy and Shah teaches all limitations as presented above except for the counter.
Loreskar teaches as follows:
The two entities at the two ends of the first secure channel and/or the two entities at the ends of the second secure channel each maintain a counter which is monotonically incremented upon exchange of messages, wherein sent messages include a value derived from the sending entity's counter, and wherein the receiving end entity only accepts as valid messages with the value derived from a counter value higher than the receiving end's current counter value. Thereby, security can be enhanced by providing for replay protection (see, ¶ [0036]).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify Chastain in view of Uy and Shah with Loreskar to include the counter incrementing upon exchange of messages as taught by Loreskar in order to efficiently enhance security.
Claims 3-4 are rejected under 35 U.S.C. 103 as being unpatentable over Chastain et al. (hereinafter Chastain)(US 2015/0127938) in view of Uy et al. (hereinafter Uy)(US 2016/0157092) and Shah et al. (hereinafter Shah)(US 2022/0141644), and further in view of Chun et al. (hereinafter Chun)(US 2020/0175867).
Regarding claims 3-4, Chastain teaches as follows:
At 2a, the OTA server can prepare a message for delivery to the UICC and sends it to the N-OIF. The OTA server may encrypt the message using an OTA server keyset (see, ¶ [0035] and figure 5A-B).
Chastain in view of Uy and Shah teaches all limitations as presented above except for using ICCID as keyset for encryption.
Chun teaches as follows:
The vehicle 210 may encrypt the authentication number using the internal information of the vehicle 210 such as VIN, ICCID, and IMEI as a key and may transmit the encrypted authentication number to the server 220 (see, ¶ [0062] and figure 2).
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to modify Chastain in view of Uy and Shah with Chun to include using the ICCID as key for encryption as taught by Chun in order to efficiently personalize (diversify) message for recipients with unique identifier.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Jeong S Park whose telephone number is (571)270-1597. The examiner can normally be reached Monday through Friday 8:00-4:30 ET.
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, Rebecca E Song can be reached at 571-270-3667. 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.
/JEONG S PARK/Primary Examiner, Art Unit 2417
July 7, 2026
Prosecution Insights