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(s) (IDS) submitted on 01/30/2024 and 07/13/2025 have been considered by the examiner.
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-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 a universal integrated circuit card (UICC) 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 a UICC 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).
Kang differs from the claimed invention and does not specifically teach generating, based on the authentication request, a generate-attestation message to be transmitted to a secure-enclave processor (SEP) on the device; and receiving, from the SEP, a SEP attestation signed by a SEP-specific key pair, the SEP attestation conveying a SEP certificate. 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 generating, based on the authentication request, a generate-attestation message to be transmitted to a secure-enclave processor (SEP) on the device ([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); and receiving, from the 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).
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 UICC is an embedded UICC (eUICC) ([0013-0014] describes how the UICC may be an eUICC) and 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 3, Kang teaches the UICC is an embedded UICC (eUICC) ([0013-0014] describes how the UICC may be an eUICC),
Kang differs from the claimed invention and does not specifically teach the authentication request includes one or more hardware security module (HSM) challenges, and the generate-attestation message includes the one or more HSM challenges. However, Li teaches the authentication request includes one or more hardware security module (HSM) challenges ([0047] depicted in FIG. 5A, Hardware Security Module (HSM) 502, and HSM validation steps, i.e. HSM challenges), and the generate-attestation message includes the one or more HSM challenges (FIG. 9A steps 902, 904, and 906 describes generating authentication messages to be transmitted between the server and the SEP on the device, FIG. 5A depicts HSM validation steps, i.e. HSM challenges).
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), 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 4, Kang differs from the claimed invention and does not specifically teach the one or more HSM challenges comprises: an HSM challenge for the SEP; or an HSM challenge for the eUICC. However, Li teaches the one or more HSM challenges (FIG. 5A depicts HSM validation steps, i.e. HSM challenges) comprises: an HSM challenge for the SEP; or an HSM challenge for the eUICC ([0047] FIGS. 5A and 5B illustrate 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, and the eSE 118 can generate a certificate signing request (CSR)).
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 5, Kang teaches generating a local profile assistant (LPA) signing request to be transmitted to the eUICC- ([0060] a terminal or device may include a local profile assistant (LPA), and the LPA may make requests to the SM-DP+ server, i.e. a signing request may be transmitted to the eUICC via the LPA)
Kang differs from the claimed invention and does not specifically teach the one or more HSM challenges includes an HSM challenge for the eUICC and the method further comprises: and - with the HSM challenge for the eUICC. However, Li teaches as such ([0047] FIGS. 5A and 5B illustrate the eSE 118 can validate the HSM certificate, verify the HSM signature, and transmit said information via a HSM challenge for the eUICC).
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), 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 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 a UICC signature and a certificate chain to be used to verify the UICC 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 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 a UICC identifier (ID) 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 UICC, a response to indicate the UICC 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] the UICC/eUICC may include key generation capabilities); and transmit the random key to the baseband processor via the interface circuitry ([0057] a profile may refer to a packaged software form of an application, a file system, and an authentication key value stored in a UICC, FIG. 1 depicts random keys being transmitted, and FIG. 9 depicts the interface circuity that would transmit said keys in a APDU command/response).
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; However, Li teaches as such ([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).
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, 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
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Rajadurai, Rajavelsamy et al. (2015). Method and system for secured remote provisioning of a universal integrated circuit card of a user equipment (US 9037112 B2). Filed 2011-03-15. Discloses remote provisioning for a universal integrated circuit card of a user equipment in accordance with unique identifiers and security keys. (abstract)
Yang, Xiangying (2022). Embedded universal integrated circuit card (euicc) profile content management (US 2022/0385445 A1). Filed 2022-08-10. Discloses a mobile network operator (MNO) using a provisioning server to update or install profile content in a profile or electronic subscriber identity module (eSIM) in accordance with trust relationships and OTA keys. (abstract)
Kang, Sujung et al. (2022). Method and apparatus for transmitting and processing profile management message for multiple enabled profiles between terminal and universal integrated circuit card (US 2022/0264284 A1). Filed 2022-02-17. Discloses a profile management module in an eUICC in a terminal (a modem or an LPA) during terminal-card initialization. (abstract)
Kang, Sujung et al. (2022). Method and apparatus for handling profiles by considering removable euicc supporting multiple enabled profiles (US 2022/0159448 A1). Filed 2021-11-18. Discloses a method for performing activation and cold reset for configuring an operating environment for a removable eUICC supporting a MEP mode in accordance with ATR messages. (abstract)
Kang, Sujung et al. (2020). Method and apparatus for providing communication service (US 2020/0404501 A1). Filed 2020-06-22. Discloses a method for identifying and accessing, by performing a discovery process, an Internet of Things (IoT) terminal operating as an access point, transmitting, to the IoT terminal, authentication information for performing a second embedded Subscriber Identity Module (eSIM) setup process. (abstract)
Castillo, Laurent et al. (2015). Method for asynchronously provisioning keys from one secure device to another (US 2015/0052359 A1). Filed 2013-08-19. Discloses a method to securely and asynchronously provision keys from one source secure device to a target secure device in accordance with a secure server. (abstract)
Lee, Jinhyoung et al. (2014). Certification method using an embedded uicc certificate, provisioning and mno changing methods using the certification method, embedded uicc therefor, mno system, and recording medium (US 2014/0329502 A1). Filed 2012-09-04. Discloses a method to verify the identity of a eUICC. (abstract)
Park, Jaemin (2014). Profile management method, embedded uicc, and device provided with the embedded uicc (US 2014/0237101 A1). Filed 2012-09-25. Discloses a method for managing a profile in an embedded UICC for providing communication and additional services. (abstract)
Merrien, Lionel et al. (2012). Method for unlocking a secure device (US 2012/0278857 A1). Filed 2010-12-24. Discloses a method for unlocking a secure device OTA. (abstract)
Dong, Olivier (2011). Client-server communications in mobile radio communications device (US 2011/0228738 A1). Filed 2009-07-31. Discloses a method of communication within a mobile radio communications device between a chip-card for distinguishing messages. (abstract)
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