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 .
Response to Amendment
Applicant’s amendment filed 17 March 2026 amends claims 1-7 and 9-15. Claim 8 has been cancelled. Claims 16 and 17 have been added. Applicant’s amendment has been fully considered and entered.
Response to Arguments
Applicant argues on pages 14-15 of the response, “Therefore, the claims are not a mental process that can be performed in a human mind, but operates on the premise of interoperability between specific hardware and software within current wireless communication standards, such as GSMA (eSIM standard)….According to MPEP § 2106.05, claims that bring an improvement to a technological field are considered to be integrated into a practical application…The present application does not simply receive a confirmation code, but proposes a conditional security protocol that ‘receives a user input and performs hashing only in the case where the confirmation required flag is set to true.’ This can prevent unnecessary waste of network resources and strengthen security.” This argument has been fully considered and is persuasive. Therefore, the previous §101 rejections have been withdrawn.
Applicant argues on page 17 of the response, “First, the ‘token’ in paragraphs [0053]-[0055] of Chauhan does not correspond to the ‘confirmation required flag’ in Claim 1…That is, the ‘token’ of Chauhan is information for obtaining an identifier for the eUICC, whereas the ‘confirmation required flag’ in Claim 1 is for obtaining a confirmation code through user input…” This argument has been fully considered and is persuasive. Therefore, the previous rejections have been withdrawn.
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 (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 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.
Claims 4, 5, 12, 13, 17 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Yu, WO 2019095948. 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: Examiner notes that the value assigned to the claimed flag would be considered to be non-functional descriptive material since the value of the flag is not functionally utilized in the claim. See MPEP 2111.04-2111.05), 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 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.
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 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: Examiner notes that the value assigned to the claimed flag would be considered to be non-functional descriptive material since the value of the flag is not functionally utilized in the claim. See MPEP 2111.04-2111.05), 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 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.
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 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).
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, 7, 9, 11, 15, 16 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), 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. 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 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 an input from a 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 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 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), 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. 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 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 an input from a 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 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 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).
Claims 6, 14 are rejected under 35 U.S.C. 103 as being unpatentable over Yu, WO 2019095948, 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, 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).
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
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 BENJAMIN E LANIER whose telephone number is (571)272-3805. The examiner can normally be reached M-Th: 6:20-4:50.
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