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 .
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.
1. Claims 1-2, 5, 10-11, 14 and 19-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Fares et al (2020/0120494).
Regarding claims 1, 10 and 19. Fares teaches a program, system (figure 6, 0055 – SM-DP++ server comprises memory, processor, and program), and a method of providing a network profile for an Embedded Universal Integrated Circuit Card (eUICC), the method comprising:
storing, in a server, profile records corresponding to each of users (figures 1A, 1B, and figures 6-7, 0004, 0008-0009, 0020 – SM-DP++ server stores Protected Profiles corresponding to each of users, 0057 – SM-DP++ technology enables a single Protected Profile (710A) (e.g., single ICCID1, IMSI1) to be used as two separate Bound Profiles (740A, 740B) wherein the first Bound Profile 740A is for 4G/LTE and the second Bound Profile 740B is for 5G (0003));
generating, for a first user that is one of the users, a first profile corresponding to a first communication protocol (figure 7, 0056-0057 – SM-DP++ technology enables a single Protected Profile (710A) (e.g., single ICCID1, IMSI1) to be used as two separate Bound Profiles (740A, 740B) wherein the first Bound Profile 740A is for 4G/LTE (e.g., first communication protocol) and the second Bound Profile 740B is for 5G (0003)),
generating, for the first user, a second profile corresponding to a second communication protocol (figure 7, 0056-0057 – SM-DP++ technology enables a single Protected Profile (710A) (e.g., single ICCID1, IMSI1) to be used as two separate Bound Profiles (740A, 740B) wherein the first Bound Profile 740A is for 4G/LTE (e.g., first communication protocol) and the second Bound Profile 740B is for 5G (e.g., a second communication protocol) (0003));
incorporating the first profile and the second profile into a profile record for the first user among the profile records (figure 7, 0056-0057 – SM-DP++ technology enables a single Protected Profile (710A) (e.g., single ICCID1, IMSI1 is used to incorporate the first profile 740A and second profile 740B to be used as two separate Bound Profiles (740A, 740B) wherein the first Bound Profile 740A is for 4G/LTE (e.g., first communication protocol) and the second Bound Profile 740B is for 5G (e.g., a second communication protocol) (0003)); and
in response to a request for downloading a profile of the first user, providing, from the server, an enabled profile among the first profile and the second profile contained in the profile record for the first user, to a user device based on a determined communication protocol to be used by the user device (0003, 0042-0043 – user selects connectivity package and Bound Profile is downloaded from server, 0047 – user is provided data package options regarding LTE, 3G, 5G, etc. (e.g., communication protocol) to select from, the user selects one or more data package options with associated Time of Arrival and Time of Departure (e.g, time-limited), and 0048 – sends the request to the SM-DP++ server and the SM-DP++ server downloads the user selected package options, figure 4, 0049 – user selects communication package options and downloads the profiles. In certain embodiments, this eSIM profile remains un-activated at the MNO until needed at a later time (see figure 10), 0050 – In case where eUICC/eSIM compatibility/capability, is detected, mobile service bundles may be offered as discussed above. 0052 – ARSP is able to dynamically schedule and allocate time-restricted “Protected Profiles” via advanced SM-DP++, 0056 – service validity period may be derived from a trip itinerary with specific date and/or Time of Arrival (TA) and Time of Departure (TD). Alternatively, the service validity period like 1 week, 1 month or 1 year prior to or from a certain date
figure 7, 0056-0058 – SM-DP++ technology enables a single Protected Profile (710A) (e.g., single ICCID1, IMSI1 is used to incorporate the first profile 740A and second profile 740B to be used as two separate Bound Profiles (740A, 740B) wherein the first Bound Profile 740A is for 4G/LTE (e.g., first communication protocol) and the second Bound Profile 740B is for 5G (e.g., a second communication protocol) (0003), figure 9 and 0059 – Generally, to prevent the same Protected Profile from becoming multiple “Bound Profiles” at the same time, SM-DP++ functionality may associate references to Protect Files stored/generated/available on an SM-DP++ with an expected service validity period/time of use (e.g., TA-TD). Accordingly, SM-DP++ may manage Protected and Bound Profiles using received data service request information, 0060-0065 – the Protected and Bound Profiles are maintained using unique reference information, such as IMEIs, ICCIDs, or other information associated with a SIM/UICC, figure 10, 0062 – SM-DP++ activates/deactivates Bound Profiles at the designated time for beginning a service validity period (e.g., TA) … and deactivate at the end of service validity period (e.g., TD));
wherein the first profile and the second profile are eUICC profiles (0006, 0009, 0010, 0057-0058, 0061, 0065, figure 7 – eUICC and/or eSIM), and
wherein storage of the profile record in which the first profile and the second profile are incorporated is maintained in the server after providing the enabled profile to the user device and while the enabled profile is used by the user device (0003, 0042-0043 – user selects connectivity package and Bound Profile is downloaded from server, 0047 – user is provided data package options regarding LTE, 3G, 5G, etc. (e.g., communication protocol) to select from, the user selects one or more data package options with associated Time of Arrival and Time of Departure (e.g, time-limited), and 0048 – sends the request to the SM-DP++ server and the SM-DP++ server downloads the user selected package options, figure 4, 0049 – user selects communication package options and downloads the profiles. In certain embodiments, this eSIM profile remains un-activated at the MNO until needed at a later time (see figure 10), 0050 – In case where eUICC/eSIM compatibility/capability, is detected, mobile service bundles may be offered as discussed above. 0052 – ARSP is able to dynamically schedule and allocate time-restricted “Protected Profiles” via advanced SM-DP++, 0056 – service validity period may be derived from a trip itinerary with specific date and/or Time of Arrival (TA) and Time of Departure (TD). Alternatively, the service validity period like 1 week, 1 month or 1 year prior to or from a certain date
figure 7, 0056-0058 – SM-DP++ technology enables a single Protected Profile (710A) (e.g., single ICCID1, IMSI1 is used to incorporate the first profile 740A and second profile 740B to be used as two separate Bound Profiles (740A, 740B) wherein the first Bound Profile 740A is for 4G/LTE (e.g., first communication protocol) and the second Bound Profile 740B is for 5G (e.g., a second communication protocol) (0003), figure 9 and 0059 – Generally, to prevent the same Protected Profile from becoming multiple “Bound Profiles” at the same time, SM-DP++ functionality may associate references to Protect Files stored/generated/available on an SM-DP++ with an expected service validity period/time of use (e.g., TA-TD). Accordingly, SM-DP++ may manage Protected and Bound Profiles using received data service request information, 0060-0065 – the Protected and Bound Profiles are maintained using unique reference information, such as IMEIs, ICCIDs, or other information associated with a SIM/UICC, figure 10, 0062 – SM-DP++ activates/deactivates Bound Profiles at the designated time for beginning a service validity period (e.g., TA) … and deactivate at the end of service validity period (e.g., TD)).
Regarding claims 2, 11, and 20. Fares teaches incorporating the first profile and the second profile into the profile record comprises: associating the first profile and the second profile with a same eUICC identification number in the profile record (figures 1A, 1B, and figures 6-7, 0004, 0008-0009, 0020 – SM-DP++ server stores Protected Profiles corresponding to each of users, 0057 – SM-DP++ technology enables a single Protected Profile (710A) (e.g., single ICCID1, IMSI1 = same eUICC identification number) to be used as two separate Bound Profiles (740A, 740B) wherein the first Bound Profile 740A is for 4G/LTE and the second Bound Profile 740B is for 5G (0003)).
Regarding claims 5 and 14. Fares teaches wherein the first communication protocol is associated with one generation of wireless technology and the second communication protocol is associated with another generation of wireless technology (figures 1A, 1B, and figures 6-7, 0004, 0008-0009, 0020 – SM-DP++ server stores Protected Profiles corresponding to each of users, 0057 – SM-DP++ technology enables a single Protected Profile (710A) (e.g., single ICCID1, IMSI1 = same eUICC identification number) to be used as two separate Bound Profiles (740A, 740B) wherein the first Bound Profile 740A is for 4G/LTE and the second Bound Profile 740B is for 5G (0003)).
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.
2. Claims 1, 2, 5-8, 10, 11, 14-17,and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over D1 (W0 2019/184658 – ZTE Corporation found on IDS 6/20/2023) in view Nitsch et al (2024/0365106) or LI et al (2021/0160683) further in view of Fares et al (2020/0120494).
Regarding claims 1, 10 and 19. D1 teaches a program, system, and a method of providing a network profile for an Embedded Universal Integrated Circuit Card (eUICC) (abstract – switching between profiles in the eSIM card), the method comprising:
generating a first profile corresponding to a first communication protocol abstract – switching between profiles in the eSIM card, (page 3 – generating a first profile for China Mobile wherein China Mobile is the first protocol);
generating a second profile corresponding to a second communication protocol (page 3 – generating a second profile for China Telecom wherein China Telecom is the second protocol);
associating the first profile and the second profile with a same profile record (page 3 – the eSIM receives the profile package of multiple profiles and parses (e.g., associating) the profile package file in the present format and stores the parsed multiple profiles) ; and
providing either the first profile or the second profile to a user device based on a determined communication protocol, from among the first communication protocol and the second communication protocol, to be used by the user device (abstract page 3 – provide the profile package (e.g., first and second profiles) to the eSIM card (user device) to switch from a currently used profile to the second profile),
wherein the first profile and the second profile are eUICC profiles (abstract, page 3 – the first and second profiles are profiles in the eSIM).
Regarding amendment dated 7/10/2025. Applicant amends and generally argues prior art does not teach “
Nitsch teaches storing and/or generating in a server comprising, memory, program, and process profile records corresponding to each users (abstract, figure 1, 0099 – User 1 (U1) has a first profile P = P1(U1) incorporated with a second profile P = P2(U1) wherein the first profile is 4G profile and the second profile is 5G profile wherein the first profile and second profile are incorporated by assigning both to the same profile number ICCID having the value 123456, , 0071 – network technologies are 2G, 3G, 4G, 5G, GSM, UMTS, CDMA, LTE). Similarly, for the second user (see figure 1, 0100 – User 2 (U2) has first profile P = P1(U2) incorporated with a second profile P = P2(U2) and associated with the same ICCID 789012). Advantageously, by the present solution, the overall amount and/or volume of required communications between the profile server and the eUICc upon profile download and installation shall be reduced so as to reduce time and/or cost and/or risk or failure due to communication interrupts (00020).
LI teaches network server comprising memory, program, processor for generating multiple eSIMs using an identical eSIM identifier (ICCID) (abstract, 0002, 0016). A specific wireless device is specified in a download order wherein the order includes a hardware identifier value for the UE, such as an eUICC identifier (EID) value (0004, 0017). LI further teaches the server selects the ICCID value to associate with a set of eSIMs for the UE (0024).
It would have been obvious for one of ordinary skill in the art before the effective filing date to modify D1 to use an eUICC identifier (ICCID) as taught by Nitsch OR LI in order to enable the download of different profiles corresponding to different wireless communication standards (4G and 5G), as well as, reduce network signaling.
Regarding RCE 12/22/2025. D1 in view of Nitsch or LI do not teach but Fares teaches wherein storage of the profile record in which the first profile and the second profile are incorporated is maintained in the server after providing the enabled profile to the user device and while the enabled profile is used by the user device.
(figure 6, 0055 – SM-DP++ server comprises memory, processor, and program, 0003, 0042-0043 – user selects connectivity package and Bound Profile is downloaded from server, 0047 – user is provided data package options regarding LTE, 3G, 5G, etc. (e.g., communication protocol) to select from, the user selects one or more data package options with associated Time of Arrival and Time of Departure (e.g, time-limited), and 0048 – sends the request to the SM-DP++ server and the SM-DP++ server downloads the user selected package options, figure 4, 0049 – user selects communication package options and downloads the profiles. In certain embodiments, this eSIM profile remains un-activated at the MNO until needed at a later time (see figure 10), 0050 – In case where eUICC/eSIM compatibility/capability, is detected, mobile service bundles may be offered as discussed above. 0052 – ARSP is able to dynamically schedule and allocate time-restricted “Protected Profiles” via advanced SM-DP++, 0056 – service validity period may be derived from a trip itinerary with specific date and/or Time of Arrival (TA) and Time of Departure (TD). Alternatively, the service validity period like 1 week, 1 month or 1 year prior to or from a certain date
figure 7, 0056-0058 – SM-DP++ technology enables a single Protected Profile (710A) (e.g., single ICCID1, IMSI1 is used to incorporate the first profile 740A and second profile 740B to be used as two separate Bound Profiles (740A, 740B) wherein the first Bound Profile 740A is for 4G/LTE (e.g., first communication protocol) and the second Bound Profile 740B is for 5G (e.g., a second communication protocol) (0003), figure 9 and 0059 – Generally, to prevent the same Protected Profile from becoming multiple “Bound Profiles” at the same time, SM-DP++ functionality may associate references to Protect Files stored/generated/available on an SM-DP++ with an expected service validity period/time of use (e.g., TA-TD). Accordingly, SM-DP++ may manage Protected and Bound Profiles using received data service request information, 0060-0065 – the Protected and Bound Profiles are maintained using unique reference information, such as IMEIs, ICCIDs, or other information associated with a SIM/UICC, figure 10, 0062 – SM-DP++ activates/deactivates Bound Profiles at the designated time for beginning a service validity period (e.g., TA) … and deactivate at the end of service validity period (e.g., TD)).
It would have been obvious for one of ordinary skill in the art before the effective filing date to modify D1 in view of Nitsch OR LI to use Bound Profiles with validity period/time as taught by Fares in order to enable the user to pre-purchase (e.g., at the travel booking stage) mobile connectivity (e.g., profile for 5G and/or profile for LTE/4G) for use with their device during upcoming international travel wherein the service can then be activated ant the time/date of arrival for the selected travel period (Fares at 0038, 0050, 0057).
Regarding claims 2, 11, and 20. D1 does not teach wherein the
Nitsch teaches storing and/or generating in a server, profile records corresponding to each users (abstract, figure 1, 0099 – User 1 (U1) has a first profile P = P1(U1) incorporated with a second profile P = P2(U1) wherein the first profile is 4G profile and the second profile is 5G profile wherein the first profile and second profile are incorporated by assigning both to the same profile number ICCID having the value 123456, , 0071 – network technologies are 2G, 3G, 4G, 5G, GSM, UMTS, CDMA, LTE). Similarly, for the second user (see figure 1, 0100 – User 2 (U2) has first profile P = P1(U2) incorporated with a second profile P = P2(U2) and associated with the same ICCID 789012). Advantageously, by the present solution, the overall amount and/or volume of required communications between the profile server and the eUICc upon profile download and installation shall be reduced so as to reduce time and/or cost and/or risk or failure due to communication interrupts (00020).
LI teaches generating multiple eSIMs using an identical eSIM identifier (abstract, 0002, 0016). A specific wireless device is specified in a download order wherein the order includes a hardware identifier value for the UE, such as an eUICC identifier (EID) value (0004, 0017).
Fares teaches incorporating the first profile and the second profile into the profile record comprises: associating the first profile and the second profile with a same eUICC identification number in the profile record figures 1A, 1B, and figures 6-7, 0004, 0008-0009, 0020 – SM-DP++ server stores Protected Profiles corresponding to each of users, 0057 – SM-DP++ technology enables a single Protected Profile (710A) (e.g., single ICCID1, IMSI1 = same eUICC identification number) to be used as two separate Bound Profiles (740A, 740B) wherein the first Bound Profile 740A is for 4G/LTE and the second Bound Profile 740B is for 5G (0003)).
It would have been obvious for one of ordinary skill in the art before the effective filing date to modify D1 to use an eUICC identifier (ICCID) as taught by Nitsch OR LI OR Fares in order to enable the download of different profiles corresponding to different wireless communication standards (4G and 5G), as well as, reduce network signaling.
Regarding claims 5 and 14. D1 does not teach wherein the first communication protocol is associated with one generation of wireless technology and the second communication protocol is associated with another generation of wireless technology.
Nitsch teaches storing and/or generating in a server, profile records corresponding to each users (abstract, figure 1, 0099 – User 1 (U1) has a first profile P = P1(U1) incorporated with a second profile P = P2(U1) wherein the first profile is 4G profile and the second profile is 5G profile wherein the first profile and second profile are incorporated by assigning both to the same profile number ICCID having the value 123456, , 0071 – network technologies are 2G, 3G, 4G, 5G, GSM, UMTS, CDMA, LTE). Similarly, for the second user (see figure 1, 0100 – User 2 (U2) has first profile P = P1(U2) incorporated with a second profile P = P2(U2) and associated with the same ICCID 789012). Advantageously, by the present solution, the overall amount and/or volume of required communications between the profile server and the eUICc upon profile download and installation shall be reduced so as to reduce time and/or cost and/or risk or failure due to communication interrupts (00020).
LI teaches generating multiple eSIMs using an identical eSIM identifier (abstract – first protocol for 5G and second protocol that excludes 5G), 0002, 0016). A specific wireless device is specified in a download order wherein the order includes a hardware identifier value for the UE, such as an eUICC identifier (EID) value (0004, 0017 – profiles for different wireless communication standards).
Fares teaches wherein the first communication protocol is associated with one generation of wireless technology and the second communication protocol is associated with another generation of wireless technology (figures 1A, 1B, and figures 6-7, 0004, 0008-0009, 0020 – SM-DP++ server stores Protected Profiles corresponding to each of users, 0057 – SM-DP++ technology enables a single Protected Profile (710A) (e.g., single ICCID1, IMSI1 = same eUICC identification number) to be used as two separate Bound Profiles (740A, 740B) wherein the first Bound Profile 740A is for 4G/LTE and the second Bound Profile 740B is for 5G (0003)).
It would have been obvious for one of ordinary skill in the art before the effective filing date to modify D1 to use an eUICC identifier (ICCID) as taught by Nitsch OR LI or Fares in order to enable the download of different profiles corresponding to different wireless communication standards (4G and 5G), as well as, reduce network signaling.
Regarding claims 6 and 15. D1 does not teach wherein the generating the second profile comprises altering a copy of the first profile.
LI teaches generating multiple eSIMs using an identical eSIM identifier (abstract – first protocol for 5G and second protocol that excludes 5G), 0002, 0016). A specific wireless device is specified in a download order wherein the order includes a hardware identifier value for the UE, such as an eUICC identifier (EID) value (0004, 0017 – profiles for different wireless communication standards).
LI further teaches the first profile includes 5G information and the second profile excludes 5G information (0004) based on UE capabilities (0016). Each eSIM of the multiple eSIMs include a set of common eSIM configuration data … and capabilities of the UE are used to determine which profiles are to be downloaded and/or excluded (e.g., deleted) to the UE (0017).
It would have been obvious for one of ordinary skill in the art before the effective filing date to modify D1 to use a download order that includes an eUICC identifier (EID) as taught by LI in order to enable the server to determine the UE capabilities so that proper profile(s) may be downloaded to the UE.
Regarding claims 7 and 16. D1 does not teach wherein the altering the copy of the first profile comprises deleting information in the first profile that is specific to the first communication protocol.
LI teaches generating multiple eSIMs using an identical eSIM identifier (abstract – first protocol for 5G and second protocol that excludes 5G), 0002, 0016). A specific wireless device is specified in a download order wherein the order includes a hardware identifier value for the UE, such as an eUICC identifier (EID) value (0004, 0017 – profiles for different wireless communication standards).
LI further teaches the first profile includes 5G information and the second profile excludes 5G information (0004) based on UE capabilities (0016). Each eSIM of the multiple eSIMs include a set of common eSIM configuration data … and capabilities of the UE are used to determine which profiles are to be downloaded and/or excluded (e.g., deleted) to the UE (0017)
It would have been obvious for one of ordinary skill in the art before the effective filing date to modify D1 to use a download order that includes an eUICC identifier (EID) as taught by LI in order to enable the server to determine the UE capabilities so that proper profile(s) may be downloaded to the UE.
Regarding claims 8 and 17. D1 teaches receiving user device information from the user device; and determining whether to provide, to the user device, the first profile or the second profile based on the received user device information (abstract, page 2 wherein eSIM receives an instruction (e.g., determining whether to provide) through a preset interface to switch from China mobile number to China telecom number (e.g., user device information).
3. Claims 3, 4, 12 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over D1 (W0 2019/184658 – ZTE Corporation found on IDS 6/20/2023) in view Nitsch et al (2024/0365106) or LI et al (2021/0160683) and Fares (2020/0120494) further in view of LEE et al (2021/0006964).
Regarding claims 3 and 12. D1 in view of Nitsch OR LI and Fares do not teach wherein the associating the first profile and the second profile with the same profile record further comprises: associating the first profile and the second profile with a same mobile telephone number in the profile record.
LEE teaches downloading a second profile from the server (0147). In an embodiment, an MSISDN of the second profile may be identical to an MSISDN of the first profile of the first SIM. In an embodiment, an IMSI included in the second profile may be identical to or different from an IMSI of the first profile. For example, the IMSI included in the second profile may be identical to or different from the IMSI of the first profile, according to a policy of the communication operator (0148).
It would have been obvious for one of ordinary skill in the art before the effective filing date to modify D1 in view of Nitsch OR LI and Fares to use the MSISDN as taught by LEE in order to enable the user to keep the same telephone number when using different eUICC profiles.
Regarding claims 4 and 13. D1 in view of Nitsch OR LI and Fares do not teach wherein the associating the first profile and the second profile with the same profile record comprises: associating the first profile and the second profile with a same Mobile Station International Subscriber Directory Number (MSISDN) and a same international mobile subscriber identity number in the same profile record.
LEE teaches downloading a second profile from the server (0147). In an embodiment, an MSISDN of the second profile may be identical to an MSISDN of the first profile of the first SIM. In an embodiment, an IMSI included in the second profile may be identical to or different from an IMSI of the first profile. For example, the IMSI included in the second profile may be identical to or different from the IMSI of the first profile, according to a policy of the communication operator (0148).
It would have been obvious for one of ordinary skill in the art before the effective filing date to modify D1 in view of Nitsch OR LI and Fares to associate MSISDN and IMSI as taught by LEE in order to enable the network operator set eSIM policies (LEE at 0148) while enabling the user the ability to keep the same telephone number when using different eUICC profiles.
4. Claims 9 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over D1 (W0 2019/184658 – ZTE Corporation found on IDS 6/20/2023) in view Nitsch et al (2024/0365106) or LI et al (2021/0160683) and Fares (2020/0120494) further in view of Lee et al (2022/0326959).
Regarding claims 9 and 18. D1 in view of Nitsch OR LI and Fares do not teach wherein the receiving the user device information comprises receiving the user device information based on a quick response code or other machine-readable code provided to and scanned by the user device.
Lee teaches the user uses the camera of the UE to scan QR code enabling the user a quick and easy way to download eUICC profile(s) (figure 3, 0088-0093).
It would have been obvious for one of ordinary skill in the art before the effective filing date to modify D1 in view of Nitsch OR LI and Fares to use the QR code as taught by LEE in order to enable the user a convenient way to download eUICC profile(s).
Response to Arguments
5. Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
6. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
---(2019/0253563) Ullah et al also teaches wherein storage of the profile record in which the first profile and the second profile are incorporated is maintained in the server after providing the enabled profile to the user device and while the enabled profile is used by the user device (0047, 0055-0056, 0067, 0076).
7. Any inquiry concerning this communication or earlier communications from the examiner should be directed to BARRY W TAYLOR whose telephone number is (571)272-7509. The examiner can normally be reached Monday-Thursday: 7-5.
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, Matthew Anderson can be reached at 571-272-4177. 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.
/BARRY W TAYLOR/Primary Examiner, Art Unit 2646