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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 10 June 2026 has been entered.
Response to Amendment
Applicant’s amendment filed 10 June 2026 amends claims 1-5, 7, 9-15, and 17. Applicant’s amendment has been fully considered and entered.
Response to Arguments
Applicant argues on page 11 of the response, “As conceded in the Office Action, ‘Yu does not specify that the terminal receives user input of the confirmation code when the required confirmation code required flag is true.’” In response, claim 4 does not currently include this limitation. Instead, claim 4 specifies that “the hashed confirmation code is based on a confirmation code by receiving an input from a user”. Claim 4 does not specify that the input from the user is received when the confirmation required flag is set to true. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Applicant argues on page 12 of the response, “In addition, Claim 4 specifies that the device change htat [sic] is the subject of a confirmation request message is a ‘device change of the first device to a second device.’” In response, the claim actually specifies that the authentication client response message includes a confirmation required flag and that the confirmation required flag is for the device change of the first device to a second device. However, the claim never functionally utilizes the claimed confirmation required flag to perform a device change operation. Therefore, the “for the device change…” language represents intended use. A recitation of the intended use of the claimed invention must result in a structural difference between the claimed invention and the prior art in order to patentably distinguish the claimed invention from the prior art. If the prior art structure is capable of performing the intended use, then it meets the claim.
Applicant argues on page 15 of the response, “This means that the ‘change’ in Yu refers to a change of a ‘server,’ not a change of a device from a ‘first terminal to a second terminal.’ In contrast, the ‘device change’ of Claim 1 refers to an operation of changing a device from a first terminal to a second terminal, and therefore the situations themselves are different.” In response, Claim 1 does not require an actual operation of changing a device from a first terminal to a second terminal. Instead, claim 1 requires the authenticate client response message to include a confirmation required flag and that confirmation required flag is for the device change of the first device to a second device. However, the claim never functionally utilizes the claimed confirmation required flag to perform a device change operation. Therefore, the “for the device change…” language represents intended use. A recitation of the intended use of the claimed invention must result in a structural difference between the claimed invention and the prior art in order to patentably distinguish the claimed invention from the prior art. If the prior art structure is capable of performing the intended use, then it meets the claim.
Applicant argues on page 15 of the response, “Further, although Yu discloses that EuiccSigned2 may include a hashed confirmation code, Yu does not disclose that the hashed confirmation code is calculated based on a confirmation code received from a user, as in Claim 1.” In response, the Final rejection mailed 10 April 2026 (“Final”) addresses this limitation on pages 9-10 using the Yu and Lee references. Specifically, the Final makes it clear that Yu discloses that the terminal hashes the confirmation code (Page 33, paragraph 2), but Yu does not specify that the terminal receives user input of the confirmation code when the required confirmation code required flag is true. Lee discloses receiving a Boolean end user intent confirmation indicator that indicates whether an end user intent confirmation is required to execute a command such that when the end user intent confirmation is required to execute the command, a screen is presented for receiving user input to provide confirmation ([0163]), which meets the limitation of receiving, from a subscription manager data preparation plus (SM-DP+), an authenticate client response message including a confirmation required flag for a device change, in case that the confirmation required flag for the device change is set to true, receiving an input from a user. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for confirmation code of Yu to have been manually entered by a user in response to the required confirmation code required flag being asserted in order to give the end user the opportunity to consent the changes as suggested by Lee ([0148] & [0163]).
Applicant argues on page 16 of the response, “That is, Yu and Lee are different in their technical fields themselves, and therefore it is improper to combine these two references.” This argument is not persuasive because each of the references are concerned with event processing.
Applicant argues on page 19 of the response, “That is, Lee is intended to change bundle states in an SSP module within a single device, and is not directed to a device change from a first device to a second device as in Claim 1.” As stated above, claim 1 does not actually require a device change operation.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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.
Claims 1, 3, 4, 5, 7, 9, 11, 12, 13, 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over Yu, WO 2019095948, in view of Lee, U.S. Publication No. 2020/0137572. Referring to claim 1, Yu discloses event processing wherein a terminal receives smdpSigned3 from an SM-DP+ server (Page 31, paragraph 5, S604: terminal reads on the claimed LPA) where smdpSigned3 includes a required confirmation code required flag (Page 30, paragraph 11: claim never functionally utilizes the claimed confirmation required flag to perform a device change operation. Therefore, the “for the device change…” language represents intended use. A recitation of the intended use of the claimed invention must result in a structural difference between the claimed invention and the prior art in order to patentably distinguish the claimed invention from the prior art. If the prior art structure is capable of performing the intended use, then it meets the claim), which meets the limitation of receiving, from a subscription manager data preparation plus (SM-DP+), an authentication client response message including a confirmation required flag for a device change of the first device to a second device. Yu discloses that the terminal hashes the confirmation code (Page 33, paragraph 2), which meets the limitation of based on the confirmation code, calculating a hashed confirmation code. The terminal sends the calculated hash to the SM-DP+ (Page 33, paragraph 6: LPA sends euiccSigned2 to SM-DP+ and euiccSigned2 includes hashed confirmation code), which meets the limitation of transmitting, to the SM-DP+, a confirmation request message for the device change including the hashed confirmation code. Yu discloses that the SM-DP+ verifies the received information and begins configuration file download to the terminal (Page 33, paragraphs 7-8: configuration file reads on the claimed activation code), which meets the limitation of receiving, from the SM-DP+, a confirmation response message for the device change including an activation code.
Yu discloses that the terminal hashes the confirmation code (Page 33, paragraph 2), but Yu does not specify that the terminal receives user input of the confirmation code when the required confirmation code required flag is true. Lee discloses receiving a Boolean end user intent confirmation indicator that indicates whether an end user intent confirmation is required to execute a command such that when the end user intent confirmation is required to execute the command, a screen is presented for receiving user input to provide confirmation ([0163]), which meets the limitation of receiving, from a subscription manager data preparation plus (SM-DP+), an authenticate client response message including a confirmation required flag for a device change, in case that the confirmation required flag for the device change is set to true, receiving an input from a user. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for confirmation code of Yu to have been manually entered by a user in response to the required confirmation code required flag being asserted in order to give the end user the opportunity to consent the changes as suggested by Lee ([0148] & [0163]).
Referring to claim 3, Yu describes a two-way authentication process between the LPA and the SM-DP+ (Page 30, paragraph 8) that includes the terminal transmitting an initial authenticaiotn message to the SM-DP+ that includes eUICC information (Page 39, paragraphs 1-2), which meets the limitation of transmitting, to the SM-DP+, an authenticate client request message for the device change, wherein the authenticate client request message for the device change further includes an embedded universal integrated circuit card (eUICC) identifier (EID).
Referring to claim 4, Yu discloses event processing wherein an SM-DP+ server transmits smdpSigned3 to a terminal (Page 31, paragraph 5, S604: terminal reads on the claimed LPA) where smdpSigned3 includes a required confirmation code required flag (Page 30, paragraph 11: claim never functionally utilizes the claimed confirmation required flag to perform a device change operation. Therefore, the “for the device change…” language represents intended use. A recitation of the intended use of the claimed invention must result in a structural difference between the claimed invention and the prior art in order to patentably distinguish the claimed invention from the prior art. If the prior art structure is capable of performing the intended use, then it meets the claim), which meets the limitation of transmitting, to a first local profile assistant (LPA) of a first device, an authenticate client response message including a confirmation required flag for the device change of the first device to a second device, wherein the confirmation required flag for the device change is set to true. The SM-DP+ receives the hash of a confirmation code from the terminal (Page 33, paragraphs 2 & 6: LPA sends euiccSigned2 to SM-DP+ and euiccSigned2 includes hashed confirmation code), which meets the limitation of receiving, from the first LPA of the first device, a confirmation request message for the device change including a hashed confirmation code. The SM-DP+ verifies the received euiccSigned2 (Page 33, paragraph 7), which meets the limitation of verifying the hashed confirmation code. The SM-DP+ verifies the received information and begins configuration file download to the terminal (Page 33, paragraphs 7-8: configuration file reads on the claimed activation code), which meets the limitation of transmitting, to the first LPA of the first device, a confirmation response message for the device change including an activation code.
Yu discloses that the terminal hashes the confirmation code (Page 33, paragraph 2), which meets the limitation of wherein the hashed confirmation code is based on a confirmation code [by receiving an input from a user]. Yu does not specify that the terminal receives user input of the confirmation code when the required confirmation code required flag is true. Lee discloses receiving a Boolean end user intent confirmation indicator that indicates whether an end user intent confirmation is required to execute a command such that when the end user intent confirmation is required to execute the command, a screen is presented for receiving user input to provide confirmation ([0163]), which meets the limitation of based on a confirmation code by receiving an input from a user. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for confirmation code of Yu to have been manually entered by a user in response to the required confirmation code required flag being asserted in order to give the end user the opportunity to consent the changes as suggested by Lee ([0148] & [0163]).
Referring to claim 5, Yu describes a two-way authentication process between the LPA and the SM-DP+ (Page 30, paragraph 8) that includes the terminal transmitting an initial authenticaiotn message to the SM-DP+ that includes eUICC information (Page 39, paragraphs 1-2), which meets the limitation of receiving, from the first LPA of the first device, an authenticate client request message for the device change, wherein the authenticate client request message for the device change further includes an embedded universal integrated circuit card (eUICC) identifier (EID).
Referring to claim 7, Yu discloses that the terminal hashes the confirmation code and includes the hashed confirmation code in the euiccSigned2 along with a session identifier (Page 33, paragraph 2), which meets the limitation of wherein the hashed confirmation code is calculated based on a confirmation code [by receiving the input from the user] and a transaction identifier (ID).
Yu does not specify that the terminal receives user input of the confirmation code when the required confirmation code required flag is true. Lee discloses receiving a Boolean end user intent confirmation indicator that indicates whether an end user intent confirmation is required to execute a command such that when the end user intent confirmation is required to execute the command, a screen is presented for receiving user input to provide confirmation ([0163]), which meets the limitation of wherein the hashed confirmation code is calculated based on the confirmation code by receiving the input from the user. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for confirmation code of Yu to have been manually entered by a user in response to the required confirmation code required flag being asserted in order to give the end user the opportunity to consent the changes as suggested by Lee ([0148] & [0163]).
Referring to claim 9, Yu discloses event processing wherein a terminal that includes a transmitter 1603, receiver 1601, and processor 1602 (Page 61, paragraph 4), which meets the limitation of a first local profile assistant (LPA) of a first device in a wireless communication system, the first LPA of the first device comprising a transceiver, and a controller coupled with the transceiver. The terminal receives smdpSigned3 from an SM-DP+ server (Page 31, paragraph 5, S604: terminal reads on the claimed LPA) where smdpSigned3 includes a required confirmation code required flag (Page 30, paragraph 11: claim never functionally utilizes the claimed confirmation required flag to perform a device change operation. Therefore, the “for the device change…” language represents intended use. A recitation of the intended use of the claimed invention must result in a structural difference between the claimed invention and the prior art in order to patentably distinguish the claimed invention from the prior art. If the prior art structure is capable of performing the intended use, then it meets the claim), which meets the limitation of receive, from a subscription manager data preparation plus (SM-DP+), an authentication client response message including a confirmation required flag for a device change of the first device to a second device. Yu discloses that the terminal hashes the confirmation code (Page 33, paragraph 2), which meets the limitation of based on the confirmation code, calculating a hashed confirmation code. The terminal sends the calculated hash to the SM-DP+ (Page 33, paragraph 6: LPA sends euiccSigned2 to SM-DP+ and euiccSigned2 includes hashed confirmation code), which meets the limitation of transmit, to the SM-DP+, a confirmation request message for the device change including the hashed confirmation code. Yu discloses that the SM-DP+ verifies the received information and begins configuration file download to the terminal (Page 33, paragraphs 7-8: configuration file reads on the claimed activation code), which meets the limitation of receive, from the SM-DP+, a confirmation response message for the device change including an activation code.
Yu discloses that the terminal hashes the confirmation code (Page 33, paragraph 2), but Yu does not specify that the terminal receives user input of the confirmation code when the required confirmation code required flag is true. Lee discloses receiving a Boolean end user intent confirmation indicator that indicates whether an end user intent confirmation is required to execute a command such that when the end user intent confirmation is required to execute the command, a screen is presented for receiving user input to provide confirmation ([0163]), which meets the limitation of receive from a subscription manager data preparation plus (SM-DP+), an authenticate client response message including a confirmation required flag for a device change, in case that the confirmation required flag for the device change is set to true, receiving an input from a user. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for confirmation code of Yu to have been manually entered by a user in response to the required confirmation code required flag being asserted in order to give the end user the opportunity to consent the changes as suggested by Lee ([0148] & [0163]).
Referring to claim 11, Yu describes a two-way authentication process between the LPA and the SM-DP+ (Page 30, paragraph 8) that includes the terminal transmitting an initial authenticaiotn message to the SM-DP+ that includes eUICC information (Page 39, paragraphs 1-2), which meets the limitation of transmit, to the SM-DP+, an authenticate client request message for the device change, wherein the authenticate client request message for the device change further includes an embedded universal integrated circuit card (eUICC) identifier (EID).
Referring to claim 12, Yu discloses event processing wherein an SM-DP+ server that includes a transmitter 1502, a receiver 1503, and a processor 1501 (Page 58, paragraphs 5-9), which meets the limitation of a subscription manager data preparation plus (SM-DP+) in a wireless communication system supporting a device change, the SM-DP+ comprising a transceiver, and a controller coupled with the transceiver. The SM-DP+ transmits smdpSigned3 to a terminal (Page 31, paragraph 5, S604: terminal reads on the claimed LPA) where smdpSigned3 includes a required confirmation code required flag (Page 30, paragraph 11: claim never functionally utilizes the claimed confirmation required flag to perform a device change operation. Therefore, the “for the device change…” language represents intended use. A recitation of the intended use of the claimed invention must result in a structural difference between the claimed invention and the prior art in order to patentably distinguish the claimed invention from the prior art. If the prior art structure is capable of performing the intended use, then it meets the claim), which meets the limitation of transmit, to a first local profile assistant (LPA) of a first device, an authenticate client response message including a confirmation required flag for the device change of the first device to a second device, wherein the confirmation required flag for the device change is set to true. The SM-DP+ receives the hash of a confirmation code from the terminal (Page 33, paragraphs 2 & 6: LPA sends euiccSigned2 to SM-DP+ and euiccSigned2 includes hashed confirmation code), which meets the limitation of receive, from the first LPA of the first device, a confirmation request message for the device change including a hashed confirmation code. The SM-DP+ verifies the received euiccSigned2 (Page 33, paragraph 7), which meets the limitation of verify the hashed confirmation code. The SM-DP+ verifies the received information and begins configuration file download to the terminal (Page 33, paragraphs 7-8: configuration file reads on the claimed activation code), which meets the limitation of transmit, to the first LPA of the first device, a confirmation response message for the device change including an activation code.
Yu discloses that the terminal hashes the confirmation code (Page 33, paragraph 2), which meets the limitation of wherein the hashed confirmation code is based on a confirmation code [by receiving an input from a user]. Yu does not specify that the terminal receives user input of the confirmation code when the required confirmation code required flag is true. Lee discloses receiving a Boolean end user intent confirmation indicator that indicates whether an end user intent confirmation is required to execute a command such that when the end user intent confirmation is required to execute the command, a screen is presented for receiving user input to provide confirmation ([0163]), which meets the limitation of based on a confirmation code by receiving an input from a user. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for confirmation code of Yu to have been manually entered by a user in response to the required confirmation code required flag being asserted in order to give the end user the opportunity to consent the changes as suggested by Lee ([0148] & [0163]).
Referring to claim 13, Yu describes a two-way authentication process between the LPA and the SM-DP+ (Page 30, paragraph 8) that includes the terminal transmitting an initial authenticaiotn message to the SM-DP+ that includes eUICC information (Page 39, paragraphs 1-2), which meets the limitation of receive, from the first LPA of the first device, an authenticate client request message for the device change, wherein the authenticate client request message for the device change further includes an embedded universal integrated circuit card (eUICC) identifier (EID).
Referring to claim 15, Yu discloses that the terminal hashes the confirmation code and includes the hashed confirmation code in the euiccSigned2 along with a session identifier (Page 33, paragraph 2), which meets the limitation of wherein the hashed confirmation code is calculated based on a confirmation code [by receiving the input from the user] and a transaction identifier (ID).
Yu does not specify that the terminal receives user input of the confirmation code when the required confirmation code required flag is true. Lee discloses receiving a Boolean end user intent confirmation indicator that indicates whether an end user intent confirmation is required to execute a command such that when the end user intent confirmation is required to execute the command, a screen is presented for receiving user input to provide confirmation ([0163]), which meets the limitation of wherein the hashed confirmation code is calculated based on a confirmation code by receiving the input from the user. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for confirmation code of Yu to have been manually entered by a user in response to the required confirmation code required flag being asserted in order to give the end user the opportunity to consent the changes as suggested by Lee ([0148] & [0163]).
Referring to claim 16, Yu discloses that the processing event can include the deletion of a configuration file (Page 17, paragraph 7), which meets the limitation of wherein the confirmation response message for the device change further includes information for deleting a profile.
The terminal hashes the confirmation code and includes the hashed confirmation code in the euiccSigned2 along with a session identifier (Page 33, paragraph 2), which meets the limitation of wherein the hashed confirmation code is calculated based on a transaction identifier (ID).
Referring to claim 17, Yu discloses that the processing event can include the deletion of a configuration file (Page 17, paragraph 7), which meets the limitation of wherein the confirmation response message for the device change further includes information for deleting a profile.
The terminal hashes the confirmation code and includes the hashed confirmation code in the euiccSigned2 along with a session identifier (Page 33, paragraph 2), which meets the limitation of wherein the hashed confirmation code is calculated based on a transaction identifier (ID).
Claims 6, 14 are rejected under 35 U.S.C. 103 as being unpatentable over Yu, WO 2019095948, in view of Lee, U.S. Publication No. 2020/0137572, and further in view of Park, WO 2020171475. Referring to claim 6, Yu discloses that the terminal sends the calculated hash to the SM-DP+ (Page 33, paragraph 6) such that the SM-DP+ verifies the received information and begins configuration file download to the terminal (Page 33, paragraphs 7-8)
Yu does not specify that the SM-DP+ transmits a message to a service provider for verification.
Park discloses that the SM-DP+ transmits request message information that includes an ICCID to an operator server for verification (Page 32, first full paragraph), which meets the limitation of transmitting, to a service provider, a request message for the device change including the ICCID. If the verification passes a response message is received (Page 32, second full paragraph: Examiner notes that what the message “indicates” does not receive patentable weight. See MPEP 2111.04-2111.05), which meets the limitation of as a response to the request message for the device change, receiving, from the service provider, at least one of information indicating that a new profile is required or a confirmation code. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the SM-DP+ of Yu to have transmitted a request message to a server in order to verify terminal information because Park discloses that such procedure is one of a finite number of possible embodiments that could have been implemented by one of ordinary skill in the art with a reasonable expectation of success (Park: Page 32, first full paragraph).
Referring to claim 14, Yu discloses that the terminal sends the calculated hash to the SM-DP+ (Page 33, paragraph 6) such that the SM-DP+ verifies the received information and begins configuration file download to the terminal (Page 33, paragraphs 7-8)
Yu does not specify that the SM-DP+ transmits a message to a service provider for verification.
Park discloses that the SM-DP+ transmits request message information that includes an ICCID to an operator server for verification (Page 32, first full paragraph), which meets the limitation of transmit, to a service provider, a request message for the device change including the ICCID. If the verification passes a response message is received (Page 32, second full paragraph: Examiner notes that what the message “indicates” does not receive patentable weight. See MPEP 2111.04-2111.05), which meets the limitation of as a response to the request message for the device change, receive, from the service provider, at least one of information indicating that a new profile is required or a confirmation code. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the SM-DP+ of Yu to have transmitted a request message to a server in order to verify terminal information because Park discloses that such procedure is one of a finite number of possible embodiments that could have been implemented by one of ordinary skill in the art with a reasonable expectation of success (Park: Page 32, first full paragraph).
Allowable Subject Matter
Claims 2, 10 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BENJAMIN E LANIER whose telephone number is (571)272-3805. The examiner can normally be reached M-Th: 5:30-4:00.
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, Alexander Lagor can be reached at 5712705143. 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.
/BENJAMIN E LANIER/Primary Examiner, Art Unit 2437
Prosecution Insights