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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 04/17/2026 has been considered by the examiner.
Response to Amendment
Applicant’s remarks have been given full consideration, as such this Office Action has been modified in view of Amendments filed on 05/22/2026.
Response to Arguments
Applicant's arguments filed "Remarks" on 05/22/2026 have been fully considered but they are not persuasive.
Applicant alleges that: Regarding independent claim 1, “Kang fail to teach or suggest generating any message to be transmitted to a server, much less one that could be argued to be similar to the recited "begin-pair message to pair an [eUICC] and a baseband [SEP] of a device," as recited in claim 1” and “the procedure relied upon in Kang is not even related to pairing an eUICC with a baseband SEP, nor does it include messages to and from a server such as those recited in claim 1”. However, Kang teaches the ability to activate, activate read as pair, an eUICC profile from [0079] “the LPA 1a-15 may obtain a user's input for local management of a profile by configuring a UI or may receive a remote management instruction through the SM-DP+ 1a-70 from an SM-DP+ server 1a-70, may obtain an input from the user 1a-01 by configuring a UI for the instruction, and may then transmit a management command for the profile to the ISD-R 1a-65 of the eUICC 1a-50, thereby activating/deactivating/deleting/updating the profile,” i.e. activating an eUICC with a user profile, beginning from a command from the user’s input transmitted to the LPA, which forwards the message to the SM-DP+ server (the process is also possible to be performed in reverse, i.e. command originating from the server/LPA). Furthermore, [0171] describes “referring to FIG. 8, a terminal 1h-25 may have a secure element (SE, e.g., a UICC) 1h-01,” i.e. a secure element such as a secure enclave processor is included within the terminal and therefore would also be paired/activated. In addition to Kang teaching this limitation, Li also teaches [0027] “the eUICC and the embedded secure element and/or the trusted execution environment are paired with symmetric keys and/or certificates after manufacture of the mobile device, such as using verification via an external L3 sever and key/certificate injection to the mobile device,” i.e. pairing an eUICC with the embedded secure element (which may be a SEP, see FIG. 3 310, and [0042]) in association with a server.
Applicant alleges that: Regarding independent claim 10, “there is no teaching that the ATR of Kang includes an indication of a pairing capability of the UICC or an indication that the UICC is unpaired”. However, Kang teaches as such “([0124] the UICC 1e-05 may transmit an answer to reset (ATR) to the terminal 1e-01, depicted in FIG. 5, and [0124-0125] describes how the response APDU from the UICC 1f-05 to terminal 1f-01 may include information such as having a pending proactive command or other indicators, i.e. such as to pair if unpaired)” as described in the office action, see claim 10. Kang also teaches [0121] “notified via one of an Answer to Reset (ATR), a returned value for a terminal capability command APDU transmitted from the terminal,” i.e. the ATR may include capability information of the terminal. [0112] describes “the terminal may report information indicating the capability of the terminal as Command APDU <INS=Terminal Profile>,” i.e. the ATR and response APDU may include capability information, which includes the state of the terminal profiles, which would include activated or deactivated (paired or unpaired) states.
Applicant alleges that: Regarding independent claim 10, “there is nothing in Kang that describes the UICC generating the random key that is transmitted to the baseband processor” and “there is nothing in this paragraph or elsewhere in Kang that describes the UICC generating a random key as part of a pairing process performed with the baseband circuitry as described with respect to claim 10”. Kang teaches the ability to use authentication keys in association with the eUICC, see [0053], [0057], [0062], and [0083], but Examiner partially agrees with applicant and has modified the rejection accordingly, please see claim 10. Li teaches [0027] “the eUICC and the embedded secure element and/or the trusted execution environment are paired with symmetric keys and/or certificates after manufacture of the mobile device, such as using verification via an external L3 sever and key/certificate injection to the mobile device,” i.e. pairing an eUICC with the embedded secure element (embedded secure element may be a SEP, see FIG. 3 310, and [0042]) via a generated random key, also described in claim 10.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-2, and 6-20 are rejected under 35 U.S.C. 103 as being unpatentable over KANG et al. (US 2022/0360968 A1, hereinafter Kang) in view of LI et al. (US 2016/0277930 A1, hereinafter Li).
Regarding claim 1, Kang teaches a method comprising: generating a begin-pair message to be transmitted to a server ([0106-0107] FIG. 4 depicts the LPA 1d-05 may receive a request for a state change of a profile installed in the eUICC from a terminal user 1d-01 (1d-20), and the LPA 1d-05 may transmit an ES10c.command to the eUICC 1d-10, the ES10c.command may be, for example, one of messages, such as ES10c.enableProfile, ES10c.disableProfile, and ES1c.euiccMemoryReset, i.e. the ES10c.command may be a begin-pair message and may be transmitted via the LPA 1d-05, and depicted in FIG. 1 the terminal may be connected directly to the SM-DP+ server (1a-70), i.e. a begin-pair message between the eUICC, LPA and the terminal will be further transmitted to a server, and FIG. 5-7 depict an initial message transmitted between the terminal and eUICC, i.e. a begin-pair message), the begin-pair message to pair an embedded universal integrated circuit card (eUICC) and a baseband processor of a device ([0079] the LPA 1a-15 may obtain a user's input for local management of a profile by configuring a UI or may receive a remote management instruction through the SM-DP+ 1a-70 from an SM-DP+ server 1a-70, and may obtain an input from the user 1a-01 by configuring a UI for the instruction, and may then transmit a management command for the profile to the ISD-R 1a-65 of the eUICC 1a-50, thereby activating/deactivating/deleting/updating the profile and other functions are performed by an instruction transmitted from the SM-DP+ 1a-70 to the terminal, and when receiving a local profile management command via the LPA 1a-15 or a remote profile management command via the SM-DP+ 1a-70, the eUICC 1a-50 may transmit predetermined information notifying a communication modem 1a-25 that the state of a profile has been changed in a process of processing the profile management command, i.e. a begin-pair message to connect the eUICC with a [0080-0081] baseband processor of a device); processing an authentication request received from the server ([0010-0011] enables the use of secure mobile communication via subscriber authentication and traffic security key generation and [0083] the UICC may be requested to provide verifying authentication information) and generating, based on the authentication request, a local profile assistant (LPA)- -request to be transmitted to the eUICC, the LPA- -request- ([0070] describes “eUICC to register a proactive command by receiving a command involving a profile state change from an LPA,” and [0079] describes “the LPA 1a-15 is an application in charge of eUICC control and manages a profile while communicating with an SM-DP+ 1a-70, a terminal user 1a-01, and an ISD-R 1a-65 in the eUICC 1a-50,” i.e. any activation/deactivation commands/requests for the eUICC (which may include authentication requests, see [0053]) come from commands directly associated with the LPA in communication with the server).
Kang differs from the claimed invention and does not specifically teach -secure- enclave processor (SEP)- the authentication request including a hardware security module (HSM) challenge for the baseband SEP and an HSM challenge for the eUICC; generating, based on the authentication request, a generate-attestation message to be transmitted to the baseband SEP, the generate- attestation message including the HSM challenge for the baseband SEP; and receiving, from the SEP, a SEP attestation signed by a SEP-specific key pair, the SEP attestation conveying a SEP certificate; -signing- and -including the HSM challenge for the eUICC. However, Li teaches [abstract] methods for user authentication and human intent verification of administrative operations for eSIMs of an eUICC included in a mobile device such as import, modification, and/or export, of an eSIM and/or for an eUICCs firmware update. Li also teaches -secure- enclave processor (SEP)-([0042] the eUICC authentication 304 means can include a hardware-based embedded Secure Element (eSE) 118 (which can also be referred to as a Secure Enclave Processor or SEP, in some embodiments) that includes a secure connection to one or more of the human verification 302) the authentication request including a hardware security module (HSM) challenge for the baseband SEP and an HSM challenge for the eUICC; ([0047] describes “the HSM certificate (HSMcert) can be obtained from the HSM 502 by the AP 506 with a signed Challenge. The AP 506 can retrieve a Card Serial Number (CSN) from the eUICC 108 and provide the signed challenge, the HSM certificate, and the CSN to the eSE 118. The eSE 118 can validate the HSM certificate, verify the HSM signature, and subsequently generate a key pair based on a unique identifier (UID) for the mobile device 102 and the CSN. The eSE 118 can generate a certificate signing request (CSR) and a common name (CN), which can be associated with the eSE 118 and the CSN combination,” i.e. an authentication request between the eSE 118, eSE read as SEP see FIG. 3 310 and [0042], and the eUICC 108 of the mobile device 102. This authentication request includes an HSM challenge between the eUICC and SEP) generating, based on the authentication request, a generate-attestation message to be transmitted to- ([0042] the eUICC authentication 304 means can include a hardware-based embedded Secure Element (eSE) 118 (which can also be referred to as a Secure Enclave Processor or SEP, in some embodiments) that includes a secure connection to one or more of the human verification 302 means and a secure connection to the eUICC 108 of the mobile device 102, and FIG. 9A steps 902, 904, and 906 describes generating authentication messages to be transmitted between the server and the SEP on the device) -the baseband SEP, the generate- attestation message including the HSM challenge for the baseband SEP (as described above the HSM challenge is transmitted between the eUICC and SEP, see [0047]); and receiving, from the baseband SEP, a SEP attestation signed by a SEP-specific key pair ([0047] FIGS. 5A and 5B illustrate a sequence diagram 500/550 for pairing an embedded secure element, the eUICC verifies its authorization via the SEP transmitting/receiving a signed key to the server), the SEP attestation conveying a SEP certificate ([0026-0027] the embedded secure element stores a key and/or a certificate tied to the eUICC) -signing- ([0047] “the eSE 118 can generate a certificate signing request,” i.e. a signing request to be sent to the eUICC) and -including the HSM challenge for the eUICC (as described above the HSM challenge is transmitted between the eUICC and SEP, see [0047]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to modify Kang to include the use of a secure-enclave processor (SEP), SEP-specific key pairs, and SEP certificates, as taught by Li, in order to [0004] ensure the eUICC can provide new or enhanced services to a user of the mobile device that includes the eUICC and to [0044] allow for mutual authentication between the eUICC and other devices.
Regarding claim 2, Kang teaches the begin-pair message ([Figure 4, operation 1d-20] this operation may be a begin-pair message as described in claim 1) includes: an exclusive chip identifier (ECID) associated with the device, an eUICC identifier (EID) associated with the eUICC, or a Global System for Mobile Communications Association (GSMA) subject key identifier ([0060] an eUICC identifier (eUICC ID) may be a unique identifier of an eUICC embedded in a terminal and may be referred to as an EID).
Regarding claim 6, Kang teaches receiving, an LPA signing response from the eUICC the LPA signing response- (FIG. 4 depicts receiving an LPA response in blocks 1d-45 and 1d-65) and generating an authentication response to be transmitted to the server based on the LPA signing response ([0079] the LPA 1a-15 may obtain a user's input for local management of a profile by configuring a UI or may receive a remote management instruction through the SM-DP+ server 1a-70, and may obtain an input from the user 1a-01 by configuring a UI for the instruction, and may then transmit a management command for the profile, i.e. the LPA communicating with the server to ensure the [0107] authentication of the UICC).
Kang differs from the claimed invention and does not specifically teach -to include a payload with the HSM challenge for the UICC signed with an eUICC signature and a certificate chain to be used to verify the eUICC signature; However, Li teaches as such (FIG. 5A depicts HSM validation steps, i.e. HSM challenges, and [0026] the embedded secure element stores a key and/or a certificate tied to the eUICC of the mobile device and may include a [0034] UICC signature).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kang to include the use of a hardware security module (HSM) in accordance with a UICC signature and a certificate chain, as taught by Li, in order to [0004] ensure the eUICC can provide new or enhanced services to a user of the mobile device that includes the eUICC and to [0044] allow for mutual authentication between the eUICC and other devices.
Regarding claim 7, Kang teaches the authentication response comprises the SEP attestation, the SEP certificate, an eUICC signature, or an eUICC certificate (0083] an embedded UICC controlling authority security domain (ECASD), which is a space for storing a certificate issuer's root public key for verifying credentials required by security domains of the eUICC, for example, an SM- DP+ credential, a keyset of an eUICC manufacturer, and the like, an eSIM operating platform, and the like may be included, i.e. the authentication response described in [0079] and the above claim 6, may contain the eUICC certificate or signature).
Regarding claim 8 Kang teaches, receiving, from the server ([Figure 1, 1a-70]), a first store pairing key message that includes a server attestation ([Figure 5, step 1e-10] and [0060-0061] the first APDU message depicted in FIG. 5 shows the Terminal (1e-01) communicating with the UICC (1e-05), the terminal receives messages from the server (1a-70) as depicted in in FIG. 1, the first APDU message may include [0053 and 0062] an authentication key); and generating a second store-pairing key message to be transmitted to the eUICC with the server attestation and a signed certificate from the server ([Figure 5, 1e-30] the second APDU may include another key message which may further include [0083] a certificate), wherein the server attestation includes an eUICC identifier (EID) associated with the UICC and a public key of the- -certificate ([0060] an eUICC identifier (eUICC ID) may be a unique identifier of an eUICC embedded in a terminal and may be referred to as an EID, and may be associated with [0083] a public key in association with the certificate).
Kang differs from the claimed invention and does not specifically teach -the SEP certificate. However, Li teaches as such ([0047] FIGS. 5A and 5B illustrate a sequence diagram 500/550 for pairing an embedded secure element, the eUICC verifies its authorization via the SEP transmitting/receiving a signed key to the server).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kang to include the use of a hardware security module (HSM) or a secure-enclave processor (SEP), as taught by Li, in order to [0004] ensure the eUICC can provide new or enhanced services to a user of the mobile device that includes the eUICC and to [0044] allow for mutual authentication between the eUICC and other devices.
Regarding claim 9, Kang teaches receiving, from the eUICC, a response to indicate the eUICC verified the- -attestation ([0060] a response APDU (response message), and may operate in a manner such that the terminal transmits a command APDU to the card and the card receiving the command APDU replies with a response APDU), the signed certificate and the EID ([0060] EID as described previously) and has stored the public key ([0083] describes storing a certificate and public key).
Kang differs from the claimed invention and does not specifically teach the SEP attestation. However, Li teaches as such ([0047] FIGS. 5A and 5B illustrate a sequence diagram 500/550 for pairing an embedded secure element, the eUICC verifies its authorization via the SEP transmitting/receiving a signed key to the server).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kang to include the use of a hardware security module (HSM) or a secure-enclave processor (SEP), as taught by Li, in order to [0004] ensure the eUICC can provide new or enhanced services to a user of the mobile device that includes the eUICC and to [0044] allow for mutual authentication between the eUICC and other devices.
Regarding claim 10, Kang teaches a universal integrated circuit card (UICC) ([Figure 1, device 1a-50] and [0009-0013] describes the eUICC may be a UICC, or [0060] eUICC is embedded in a terminal 1a-05) comprising: interface circuitry ([Figure 9, 1i-50] and [0186] the terminal may contain a screen display 1i-50); and processing circuitry coupled with the interface circuitry ([Figure 9, 1i-20/1i-30] and [0186] a message processor 1i-20, a controller 1i-30, i.e. processing circuity couple with interface circuity 1i-50), the processing circuitry to: transmit, to a baseband processor via the interface circuitry ([Figure 9, 1i-10] a message transceiver 1i-10 coupled with message processor 1i-20 and interface circuity 1i-50, [0080] describes processors may be two or more baseband processors, as depicted in FIG. 1 1a-30/1a-35), an answer-to-reset (ATR) message that includes a pairing capability of the UICC and an unpaired indication ([0124] the UICC 1e-05 may transmit an answer to reset (ATR) to the terminal 1e-01, depicted in FIG. 5, [0124-0125] describes how the response APDU from the UICC 1f-05 to terminal 1f-01 may include information such as having a pending proactive command or other indicators, i.e. such as to pair if unpaired); receive, from the baseband processor via the interface circuitry (FIG. 9 depicts the processor 1i-20 in accordance with a message transceiver 1i-10, further communicating with a interface circuity 1i-50, and the processor may be a [0080] baseband processor), generate a random key ([0053], [0057], [0062], and [0083], the UICC/eUICC may include key generation capabilities).
Kang differs from the claimed invention and does not specifically teach an initialize-pairing message with an international mobile equipment identifier (IMEI) associated with the baseband processor; and -transmit the random key to the baseband processor via the interface circuitry. However, Li teaches an initialize-pairing message with an international mobile equipment identifier (IMEI) associated with the baseband processor; ([0047] describes a unique identifier (UID) for the mobile device and an exclusive chip identifier (ECID), UID or ECID read as equipment identifier, associated with [0033] a baseband processor, which may be included in a message, [0014] FIGS. 5A and 5B illustrate a sequence diagram for pairing an embedded secure element with an eUICC in a mobile device, including an [0057] initialize pairing message) and -transmit the random key to the baseband processor via the interface circuitry ([0027] “the eUICC and the embedded secure element and/or the trusted execution environment are paired with symmetric keys and/or certificates after manufacture of the mobile device, such as using verification via an external L3 sever and key/certificate injection to the mobile device,” i.e. pairing an eUICC with the embedded secure element (which may be a SEP, see FIG. 3 310, and [0042]) via a generated random key).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kang to include the use of an IMEI unique identifier and transmitting to the baseband processor a random key, as taught by Li, in order to [0004] ensure the eUICC can provide new or enhanced services to a user of the mobile device that includes the eUICC and to [0044] allow for mutual authentication between the eUICC and other devices.
Regarding claim 11, Kang teaches the processing circuitry is further to: receive, from the baseband processor via the interface circuitry (FIG. 9 depicts interface circuity 1i-50 and processor 1i-20 capable of receiving messages via the message transceiver 1i-10, and the processor may be a [0080] baseband processor), a finalize-pairing message to indicate the random key was saved by baseband processor ([0130] FIG. 5 depicts the terminal 1e-01 and the UICC 1e-05 complete the proactive command processing procedure (operation 1e-60), i.e. the operation which may be [0074] pairing/connecting is complete and [0057] an authentication key value has been stored in a UICC).
Regarding claim 12, Kang teaches the processing circuitry is further to: enter a paired state based on receipt of the finalize-pairing message ([0074] the eUICC may complete processing of the status change of a profile connected to a corresponding logical interface by receiving the result of processing a proactive command, i.e. the pairing APDU command/response interaction has concluded and the devices are in a "paired" state).
Regarding claim 13, Kang teaches the ATR message is a first ATR message and the processing circuitry ([0124] information may be notified via one of an Answer to Reset (ATR), a returned value for a terminal capability command APDU transmitted from the terminal, i.e. the first APDU transmitted shown in FIG. 5 may be the first ATR message) is further to: detect a power-on or reset event ([0126] a UICC reset mode or an eUICC profile state change mode through a REFRESH-type proactive command, i.e. a reset event may occur); and determine, based on detection of the power-on or reset event, that the UICC is in the paired state ([0138] REFRESH-type proactive command indicating that the state of a file in the UICC is changed, i.e. the detection of a power reset event and the ability for [0124 and 0149] a plurality of specific indicators to represent the UICC is paired); and transmit ([Figure 9, 1i-10] message transceiver), to a processor ([Figure 9, 1i-20] message processor), a second ATR message with a restricted indication to indicate operation of the UICC is restricted to a subset of available operations ([0119] if impossible, the LPA 1d-05 may optionally notify the user 1d-01 of the reason why the processing is impossible and may terminate the processing (operation 1d-85). Further, when the LPA 1d-05 cannot determine why the processing is impossible through the previously returned error message (operation 1d-70), the LPA ld-05 may optionally transmit a notification to the user 1d-01 and may terminate the processing (operation ld-85), and [0124] UICC 1e-05 may transmit an answer to reset (ATR) to the terminal 1e-01 in response to generate a session for data transmission and reception between the terminal and the card, i.e. the UICC may transmit a plurality of ATR as described in [0133-0140], and this ATR may be the second ATR).
Regarding claim 14, Kang teaches the processing circuitry is further to: receive, from the processor via the interface circuitry, an initialize-authentication message; transmit, to the processor via the interface circuitry (FIG. 9 depicts the ability to receive/transmit messages via the processor in association with interface circuity), -receive, from the processor via the interface circuitry (FIG. 9 depicts the ability to receive/transmit messages via the processor in association with interface circuity).
Kang differs from the claimed invention in not specifically teaching -a nonce; and a message authentication code (MAC) message that is based on the nonce and an IMEI associated with the processor; perform one or more verification operations based on the MAC message; and determine the processor is the baseband processor based on performance of the one or more verification operations. However, Li teaches -a nonce ([0047] describes a nonce may be used in accordance with an authentication process); and a message authentication code (MAC) message that is based on the nonce and an IMEI associated with the processor ([0047] the eSE 118 can also generate a hash (labeled as HMAC SEP in FIG. 5A) based on a group identifier (GID), the CSR, an exclusive chip identifier (ECID), and the challenge. The CSR, ECID, and HMAC SEP can be communicated to the AP 506, which can generate a signed identity map based on the information and send the signed identity map to the eUICC 108, the eUICC 108 can return to the AP 506 the signed identity map with a nonce added thereto, i.e. variations of a message authentication code (MAC), based on a variation of identifiers associated with the processor); perform one or more verification operations based on the MAC message ([0047] describes the signed identity that may be transmitted for verification operations); and determine the processor is the baseband processor based on performance of the one or more verification operations ([0047] the HSM 502 can validate the eUICC certificate, verify the eUICC signature, verify the CSN, verify the hash (HSM_SEP), validate the CSR, and issue a certificate (when successful verification and validation occurs) for the eSE 118 (the certificate labeled as SEP_VINYLcert in FIG. 5A), i.e. validation of processor based on performance of the verification operations).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kang to include the use a message authentication code (MAC) message that is based on a nonce and an IMEI associated with the processor in association with verification operations, as taught by Li, in order to [0004] ensure the eUICC can provide new or enhanced services to a user of the mobile device that includes the eUICC and to [0044] allow for mutual authentication between the eUICC and other devices.
Regarding claim 15, Kang differs from the claimed invention and does not specifically teach the MAC message is based on a cipher-based MAC algorithm or a hash-based MAC algorithm. However, Li teaches as such ([0047] the eSE 118 can also generate a hash (labeled as HMAC SEP in FIG. 5A)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kang to include the use of a hash-based MAC algorithm, as taught by Li, in order to [0004] ensure the eUICC can provide new or enhanced services to a user of the mobile device that includes the eUICC and to [0044] allow for mutual authentication between the eUICC and other devices.
Regarding claim 16, Kang differs from the claimed invention and does not specifically teach the one or more verification operations comprise: a verification of the MAC message, a verification of the IMEI, or a verification of the nonce. However, Li teaches as such ([0047] the HSM 502 can validate the eUICC certificate, verify the eUICC signature, verify the CSN, verify the hash (HSM_SEP), validate the CSR, and issue a certificate (when successful verification and validation occurs) for the eSE 118 (the certificate labeled as SEP_VINYLcert in FIG. 5A), i.e. validation of MAC message or various identifiers)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kang to include the use of validation of MAC messages or various identifiers, as taught by Li, in order to [0004] ensure the eUICC can provide new or enhanced services to a user of the mobile device that includes the eUICC and to [0044] allow for mutual authentication between the eUICC and other devices.
Regarding claim 17, Kang teaches the processing circuitry is further to: transmit, to the baseband processor based on determination that the processor is the baseband processor ([0080] describes processors may be two or more baseband processors, as depicted in FIG. 1 1a-30/1a-35), a message to indicate the UICC is no longer restricted to the subset of available operations ([0119] describes how the UICC may be restricted and corresponding notifications, i.e. the UICC may no longer be restricted).
Regarding claim 18, Kang teaches the subset of available operations includes operations to perform an initialization procedure with the baseband processor ([0105] Referring to FIG. 4, it may be assumed that an LPA, an eUICC, and a modem support MEP and agree to operate in the MEP mode by a performance negotiation in an initialization process between the terminal and the card or presetting between the terminal and the card, the terminal may include [0080] baseband processors, as depicted in FIG. 1 1a-30/1a-35).
Regarding claim 19, Kang teaches the subset of available operations includes operations to enable installation of UICC firmware ([0087] an SM-DP+ to activate/deactivate/delete/update a preinstalled profile, and [0057] profile may have the same meaning as a profile or may refer to a packaged software form of information included in a USIM application in the profile, i.e. the UICC may be updated with a packaged software, which may be firmware).
Regarding claim 20, Kang teaches the subset of available operations includes operations to debug or identify the UICC ([0108] the eUICC 1d-10 may identify whether the ES10c.command can be processed by identifying a current profile deactivation/activation state, i.e. identifying the UICC).
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 MATTHEW JAMES DWYER whose telephone number is (571)272-5121. The examiner can normally be reached M-F 6 a.m. - 3 p.m. EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Yuwen Pan can be reached at (571) 272-7855. 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.
/MATTHEW JAMES DWYER/Examiner, Art Unit 2649
/GEORGE ENG/Supervisory Patent Examiner, Art Unit 2699
Prosecution Insights