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 .
Detail Action
This office action is response to the application 18/962,963 filed on 11/27/2024. Claims 1-20 are pending in this communication.
Priority
This application claims priority from EP 23383240.1 11/30/2023. Priority date has been accepted.
Examiner’s Note
The examiner is requesting the applicant’s representative to provide direct phone number and/or mobile phone number in next communication, which will be very helpful to advance the prosecution.
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 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. OR
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-5 & 13-17 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by KANG; Sujung et al. (US 2022/0159448 A1).
Regarding Claim 1, KANG anticipated an embedded universal integrated circuit card (eUICC), wherein an issuer security domain root (ISD-R) is hosted and implemented as a root profile, wherein at least one security domain profile (ISD-P) hosts or is constructed for hosting an operational profile, said eUICC comprising:
a device-eUICC binding applet being implemented in the issuer security domain root (ISD-R) {Fig. 1 & [0085], “The ISD-R 165 generates a new ISD-P (meaning a security domain for hosting the profile) and as described above, the necessary eUICC data and services (e.g., local profile management, profile information, etc.) required by the LPA (Local Profile Assistant) functions are stored or collected in the eUICC 150 and provided to LPA 115”. Examiner’s note: LPA is functioning as eUICC binding applet (Fig. 1 element 110) for host enablement};
the device-eUICC binding applet being constructed to, after each reset of the eUICC: effect the eUICC to be in a disabled state which prevents operation of the eUICC in the device {Fig. 4 steps 425-450 & [0108], “The modem 415 may transmit a terminal response (when the eUICC 410 transmits an eUICC profile state change) to the eUICC 410 or may not transmit the terminal response (when the eUICC 410 transmits a UICC reset) according to the result of processing the REFRESH in the modem 415 in operation 450”. Examiner’s note: at step 455 target profile’s port number remain disabled preventing operation of host (Fig. 1 UE 105)};
output, to a device hosting the eUICC, a request for sending enablement information, and, only when valid enablement information of a target device is received at the eUICC, identify the device hosting the eUICC as the target device, and set the eUICC into an enabled state in order to enable operation of the eUICC in the device {Fig. 4 steps 475 & 480 & [0109], “the modem 415 performs the UICC activation procedure including TERMINAL PROFILE defined in ETSI TS in operation 475. After the above procedure is performed, the modem 415 performs a network attach procedure using information of a profile (e.g., profile 3) newly connected to the port in the baseband connected to the port in operation 480”. Examiner’s note: eUICC is enabled after verifications (Fig. 4 steps 425-470 with OK message) and the host UE is enabled for operation}.
Regarding Claim 2, KANG anticipates all the features of claim 1 and KANG further anticipates
wherein the request for sending enablement information, in reply to receiving from the device an eUICC-authentication request, requests the eUICC to provide authentication information to authenticate the eUICC with respect to the device {Fig. 4 elements 465, 470 & [0058], “AKA (authentication algorithm) may indicate authentication and key agreement, and may indicate an authentication algorithm for accessing … networks. K is an encryption key value stored in the eUICC used for the AKA authentication algorithm, and in the present disclosure, OPc is a parameter value that can be stored in the eUICC used for the AKA authentication algorithm”}.
Regarding Claim 3, KANG anticipates all the features of claim 2 and KANG further anticipates
wherein the enablement information received at the eUICC comprises or is part of a eUICC-Response, which is received at the eUICC from the device, in reply to the eUICC-Challenge {ABSTRACT AND Fig. 4 steps 445 refresh challenge, 450 reset response & step 470 OK, steps 475 & 480 network attach procedure & related written description in specification relating Fig. 4) & [0102], “FIG. 4 illustrates a method for a UE and an eUICC to process local profile activation when the UE operates in an MEP mode”}.
Regarding Claim 4, KANG anticipates all the features of claim 3 and KANG further anticipates
wherein the request comprises the target device specific public key, wherein the valid enablement information comprises a signature generated with the target device specific secret key corresponding to the target device specific public key {[0086], “for convenience of description, the eUICC 150 of the UE 105 may include an embedded UICC controlling authority security domain (ECASD), which is a space for storing certificates required by the security domains of the eUICC 150, for example, a certificate issuer's root public key for verifying a SM-DP+ certificate, keyset of eUICC manufacturer”. Examiner’s note: ‘keyset of eUICC manufacturer’ is functioning as claimed ‘signature’}.
Regarding Claim 5, KANG anticipates all the features of claim 4 and KANG further anticipates
wherein the eUICC-authentication request comprises or is part of a device-Challenge in a Challenge-Response procedure; wherein the authentication information received at the device comprises or is part of a eUICC-Response, which is received at the device from the eUICC, in reply to the device-Challenge {[0086], “for convenience of description, the eUICC 150 of the UE 105 may include an embedded UICC controlling authority security domain (ECASD), which is a space for storing certificates required by the security domains of the eUICC 150, for example, a certificate issuer's root public key for verifying a SM-DP+ certificate, keyset of eUICC manufacturer”. Examiner’s note: device profile activation process includes authentication request and receiving approval}.
Regarding claim 13, claim 13 is claim to a method using the eUICC device of claim 1. Therefore, claim 13 is rejected for the reasons set forth for claim 1.
Regarding claim 14, claim 14 is a dependent claim of claim 13, claim 14 is claim to method using the eUICC device of claim 2. Therefore, claim 14 is rejected for the reasons set forth for claim 2.
Regarding claim 15, claim 15 is a dependent claim of claim 14, claim 15 is claim to method using the eUICC device of claim 3. Therefore, claim 15 is rejected for the reasons set forth for claim 3.
Regarding claim 16, claim 16 is a dependent claim of claim 15, claim 16 is claim to method using the eUICC device of claim 4. Therefore, claim 16 is rejected for the reasons set forth for claim 4.
Regarding claim 17, claim 17 is a dependent claim of claim 16, claim 17 is claim to method using the eUICC device of claim 5. Therefore, claim 17 is rejected for the reasons set forth for claim 5.
Allowable subject matter
Claim 6 & 7 will be allowable if written in independent form with base eUICC device claim 1, and Claims 18 & 19 will be allowable if written in independent form with base method claim 13.
The reason of allowance is - to unlock, the card (eUICC) challenges the host device to provide enablement information, which may include a public-key signature and a synchronized one-time-password (OTP). Once this OTP and cryptographic proof is verified, the ISD-R identifies the host as the authorized target device and enables the ISD-P to host and execute its operational profile. To unlock a default locked (eUICC) card use public-key, a certificate linking eUICC manufacturer and one-time password (OTP) all three.
Therefore, claims 6-12 & 18-20 are objected.
Conclusion
Following prior arts have been considered, however, is not applied:
ALONSO CEBRIAN; Jose Maria et al. (US 2016/0156598 A1) – “extra authentication factor mechanism is extended with the use of a public/private key for generating a digital signature by means of: generating and sending, the second server to the dedicated program, a one-time password (OTP) that the user is going to use for setting up the extra authentication factor mechanism”; and
GAO; Linyi (US 10,182,340 B2) – Profile switching method & terminal: “A profile switching method and a terminal, where the method includes sending, by a terminal, an enable instruction to an embedded universal integrated circuit card (eUICC), where the eUICC includes at least a first profile and a second profile, the terminal has accessed a network using the first profile, data of the first profile is stored in a cache of the terminal, and the enable instruction instructs the eUICC to disable the first profile and enable the second profile, and send a first instruction to the terminal, where the first instruction instructs the terminal not to restart the eUICC, and after receiving the first instruction, retaining, by the terminal, the data of the first profile in the cache, storing data of the second profile in the cache, and accessing a network using the second profile”.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to QUAZI FAROOQUI whose telephone number is (571) 270-1034 or Quazi.farooqui@USPTO.GOV. The examiner can normally be reached on Monday-Friday 9:00 am to 5:30 pm, EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bill Korzuch can be reached on (571) 272-7589 or William.Korzuch@USPTO.GOV. The fax phone number for Examiner Farooqui assigned is 571-270-2034.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-flee). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/QUAZI FAROOQUI/
Primary Examiner, Art Unit 2491