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 Arguments
Applicant’s arguments with respect to newly amended claims 1, 6, 11, and 16 have been considered but are moot in view of new grounds of rejection based on a new reference Xu et al. (US 2020/0228488 A1).
On pg. 8, par. 2 of Applicant’s Response, applicant argues that claim 1 is patentable because the cited references do not disclose or suggest that an eUICC selects a target port and explicitly notifies an LPA of the port number of the selected target port. The Office Action concedes that Kim does not disclose "the target profile is a target port for the profile", relying on the disclosure of Yin to allegedly teach "a target port for a target profile." However, such a combination relies on an unreasonable interpretation of Kim and Yin to correlate the enabling(determination) of a "profile" with the enabling (determination) of a "port." For example, assuming that ports #1, #2, #3, and #4 exist, even if the combination of Kim and Yin teaches that a single port is mapped to a profile to be enabled, this merely implies that one of the available ports (e.g., port #1, #2, #3, or #4) is assigned to that profile. This is different from Claim 1, in which the eUICC actively determines (selects) a specific port (e.g., port #3) for the profile under the specific condition where a refresh flag is not set.
Examiner respectfully disagrees with applicant’s argument.
Kim states in par. 97, “In operation 421, the electronic device may enable the target profile. The LPA module may transmit an enable request message to the eUICC. Depending on the enable request message, the eUICC may disable the enabled profile and may enable the target profile (~enabling a certain target profile is selecting the certain target profile to enable). The electronic device may transmit a refresh flag together with the enable request message. The refresh flag may be set to ‘false’ (~under the specific condition where a refresh flag is not set)”.
Kim does not explicitly teach that enabling (~selects - selecting required to enable the selected) a target profile is enabling (~selects - selecting required to enable the selected) a target profile port and is thus combined with Yin to remedy the deficiency.
Yin states on col. 8 lines 37-38, “each enabled profile (~target profile) 168a-b has (~consists of) a separate respective logical interface (~target profile port) 212a-b”, wherein since the target profile has (~consists of) a logical interface (~target profile port), enabling (~selecting) the target profile is enabling (~selecting) the logical interface (~target profile port).
On pg. 8, par. 3 of Applicant’s Response, applicant argues that furthermore, the Office Action asserts that since Kim states that the eUICC may enable the target profile "depending on the enable request message," in paragraph [0097], that setting the refresh flag to 'false' results in the eUICC enabling the target profile. The Applicant respectfully disagrees. In Kim, the eUICC enables or disables a profile depending on the enable request message, and the condition 'refresh flag =false' merely indicates that the refresh operation is to be omitted. Kim does not disclose or suggest the feature of Claim 1 where the eUICC selects a specific target port for the profile to be enabled when the refresh flag is not set.
Examiner respectfully disagrees with applicant’s argument. Kim states in par.97, “Depending on the enable request message, the eUICC may disable the enabled profile and may enable the target profile. The electronic device may transmit a refresh flag together with the enable request message (~refresh flag contained in the enable request message). The refresh flag may be set to ‘false’ (~refresh flag is not set)”, wherein, in case the enable request message contains a “false” refresh flag (~refresh flag is not set), eUICC enables (~selects - selecting required to enable the selected) the target profile; Note: enabling (~selecting - selecting required to enable the selected) of target profile depends on the enable request message and since the enable request message contains a “false” refresh flag (~refresh flag is not set), the enabling of the target profile depends on the “false” refresh flag (~refresh flag is not set).
Kim does not explicitly teach that enabling (~selecting - selecting is required to enable) the target profile is enabling (~selecting - selecting is required to enable) the target profile port and is thus combined with Yin to remedy the deficiency.
Yin states on col. 8 lines 37-38, “each enabled profile (~target profile) 168a-b has (~consists of) a separate respective logical interface (~target profile port) 212a-b”, wherein since the target profile has (~consists of) a logical interface (~target profile port), enabling (~selecting) the target profile is enabling (~selecting) the logical interface (~target profile port).
5. On pg. 9, par. 2 of Applicant’s Response, applicant argues that moreover, the cited reference does not disclose or suggest that a second message including information indicating a target port is sent to an LPA as a response to a refresh flag not being set in first message. Instead, the proposed combination of Kim and Yin at best discloses the following sequence of events: 1. The eUICC receives an enable request message (first message) from an LPA that includes a refresh flag set to false. (Kim, para. [0097]). 2. The eUICC restores a connection of the target profile based on receiving the message. (Kim, para. [0098]). The connection may have an associated target port (Yin). 3. The eUICC receives a profile request message (second message) from the LPA. 4. The eUICC transmits profile information (third message) to the LPA in response to the second message. (Kim, para. [0099]). The profile information may include information about the associated target port. (Yin). The profile information is not
transmitted in response to an enable request message.
Examiner respectfully disagrees with applicant’s argument.
Note: in Fig. 4, step 417 (~second message - target profile information) is in response to step 421 (~first message - refresh flag not being set). Similarly, steps described in par. 99 is in response to steps described in par. 97; To reiterate, as shown by arrows in Fig. 4, step 417 occurs in response to step 421.
Fig. 4 of Kim, the second message (~Fig. 4 step 417 and [0099], “perform operation 417 ... LPA module ... obtain profile information (~second message) from the eUICC. The profile information ... indicate that ... the target profile is in an enable state”) is sent as a response to the first message (~Fig. 4 step 421 and [0097], “LPA module may transmit an enable request message (~first message) to the eUICC ... (~for) enable (~of) the target profile (~includes information indicating the target profile)”).
Kim states in par. 99, “LPA module may transmit a profile information request message to the eUICC and may obtain profile information (~second message) from the eUICC. The profile information received from the eUICC may indicate that the enabled profile is in a disable state and the target profile is in an enable state”.
Kim states in par. 97, “LPA module may transmit an enable request message (~first message) to the eUICC. Depending on the enable request message, the eUICC may disable the enabled profile and may enable the target profile. The electronic device may transmit a refresh flag together with the enable request message. The refresh flag may be set to ‘false’”.
Fig. 4, step 421 ([0097], in case refresh flag not set in the first message; as a response to the first message (~Fig. 4 step 421 and [0097], “LPA module may transmit an enable request message (~first message) to the eUICC”) [Wingdings font/0xE0] Fig. 4, step 417 ([0099], obtaining, from the eUICC, a second message including information indicating a target profile)).
Kim does not explicitly teach that enabling (~selecting - selecting is required to enable) the target profile is enabling (~selecting - selecting is required to enable) the target profile port and is thus combined with Yin to remedy the deficiency.
Yin states on col. 8 lines 37-38, “each enabled profile (~target profile) 168a-b has (~consists of) a separate respective logical interface (~target profile port) 212a-b”, wherein since the target profile has (~consists of) a logical interface (~target profile port), enabling (~selecting) the target profile is enabling (~selecting) the logical interface (~target profile port).
Claim Rejections - 35 USC § 103
6. 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.
7. 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.
8. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kim (US 2018/0249322 A1) in view of Yin (US 10,708,761 B1), and further in view of Xu (US 2020/0228488 A1).
Regarding claim 1, Kim teaches a method performed by an embedded universal integrated circuit card (eUICC) in a device in a wireless communication system ([0052], “Referring to FIG. 2, the electronic device 100 may include an application processor (AP) 111, a communication processor (CP) 113, an eUICC 121, the memory 130, and the RF circuit 140”; Fig. 2), the method comprising:
receiving, obtaining, from a local profile assistant (LPA) in the device, a first message to enable a profile, the first message including an identifier of the profile ([0097], “LPA module may transmit an enable request message to the eUICC. Depending on the enable request message, the eUICC may disable the enabled profile and may enable the target profile”, wherein the enable request message includes an identifier of the profile to be enabled);
in case that a refresh flag is not set in the first message, selecting a target profile ([0097], in case that the enable request message contains a refresh flag set to ‘false’, reset is not performed, and a target profile is determined and enabled; [0097], “Depending on the enable request message, the eUICC may disable the enabled profile and may enable the target profile (~enabling a certain target profile is selecting the certain target profile to enable). The electronic device may transmit a refresh flag together with the enable request message. The refresh flag may be set to ‘false’”); and
sending, to the LPA, a second message as a response to the first message, the second message including information indicating the selected target profile (Fig. 4, the second message (~Fig. 4 step 417 and [0099], “perform operation 417 ... LPA module ... obtain profile information (~second message) from the eUICC. The profile information is sent as a response to the first message (~Fig. 4 step 421 and [0097], “LPA module may transmit an enable request message (~first message) to the eUICC ... (~for) enable (~of) the target profile (~includes information indicating the selected target profile)”); [0099], “LPA module may transmit a profile information request message to the eUICC and may obtain profile information (~second message) from the eUICC. The profile information received from the eUICC may indicate that the enabled profile is in a disable state and the target profile is in an enable state”; [0097], “LPA module may transmit an enable request message (~first message) to the eUICC. Depending on the enable request message, the eUICC may disable the enabled profile and may enable the target profile. The electronic device may transmit a refresh flag together with the enable request message. The refresh flag may be set to ‘false’”; Fig. 4, step 421 ([0097], in case refresh flag not set in the first message) [Wingdings font/0xE0] step 417 ([0099], obtaining, from the eUICC, a second message including information indicating a target profile) as a response to the first message (~Fig. 4 step 421 and [0097], “LPA module may transmit an enable request message (~first message) to the eUICC”)).
Kim does not explicitly teach that the target profile is a target port for the target profile
However, Yin teaches a target port for a target profile (Fig. 2B, target port 212a (~logical interface) for profile A 168a; col. 8 lines 1-40, “a user device 160 with an eSIM chip 166 includes a single physical interface 210c. The single physical interface 210c may be multiplexed to support multiple logical interfaces 212a-b. Here, the first communication interface 200a includes the first logical interface 212a multiplexed from the single physical interface 210c and the second communication interface 200b includes the second logical interface 212b multiplexed from the single physical interface 210c. That is, each enabled profile 168a-b has a separate respective logical interface 212a-b as in FIG. 2A, but shares the single physical interface 210c via, for example, the T=1 transmission protocol”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Yin with the teaching of Kim in order to effectively communicate with a profile accessible via an associated port or a logical interface among a plurality of ports or logical interfaces multiplexed in a single physical interface, providing capability to handle priority and increase in bandwidth.
The combination does not explicitly teach that the information indicating the target port is information indicating a port number of the target port.
However, Xu teaches information indicating a port number of a target port ([0116], “Profile Information Database 1530 can notify a container which has capacity to initiate another USIM instance with its profile index information such as ICCID or EID. A container 1670 receives an instruction of creating an USIM instance with profile index information ICCID or EID, and starts a process of an USIM instance with basis info such as ICCID and EID. Further, the new started instance 1680 further accesses profile information elements, such as IMSI, SPN, PIN, PAK, etc., to complete the rest process of an USIM instance. Once the instance is completed 1690, the USIM instance access information (e.g., ICCID, IMSI, Container ID, IP address, Port Number, etc.) are sent back to Virtual SIM Driver and Container Manager 1550 so that the Virtual SIM Driver and Container Manager 1550 can forward its received APDU Payload to an associated USIM instance via IP, Port number or Container ID, etc.”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Xu with the teaching of Kim as modified by Yin in order to ensures secure communication between the eUICC and the remote management platform.
Regarding claim 2, Kim in view of Yin, and further in view of Xu teaches the method of claim 1.
The combination of Kim and Xu does not explicitly teach wherein the selecting of the target port for the profile further comprises: determining an embedded subscriber identity module (eSIM) port which currently has no enabled profile as the target port.
However, Yin further teaches wherein selecting of a target port for a profile further comprises: determining an embedded subscriber identity module (eSIM) port which currently has no enabled profile as a target port (when profile c is disabled, eSIM port 212b currently has no enabled profile as a target port (see Fig. 3 and col. 9 lines 28-29), and this eSIM port is selected as a target port for newly enabled profile B; col. 9 lines 28-29, “Profile C 168c may be disabled and Profile B 168b subsequently assigned to interface 212b and enabled. The user 10 would then gain access to the services 169 authorized by Profile C 168c”; Fig. 3).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Yin with the teaching of Kim as modified by Yin and Xu in order to effectively communicate with a profile accessible via an associated port or a logical interface among a plurality of ports or logical interfaces multiplexed in a single physical interface, providing capability to handle priority and increase in bandwidth.
Regarding claim 3, Kim in view of Yin, and further in view of Xu teaches the method of claim 1,
wherein the selecting of the target port for the profile further comprises: disabling a currently enabled profile (Kim [0085], “eUICC may disable the enabled profile (~enabling a certain target profile is selecting the certain target profile to enable)); and
enabling the profile (Kim [0085], “and may enable the target profile”).
The combination of Kim and Xu does not explicitly teach that the profiles are on the target port.
However, Yin further teaches a profile on a target port (each profile is associated with a separate logical interface (~target port) and enabling a profile requires sending a logical interface (~target port) information of the profile to be enabled; col. 8 lines 1-40, “a user device 160 with an eSIM chip 166 includes a single physical interface 210c. The single physical interface 210c may be multiplexed to support multiple logical interfaces 212a-b. Here, the first communication interface 200a includes the first logical interface 212a multiplexed from the single physical interface 210c and the second communication interface 200b includes the second logical interface 212b multiplexed from the single physical interface 210c. That is, each enabled profile 168a-b has a separate respective logical interface 212a-b as in FIG. 2A, but shares the single physical interface 210c via, for example, the T=1 transmission protocol”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Yin with the teaching of Kim as modified by Yin and Xu in order to effectively communicate with a profile accessible via an associated port or a logical interface among a plurality of ports or logical interfaces multiplexed in a single physical interface, providing capability to handle priority and increase in bandwidth.
Regarding claim 4, Kim in view of Yin, and further in view of Xu teaches the method of claim 1.
The combination of Kim and Xu does not explicitly teach wherein the first message is obtained on a predetermined port which is different from the target port.
However, Yin further teaches wherein a message is obtained on a predetermined port which is different from a target port (Fig. 3, a message (~such as an enable/disable request message) can be obtained on port 212a which is different than port 212b (~target port)).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Yin with the teaching of Kim as modified by Yin and Xu in order to effectively communicate with a profile accessible via an associated port or a logical interface among a plurality of ports or logical interfaces multiplexed in a single physical interface, providing capability to handle priority and increase in bandwidth.
Regarding claim 5, Kim in view of Yin, and further in view of Xu teaches the method of claim 1,
wherein the eUICC supports multiple enabled profiles (Kim [0138], “eUICC 121 included in an electronic device may store a plurality of profiles”; [0095], “LPA module may update the profile list based on the obtained profile information. Since the profile information indicates the profile state of the eUICC, the state of the target profile may be displayed as an enabled state. The LPA module may update the profile list for the purpose of indicating that a plurality of profiles are in the enabled state”).
Regarding claim 6, Kim teaches a method performed by a local profile assistant (LPA) in a device in a wireless communication system (Fig. 2, LPA 160 in electronic device 100; [0052], “Referring to FIG. 2, the electronic device 100 may include an application processor (AP) 111, a communication processor (CP) 113, an eUICC 121, the memory 130, and the RF circuit 140”; [0055], “LPA module 160 may support the profile management of the eUICC 121”),
the method comprising: identifying a profile to be enabled ([0079], Referring to FIG. 4, a processor (e.g., the processor 110), an LPA module (e.g., the LPA module 160), or a SIM manager module (e.g., the SIM manager module 170) may perform profile enable or multi-profile enable depending on user selection. Hereinafter, in the description about FIG. 4, it is assumed that one profile is enabled in an eUICC (e.g., the eUICC 121). In the following description, at least one or more profiles enabled in the eUICC may be referred to “enabled profile”, and a profile selected by a user for the purpose of enabling the profile may be referred to as “target profile””);
sending, to the an embedded universal integrated circuit card (eUICC) in the device, a first message to enable the profile, the first message including an identifier of the profile ([0097], “LPA module may transmit an enable request message to the eUICC. Depending on the enable request message, the eUICC may disable the enabled profile and may enable the target profile”, wherein the enable request message includes an identifier of the profile to be enabled); and
in case that a refresh flag is not set in the first message, obtaining, from the eUICC, a second message as a response to the first message, the second message including information indicating a target profile selected by the eUICC (Fig. 4, step 421 ([0097], in case refresh flag not set in the first message) [Wingdings font/0xE0] step 417 ([0099], obtaining, from the eUICC, a second message including information indicating a target profile) as a response to the first message (~Fig. 4 step 421 and [0097], “LPA module may transmit an enable request message (~first message) to the eUICC”); Fig. 4, the second message (~Fig. 4 step 417 and [0099], “perform operation 417 ... LPA module ... obtain profile information (~second message) from the eUICC. The profile information ... indicate that ... the target profile is in an enable state”) is obtained as a response to the first message (~Fig. 4 step 421 and [0097], “LPA module may transmit an enable request message (~first message) to the eUICC ... may enable the target profile (~enabling a certain target profile is selecting the certain target profile to enable)”); [0099], “LPA module may transmit a profile information request message to the eUICC and may obtain profile information (~second message) from the eUICC. The profile information received from the eUICC may indicate that the enabled profile is in a disable state and the target profile is in an enable state”; [0097], “LPA module may transmit an enable request message (~first message) to the eUICC. Depending on the enable request message, the eUICC may disable the enabled profile and may enable the target profile (~enabling a certain target profile is selecting the certain target profile to enable). The electronic device may transmit a refresh flag together with the enable request message (~first message). The refresh flag may be set to ‘false’ (~in case that a refresh flag is not set in the first message)”).
Kim does not explicitly teach that the target profile is a target port for the profile.
However, Yin teaches a target port for a profile (Fig. 2B, target port 212a (~logical interface) for profile A 168a; col. 8 lines 1-40, “a user device 160 with an eSIM chip 166 includes a single physical interface 210c. The single physical interface 210c may be multiplexed to support multiple logical interfaces 212a-b. Here, the first communication interface 200a includes the first logical interface 212a multiplexed from the single physical interface 210c and the second communication interface 200b includes the second logical interface 212b multiplexed from the single physical interface 210c. That is, each enabled profile 168a-b has a separate respective logical interface 212a-b as in FIG. 2A, but shares the single physical interface 210c via, for example, the T=1 transmission protocol”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Yin with the teaching of Kim in order to effectively communicate with a profile accessible via an associated port or a logical interface among a plurality of ports or logical interfaces multiplexed in a single physical interface, providing capability to handle priority and increase in bandwidth.
The combination does not explicitly teach the information indicating the target port is information indicating a port number of the target port.
However, Xu teaches information indicating a port number of a target port ([0116], “Profile Information Database 1530 can notify a container which has capacity to initiate another USIM instance with its profile index information such as ICCID or EID. A container 1670 receives an instruction of creating an USIM instance with profile index information ICCID or EID, and starts a process of an USIM instance with basis info such as ICCID and EID. Further, the new started instance 1680 further accesses profile information elements, such as IMSI, SPN, PIN, PAK, etc., to complete the rest process of an USIM instance. Once the instance is completed 1690, the USIM instance access information (e.g., ICCID, IMSI, Container ID, IP address, Port Number, etc.) are sent back to Virtual SIM Driver and Container Manager 1550 so that the Virtual SIM Driver and Container Manager 1550 can forward its received APDU Payload to an associated USIM instance via IP, Port number or Container ID, etc.”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Xu with the teaching of Kim as modified by Yin in order to ensures secure communication between the eUICC and the remote management platform.
Regarding claim 7, Kim in view of Yin, and further in view of Xu teaches the method of claim 6,
further comprising: discarding cached information from a previously enabled profile on the target (Kim [0091] “In the case where the target profile is not the previously enabled profile, in operation 413, the electronic device may update the connection information of the enabled profile (~cached information from a previous enabled profile is discarded from the update of the enabled profile information) or may update the connection information table. The PSC module may store the enable state of the enabled profile, channel information or session information of the client connected to the corresponding profile, or the like”); and performing a network attach procedure based on the profile on the target (Kim [0107], “electronic device may perform the network communication associated with the profile of the enable state”).
The combination of Kim and Xu does not explicitly teach that the target is a target port.
However, Yin further teaches a port (each profile is associated with a separate logical interface (~target port) and enabling a profile requires sending a logical interface (~target port) information of the profile to be enabled; col. 8 lines 1-40, “a user device 160 with an eSIM chip 166 includes a single physical interface 210c. The single physical interface 210c may be multiplexed to support multiple logical interfaces 212a-b. Here, the first communication interface 200a includes the first logical interface 212a multiplexed from the single physical interface 210c and the second communication interface 200b includes the second logical interface 212b multiplexed from the single physical interface 210c. That is, each enabled profile 168a-b has a separate respective logical interface 212a-b as in FIG. 2A, but shares the single physical interface 210c via, for example, the T=1 transmission protocol”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Yin with the teaching of Kim as modified by Yin and Xu in order to effectively communicate with a profile accessible via an associated port or a logical interface among a plurality of ports or logical interfaces multiplexed in a single physical interface, providing capability to handle priority and increase in bandwidth.
Regarding claim 8, Kim in view of Yin, and further in view of Xu teaches the method of claim 6,
wherein the profile to be enabled is identified based on a user input (Kim [0079], Referring to FIG. 4, a processor (e.g., the processor 110), an LPA module (e.g., the LPA module 160), or a SIM manager module (e.g., the SIM manager module 170) may perform profile enable or multi-profile enable depending on user selection. Hereinafter, in the description about FIG. 4, it is assumed that one profile is enabled in an eUICC (e.g., the eUICC 121). In the following description, at least one or more profiles enabled in the eUICC may be referred to “enabled profile”, and a profile selected by a user for the purpose of enabling the profile may be referred to as “target profile””).
Regarding claim 9, Kim in view of Yin, and further in view of Xu teaches the method of claim 6.
The combination of Kim and Xu does not explicitly teach wherein the first message is obtained on a predetermined port which is different from the target port.
However, Yin further teaches wherein a first message is obtained on a predetermined port which is different than a target port (Fig. 3 and Fig. 2B, a message can be sent on port 212a which is different than port 212b (~target port)).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Yin with the teaching of Kim as modified by Yin and Xu in order to effectively communicate with a profile accessible via an associated port or a logical interface among a plurality of ports or logical interfaces multiplexed in a single physical interface, providing capability to handle priority and increase in bandwidth.
Regarding claim 10, Kim in view of Yin, and further in view of Xu teaches the method of claim 6,
wherein the device supports multiple enabled profiles (Kim [0138], “eUICC 121 included in an electronic device may store a plurality of profiles”; [0095], “LPA module may update the profile list based on the obtained profile information. Since the profile information indicates the profile state of the eUICC, the state of the target profile may be displayed as an enabled state. The LPA module may update the profile list for the purpose of indicating that a plurality of profiles are in the enabled state”).
Regarding claim 11, Kim teaches an embedded universal integrated circuit card (eUICC) in a device in a wireless communication system, the eUICC configured to ([0052], “Referring to FIG. 2, the electronic device 100 may include an application processor (AP) 111, a communication processor (CP) 113, an eUICC 121, the memory 130, and the RF circuit 140”; Fig. 2):
obtain, from a local profile assistant (LPA) in the device, a first message to enable a profile, the first message including an identifier of the profile ([0097], “LPA module may transmit an enable request message to the eUICC. Depending on the enable request message, the eUICC may disable the enabled profile and may enable the target profile”, wherein the enable request message includes an identifier of the profile to be enabled),
in case that a refresh flag is not set in the first message, select a target profile ([0097], in case that the enable request message (~first message) contains a refresh flag set to ‘false’, reset is not performed, and a target profile is determined and enabled; [0097], “Depending on the enable request message (~first message), the eUICC may disable the enabled profile and may enable the target profile (~enabling a certain target profile is selecting the certain target profile to enable). The electronic device may transmit a refresh flag together with the enable request message. The refresh flag may be set to ‘false’ (~refresh flag is not set)”), and
send, to the LPA, a second message as a response to the first message, the second message including information indicating the selected target profile (Fig. 4, the second message (~Fig. 4 step 417 and [0099], “perform operation 417 ... LPA module ... obtain profile information from the eUICC. The profile information ... indicate that ... the target profile is in an enable state”) is sent as a response to the first message (~Fig. 4 step 421 and [0097], “LPA module may transmit an enable request message to the eUICC ... (~for) enable (~of) the target profile (~includes information indicating the target profile)”); [0099], “LPA module may transmit a profile information request message to the eUICC and may obtain profile information from the eUICC. The profile information received from the eUICC may indicate that the enabled profile is in a disable state and the target profile is in an enable state”; [0097], “LPA module may transmit an enable request message to the eUICC. Depending on the enable request message, the eUICC may disable the enabled profile and may enable the target profile. The electronic device may transmit a refresh flag together with the enable request message. The refresh flag may be set to ‘false’”; Fig. 4, step 421 ([0097], in case refresh flag not set in the first message) [Wingdings font/0xE0] step 417 ([0099], send, to the LPA, a second message including information indicating a target profile) as a response to the first message (~Fig. 4 step 421 and [0097], “LPA module may transmit an enable request message (~first message) to the eUICC”)).
Kim does not explicitly teach that the target profile is a target port for the profile.
However, Yin teaches a target port for a profile (Fig. 2B, target port 212a (~logical interface) for profile A 168a; col. 8 lines 1-40, “a user device 160 with an eSIM chip 166 includes a single physical interface 210c. The single physical interface 210c may be multiplexed to support multiple logical interfaces 212a-b. Here, the first communication interface 200a includes the first logical interface 212a multiplexed from the single physical interface 210c and the second communication interface 200b includes the second logical interface 212b multiplexed from the single physical interface 210c. That is, each enabled profile 168a-b has a separate respective logical interface 212a-b as in FIG. 2A, but shares the single physical interface 210c via, for example, the T=1 transmission protocol”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Yin with the teaching of Kim in order to effectively communicate with a profile accessible via an associated port or a logical interface among a plurality of ports or logical interfaces multiplexed in a single physical interface, providing capability to handle priority and increase in bandwidth.
The combination does not explicitly teach that the information indicating the target port is information indicating a port number of the target port.
However, Xu teaches information indicating a port number of a target port ([0116], “Profile Information Database 1530 can notify a container which has capacity to initiate another USIM instance with its profile index information such as ICCID or EID. A container 1670 receives an instruction of creating an USIM instance with profile index information ICCID or EID, and starts a process of an USIM instance with basis info such as ICCID and EID. Further, the new started instance 1680 further accesses profile information elements, such as IMSI, SPN, PIN, PAK, etc., to complete the rest process of an USIM instance. Once the instance is completed 1690, the USIM instance access information (e.g., ICCID, IMSI, Container ID, IP address, Port Number, etc.) are sent back to Virtual SIM Driver and Container Manager 1550 so that the Virtual SIM Driver and Container Manager 1550 can forward its received APDU Payload to an associated USIM instance via IP, Port number or Container ID, etc.”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Xu with the teaching of Kim as modified by Yin in order to ensures secure communication between the eUICC and the remote management platform.
Regarding claim 12, Kim in view of Yin, and further in view of Xu teaches the eUICC of claim 11.
The combination of Kim and Xu does not explicitly teach wherein the eUICC is further configured to: determine an embedded subscriber identity module (eSIM) port which currently has no enabled profile as the target port.
However, Yin further teaches wherein an eUICC is further configured to: select an embedded subscriber identity module (eSIM) port which currently has no enabled profile as a target port (when profile c is disabled, eSIM port 212b currently has no enabled profile as a target port (see Fig. 3 and col. 9 lines 28-29), and this eSIM port is determined (~selected) as a target port for newly enabled profile B; col. 9 lines 28-29, “Profile C 168c may be disabled and Profile B 168b subsequently assigned to interface 212b and enabled. The user 10 would then gain access to the services 169 authorized by Profile C 168c”; Fig. 3).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Yin with the teaching of Kim as modified by Yin and Xu in order to effectively communicate with a profile accessible via an associated port or a logical interface among a plurality of ports or logical interfaces multiplexed in a single physical interface, providing capability to handle priority and increase in bandwidth.
Regarding claim 13, Kim in view of Yin, and further in view of Xu teaches the eUICC of claim 11,
wherein the eUICC is further configured to: disable a currently enabled profile (Kim [0085], “eUICC may disable the enabled profile”), and enable the profile (Kim [0085], “and may enable the target profile”).
The combination of Kim and Xu does not explicitly teach that the profiles are on the target port.
However, Yin further teaches a profile on a target port (each profile is associated with a separate logical interface (~target port) and enabling a profile requires sending a logical interface (~target port) information of the profile to be enabled; col. 8 lines 1-40, “a user device 160 with an eSIM chip 166 includes a single physical interface 210c. The single physical interface 210c may be multiplexed to support multiple logical interfaces 212a-b. Here, the first communication interface 200a includes the first logical interface 212a multiplexed from the single physical interface 210c and the second communication interface 200b includes the second logical interface 212b multiplexed from the single physical interface 210c. That is, each enabled profile 168a-b has a separate respective logical interface 212a-b as in FIG. 2A, but shares the single physical interface 210c via, for example, the T=1 transmission protocol”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Yin with the teaching of Kim as modified by Yin and Xu in order to effectively communicate with a profile accessible via an associated port or a logical interface among a plurality of ports or logical interfaces multiplexed in a single physical interface, providing capability to handle priority and increase in bandwidth.
Regarding claim 14, Kim in view of Yin, and further in view of Xu teaches the eUICC of claim 11.
The combination of Kim and Xu does not explicitly teach wherein the first message is obtained on a predetermined port different than the target port.
However, Yin further teaches wherein a first message is obtained on a predetermined port which is different from a target port (Fig. 3, a message (~such as an enable/disable request message) can be obtained on port 212a which is different than port 212b (~target port)).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Yin with the teaching of Kim as modified by Yin and Xu in order to effectively communicate with a profile accessible via an associated port or a logical interface among a plurality of ports or logical interfaces multiplexed in a single physical interface, providing capability to handle priority and increase in bandwidth.
Regarding claim 15, Kim in view of Yin, and further in view of Xu teaches the eUICC of claim 11,
wherein the eUICC supports multiple enabled profiles (Kim [0138], “eUICC 121 included in an electronic device may store a plurality of profiles”; [0095], “LPA module may update the profile list based on the obtained profile information. Since the profile information indicates the profile state of the eUICC, the state of the target profile may be displayed as an enabled state. The LPA module may update the profile list for the purpose of indicating that a plurality of profiles are in the enabled state”).
Regarding claim 16, Kim teaches a device in a wireless communication system, comprising a local profile assistant (LPA) wherein the LPA is (Fig. 2, LPA 160 in electronic device 100; [0052], “Referring to FIG. 2, the electronic device 100 may include an application processor (AP) 111, a communication processor (CP) 113, an eUICC 121, the memory 130, and the RF circuit 140”; [0055], “LPA module 160 may support the profile management of the eUICC 121”) configured to:
identify a profile to be enabled ([0079], Referring to FIG. 4, a processor (e.g., the processor 110), an LPA module (e.g., the LPA module 160), or a SIM manager module (e.g., the SIM manager module 170) may perform profile enable or multi-profile enable depending on user selection. Hereinafter, in the description about FIG. 4, it is assumed that one profile is enabled in an eUICC (e.g., the eUICC 121). In the following description, at least one or more profiles enabled in the eUICC may be referred to “enabled profile”, and a profile selected by a user for the purpose of enabling the profile may be referred to as “target profile””),
send, to an embedded universal integrated circuit card (eUICC) in the device, a first message to enable the profile, the first message including an identifier of the profile ([0097], “LPA module may transmit an enable request message to the eUICC. Depending on the enable request message, the eUICC may disable the enabled profile and may enable the target profile”, wherein the enable request message includes an identifier of the profile to be enabled), and
in case that a refresh flag is not set in the first message ([0097], “Depending on the enable request message, the eUICC may disable the enabled profile and may enable the target profile. The electronic device may transmit a refresh flag together with the enable request message (~refresh flag in the first message). The refresh flag may be set to ‘false’ (~refresh flag is not set)”),
obtain, from the eUICC, a second message as a response to the first message, the second message including information indicating a target profile selected by the eUICC (Fig. 4, the second message (~Fig. 4 step 417 and [0099], “perform operation 417 ... LPA module ... obtain profile information from the eUICC. The profile information ... indicate that ... the target profile is in an enable state”) is obtained as a response to the first message (~Fig. 4 step 421 and [0097], “LPA module may transmit an enable request message to the eUICC ... (~for) enable (~of) the target profile (~includes information indicating the target profile)”); [0099], “LPA module may transmit a profile information request message to the eUICC and may obtain profile information from the eUICC. The profile information received from the eUICC may indicate that the enabled profile is in a disable state and the target profile is in an enable state”; [0097], “LPA module may transmit an enable request message to the eUICC. Depending on the enable request message, the eUICC may disable the enabled profile and may enable the target profile (~enabling a certain target profile is selecting the certain target profile to enable). The electronic device may transmit a refresh flag together with the enable request message. The refresh flag may be set to ‘false’”; Fig. 4, step 421 ([0097], in case refresh flag not set in the first message) [Wingdings font/0xE0] step 417 ([0099], obtaining, from the eUICC, a second message including information indicating a target profile) as a response to the first message (~Fig. 4 step 421 and [0097], “LPA module may transmit an enable request message (~first message) to the eUICC”)).
Kim does not explicitly teach that the target profile is a target port for the profile.
However, Yin teaches a target port for a profile (Fig. 2B, target port 212a (~logical interface) for profile A 168a; col. 8 lines 1-40, “a user device 160 with an eSIM chip 166 includes a single physical interface 210c. The single physical interface 210c may be multiplexed to support multiple logical interfaces 212a-b. Here, the first communication interface 200a includes the first logical interface 212a multiplexed from the single physical interface 210c and the second communication interface 200b includes the second logical interface 212b multiplexed from the single physical interface 210c. That is, each enabled profile 168a-b has a separate respective logical interface 212a-b as in FIG. 2A, but shares the single physical interface 210c via, for example, the T=1 transmission protocol”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Yin with the teaching of Kim in order to effectively communicate with a profile accessible via an associated port or a logical interface among a plurality of ports or logical interfaces multiplexed in a single physical interface, providing capability to handle priority and increase in bandwidth.
The combination does not explicitly teach that the information indicating the target port is information indicating a port number of the target port.
However, Xu teaches information indicating a port number of a target port ([0116], “Profile Information Database 1530 can notify a container which has capacity to initiate another USIM instance with its profile index information such as ICCID or EID. A container 1670 receives an instruction of creating an USIM instance with profile index information ICCID or EID, and starts a process of an USIM instance with basis info such as ICCID and EID. Further, the new started instance 1680 further accesses profile information elements, such as IMSI, SPN, PIN, PAK, etc., to complete the rest process of an USIM instance. Once the instance is completed 1690, the USIM instance access information (e.g., ICCID, IMSI, Container ID, IP address, Port Number, etc.) are sent back to Virtual SIM Driver and Container Manager 1550 so that the Virtual SIM Driver and Container Manager 1550 can forward its received APDU Payload to an associated USIM instance via IP, Port number or Container ID, etc.”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Xu with the teaching of Kim as modified by Yin in order to ensures secure communication between the eUICC and the remote management platform.
Regarding claim 17, Kim in view of Yin, and further in view of Xu teaches the device of claim 16,
wherein the LPA is further configured to: discard cached information from a previously enabled profile (Kim [0089], when LPA receives updated profile information from eUICC, cached information from a previous enabled profile will be replaced or discarded; [0089], “eUICC may transmit profile information to the LPA module, as a response to the profile information request message. The profile information may include at least one of the states of profiles or the metadata of a profile”), and perform a network attach procedure based on the profile on the target (Kim [0107], “electronic device may perform the network communication associated with the profile of the enable state”).
The combination of Kim and Xu does not explicitly teach that the previously enabled profile is a previous enabled profile on the target port.
However, Yin further teaches a previously enabled profile on a target port (Fig. 2B, previous enabled profile A 168a on a target port 212a (~logical interface); col. 8 lines 1-40, “a user device 160 with an eSIM chip 166 includes a single physical interface 210c. The single physical interface 210c may be multiplexed to support multiple logical interfaces 212a-b. Here, the first communication interface 200a includes the first logical interface 212a multiplexed from the single physical interface 210c and the second communication interface 200b includes the second logical interface 212b multiplexed from the single physical interface 210c. That is, each enabled profile 168a-b has a separate respective logical interface 212a-b as in FIG. 2A, but shares the single physical interface 210c via, for example, the T=1 transmission protocol”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Yin with the teaching of Kim as modified by Yin in order to effectively communicate with a profile accessible via an associated port or a logical interface among a plurality of ports or logical interfaces multiplexed in a single physical interface, providing capability to handle priority and increase in bandwidth.
Regarding claim 18, Kim in view of Yin, and further in view of Xu teaches the device of claim 16,
wherein the profile to be enabled is identified based on a user input (Kim [0079], Referring to FIG. 4, a processor (e.g., the processor 110), an LPA module (e.g., the LPA module 160), or a SIM manager module (e.g., the SIM manager module 170) may perform profile enable or multi-profile enable depending on user selection. Hereinafter, in the description about FIG. 4, it is assumed that one profile is enabled in an eUICC (e.g., the eUICC 121). In the following description, at least one or more profiles enabled in the eUICC may be referred to “enabled profile”, and a profile selected by a user for the purpose of enabling the profile may be referred to as “target profile””).
Regarding claim 19, Kim in view of Yin, and further in view of Xu teaches the device of claim 16.
The combination of Kim and Xu does not explicitly teach wherein the first message is obtained on a predetermined port different than the target port.
However, Yin further teaches wherein a first message is obtained on a predetermined port which is different from a target port (Fig. 3, a message (~such as an enable/disable request message) can be obtained on port 212a which is different than port 212b (~target port)).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Yin with the teaching of Kim as modified by Yin and Xu in order to effectively communicate with a profile accessible via an associated port or a logical interface among a plurality of ports or logical interfaces multiplexed in a single physical interface, providing capability to handle priority and increase in bandwidth.
Regarding claim 20, Kim in view of Yin, and further in view of Xu teaches the device of claim 16, wherein the device supports multiple enabled profiles (Kim [0138], “eUICC 121 included in an electronic device may store a plurality of profiles”; [0095], “LPA module may update the profile list based on the obtained profile information. Since the profile information indicates the profile state of the eUICC, the state of the target profile may be displayed as an enabled state. The LPA module may update the profile list for the purpose of indicating that a plurality of profiles are in the enabled state”).
Conclusion
9. 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 ALEXANDER J. YI whose telephone number is (571)270-7696. The examiner can normally be reached Monday thru Friday: 8:00AM to 5PM 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, Jinsong Hu can be reached at (571)272-3965. 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.
/ALEXANDER J YI/Examiner, Art Unit 2643
/CHARLES N APPIAH/Supervisory Patent Examiner, Art Unit 2641
Prosecution Insights