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 .
Information Disclosure Statement
The Information Disclosure Statement documents filed 05/16/2025, 08/25/2025, 01/12/2026, and 01/28/2026, have been fully considered by examiner and entered into record.
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-4, 7, 10, 11-14, 17, and 20 are rejected under 35 U.S.C. 102(a)(1) & 102(a)(2) as being anticipated by Krishnaswamy et al (US 2010/0017861).
Regarding Claim 1, Krishnaswamy teaches a method ([0060], Fig. 5 illustrating example architecture of MVNO 112) comprising:
receiving, by a graphical user interface at a mobile virtual network operator, a request ([0061], Fig. 5, Access request 504 can be associated with a client such as client 104, and may include client credentials, client preferences, and client-connection parameters 530. Access request 504 may be transmitted from client 104 to MVNO 102, via an available MNO 106, when client 104 attempts to establish a communication session)
to verify whether a network switch is available for the mobile virtual network operator to switch a client from a source mobile network operator that is serving the client for the mobile virtual network operator to a target mobile network operator that is serving clients for the mobile virtual network operator ([0068], Fig. 5, Handover manager 514 can facilitate switching client 104 to a second MNO during the communication session when the system reaches a predetermined threshold, such as with respect to load or link quality (e.g., as determined by network monitor 510). It should be appreciated that in some aspects MVNO 102 can initiate the switch to the second MNO. Additionally or alternatively, the original hosting MNO can transmit a request to MVNO 102 to make the switch. In either case, handover manager 514 can be adapted to utilize information provided by network monitor 510 in order to switch client 104 to another MNO. In addition, handover manager 514 can also manage handover events that do not relate to link quality or system load. For example, handover manager 514 can facilitate a switch from one carrier to another or from one access point to another access point within a single carrier's network, e.g., when client 104 changes location); and
outputting automatically, by the graphical user interface at the mobile virtual network operator based on an analysis of attributes of at least the client and the target mobile network operator ([0069], Fig. 5, MNO evaluator 512 may include one or both of network-based optimization rules 536 and client-based optimization rules 538, each of which may guide the definition of option (s) 532 and/or the selected communication session/MNO 536 to achieve a desired result, e.g. a network-based end value, such as minimizing the use of network resources, balancing network load, etc., or a client-based end value, such as reducing energy/battery consumption, providing a desired service quality, or providing a desired price, etc. For example, option(s) 532 and/or selected communication session/MNO 534 may be based at least in part upon information obtained by network monitor 510, such as MVNO connection parameters 528, or based at least in part on client-connection parameters 530, or based at least in part on a combination of both MVNO connection parameters 528 and client-connection parameters 530),
a positive answer indicating that the network switch is available for the mobile virtual network operator to switch the client from the source mobile network operator that is serving the client for the mobile virtual network operator to the target mobile network operator that is serving clients for the mobile virtual network operator ([0070], Fig. 5, client 104 may not be able to utilize all MNOs in a given region and/or all MNOs from the set of MNOs available to MVNO 102. Thus, MNO evaluator 512 can select the suitable MNO based upon a limited subset of MNOs that are available to client 104. Further detailed, infra, in connection with price comparator 506, client 104 can choose the MNO to employ for the communication session or provide input for the selection. In one embodiment, MNO evaluator 512 can reduce or narrow the set of MNO's from which client 104 can choose for hosting the MNO and/or exclude MNO's from a list of MNO's provided to client 104 for selection).
Regarding Claim 2, Krishnaswamy teaches the method of claim 1, wherein the analysis comprises: a first check of checking automatically, by the graphical user interface at the mobile virtual network operator in response to receiving the request, whether an international mobile equipment identity of a device of the client is covered by the target mobile network operator to return a first value ([0061], Fig. 5, Access request 504 can be associated with a client such as client 104, and may include client credentials, client preferences, and client-connection parameters 530. Access request 504 may be transmitted from client 104 to MVNO 102, via an available MNO 106, when client 104 attempts to establish a communication session such as communication session 108 (FIG. 1). Client credentials may be information, such as an IMEI, a phone number, a token, etc., that identify a client or an allowed service for the client. Client preferences may include but are not limited to threshold values such as a quality of service threshold, a desired throughput threshold, and the like, [0063], Credential manager 502 can authenticate or reject the client 104, based on client credentials that may accompany access request 504, for communication session 108 and may transmit a response to MNO 106 to forward to client 104);
a second check of checking automatically, by the graphical user interface at the mobile virtual network operator in response to receiving the request, whether a geographic location of the client is covered by the target mobile network operator to return a second value ([0068], Fig. 5, handover manager 514 can facilitate a switch from one carrier to another or from one access point to another access point within a single carrier's network, e.g., when client 104 changes location, [0070], client 104 may not be able to utilize all MNOs in a given region and/or all MNOs from the set of MNOs available to MVNO 102. Thus, MNO evaluator 512 can select the suitable MNO based upon a limited subset of MNOs that are available to client 104. Further detailed, infra, in connection with price comparator 506, client 104 can choose the MNO to employ for the communication session or provide input for the selection. In one embodiment, MNO evaluator 512 can reduce or narrow the set of MNO's from which client 104 can choose for hosting the MNO and/or exclude MNO's from a list of MNO's provided to client 104 for selection); or
a third check of checking automatically, by the graphical user interface at the mobile virtual network operator in response to receiving the request, whether the target mobile network operator provides a target configuration that satisfies a consistency policy with a source configuration on which the source mobile network operator is providing telecommunication service to the client to return a third value (Embodiment not invoked).
Regarding Claim 3, Krishnaswamy teaches the method of claim 2, wherein the third check checks automatically whether the target configuration and the source configuration are identical (Embodiment not invoked).
Regarding Claim 4, Krishnaswamy teaches the method of claim 2, wherein the positive answer is output automatically based on at least two of the first check, the second check, and the third check being true ([0070], client 104 may not be able to utilize all MNOs in a given region and/or all MNOs from the set of MNOs available to MVNO 102. Thus, MNO evaluator 512 can select the suitable MNO based upon a limited subset of MNOs that are available to client 104. Further detailed, infra, in connection with price comparator 506, client 104 can choose the MNO to employ for the communication session or provide input for the selection. In one embodiment, MNO evaluator 512 can reduce or narrow the set of MNO's from which client 104 can choose for hosting the MNO and/or exclude MNO's from a list of MNO's provided to client 104 for selection).
Regarding Claim 7, Krishnaswamy teaches the method of claim 2, wherein the second check comprises: invoking, by the mobile virtual network operator, a network coverage application programming interface that returns a list of mobile network operators that are serving the mobile virtual network operator and that cover a geographic location of the client; checking whether the target mobile network operator is included within the list of mobile network operators ([0065], Fig. 5, connection module 526 may include network monitor 510, MNO evaluator 512, handover module 514 data manager 516, control manager 518 and intelligence component 520, [0069-0070], MNO evaluator 512 can select the MNO based upon system load, link quality, or a price. It should be appreciated that in some cases, client 104 may not be able to utilize all MNOs in a given region and/or all MNOs from the set of MNOs available to MVNO 102. Thus, MNO evaluator 512 can select the suitable MNO based upon a limited subset of MNOs that are available to client 104. Further detailed, infra, in connection with price comparator 506, client 104 can choose the MNO to employ for the communication session or provide input for the selection. In one embodiment, MNO evaluator 512 can reduce or narrow the set of MNO's from which client 104 can choose for hosting the MNO and/or exclude MNO's from a list of MNO's provided to client 104 for selection).
Regarding Claim 10, Krishnaswamy teaches the method of claim 1, wherein the analysis is performed after the client has already been onboarded with the mobile virtual network operator through the source mobile network operator rather than performing the analysis as part of onboarding the client with the mobile virtual network operator ([0065], Fig. 5, connection module 526 may include network monitor 510, MNO evaluator 512, handover module 514 data manager 516, control manager 518 and intelligence component 520. Connection module 526 is operable to manage the details in setting up and/or maintaining and/or handing off and/or terminating the communication session 108, [0068], Handover manager 514 can facilitate switching client 104 to a second MNO during the communication session))
Regarding Claim 11, Krishnaswamy teaches a system ([0060], Fig. 5 illustrating example architecture of MVNO 112) comprising: at least one physical computing processor of a computing device; and a non-transitory computer-readable medium that has instructions stored thereon that, when executed by the at least one physical computing processor ([0014]), cause the computing device to perform operations comprising:
receiving, by a graphical user interface at a mobile virtual network operator, a request ([0061], Fig. 5, Access request 504 can be associated with a client such as client 104, and may include client credentials, client preferences, and client-connection parameters 530. Access request 504 may be transmitted from client 104 to MVNO 102, via an available MNO 106, when client 104 attempts to establish a communication session)
to verify whether a network switch is available for the mobile virtual network operator to switch a client from a source mobile network operator that is serving the client for the mobile virtual network operator to a target mobile network operator that is serving clients for the mobile virtual network operator ([0068], Fig. 5, Handover manager 514 can facilitate switching client 104 to a second MNO during the communication session when the system reaches a predetermined threshold, such as with respect to load or link quality (e.g., as determined by network monitor 510). It should be appreciated that in some aspects MVNO 102 can initiate the switch to the second MNO. Additionally or alternatively, the original hosting MNO can transmit a request to MVNO 102 to make the switch. In either case, handover manager 514 can be adapted to utilize information provided by network monitor 510 in order to switch client 104 to another MNO. In addition, handover manager 514 can also manage handover events that do not relate to link quality or system load. For example, handover manager 514 can facilitate a switch from one carrier to another or from one access point to another access point within a single carrier's network, e.g., when client 104 changes location); and
outputting automatically, by the graphical user interface at the mobile virtual network operator based on an analysis of attributes of at least the client and the target mobile network operator ([0069], Fig. 5, MNO evaluator 512 may include one or both of network-based optimization rules 536 and client-based optimization rules 538, each of which may guide the definition of option (s) 532 and/or the selected communication session/MNO 536 to achieve a desired result, e.g. a network-based end value, such as minimizing the use of network resources, balancing network load, etc., or a client-based end value, such as reducing energy/battery consumption, providing a desired service quality, or providing a desired price, etc. For example, option(s) 532 and/or selected communication session/MNO 534 may be based at least in part upon information obtained by network monitor 510, such as MVNO connection parameters 528, or based at least in part on client-connection parameters 530, or based at least in part on a combination of both MVNO connection parameters 528 and client-connection parameters 530),
a positive answer indicating that the network switch is available for the mobile virtual network operator to switch the client from the source mobile network operator that is serving the client for the mobile virtual network operator to the target mobile network operator that is serving clients for the mobile virtual network operator ([0070], Fig. 5, client 104 may not be able to utilize all MNOs in a given region and/or all MNOs from the set of MNOs available to MVNO 102. Thus, MNO evaluator 512 can select the suitable MNO based upon a limited subset of MNOs that are available to client 104. Further detailed, infra, in connection with price comparator 506, client 104 can choose the MNO to employ for the communication session or provide input for the selection. In one embodiment, MNO evaluator 512 can reduce or narrow the set of MNO's from which client 104 can choose for hosting the MNO and/or exclude MNO's from a list of MNO's provided to client 104 for selection).
Regarding Claim 12, Krishnaswamy teaches the system of claim 11, wherein the analysis comprises: a first check of checking automatically, by the graphical user interface at the mobile virtual network operator in response to receiving the request, whether an international mobile equipment identity of a device of the client is covered by the target mobile network operator to return a first value ([0061], Fig. 5, Access request 504 can be associated with a client such as client 104, and may include client credentials, client preferences, and client-connection parameters 530. Access request 504 may be transmitted from client 104 to MVNO 102, via an available MNO 106, when client 104 attempts to establish a communication session such as communication session 108 (FIG. 1). Client credentials may be information, such as an IMEI, a phone number, a token, etc., that identify a client or an allowed service for the client. Client preferences may include but are not limited to threshold values such as a quality of service threshold, a desired throughput threshold, and the like, [0063], Credential manager 502 can authenticate or reject the client 104, based on client credentials that may accompany access request 504, for communication session 108 and may transmit a response to MNO 106 to forward to client 104);
a second check of checking automatically, by the graphical user interface at the mobile virtual network operator in response to receiving the request, whether a geographic location of the client is covered by the target mobile network operator to return a second value ([0068], Fig. 5, handover manager 514 can facilitate a switch from one carrier to another or from one access point to another access point within a single carrier's network, e.g., when client 104 changes location, [0070], client 104 may not be able to utilize all MNOs in a given region and/or all MNOs from the set of MNOs available to MVNO 102. Thus, MNO evaluator 512 can select the suitable MNO based upon a limited subset of MNOs that are available to client 104. Further detailed, infra, in connection with price comparator 506, client 104 can choose the MNO to employ for the communication session or provide input for the selection. In one embodiment, MNO evaluator 512 can reduce or narrow the set of MNO's from which client 104 can choose for hosting the MNO and/or exclude MNO's from a list of MNO's provided to client 104 for selection); or
a third check of checking automatically, by the graphical user interface at the mobile virtual network operator in response to receiving the request, whether the target mobile network operator provides a target configuration that satisfies a consistency policy with a source configuration on which the source mobile network operator is providing telecommunication service to the client to return a third value (Embodiment not invoked).
Regarding Claim 13, Krishnaswamy teaches the system of claim 12, wherein the third check checks automatically whether the target configuration and the source configuration are identical (Embodiment not invoked).
Regarding Claim 14, Krishnaswamy teaches the system of claim 12, wherein the system is configured such that the positive answer is output automatically based on at least two of the first check, the second check, and the third check being true ([0070], client 104 may not be able to utilize all MNOs in a given region and/or all MNOs from the set of MNOs available to MVNO 102. Thus, MNO evaluator 512 can select the suitable MNO based upon a limited subset of MNOs that are available to client 104. Further detailed, infra, in connection with price comparator 506, client 104 can choose the MNO to employ for the communication session or provide input for the selection. In one embodiment, MNO evaluator 512 can reduce or narrow the set of MNO's from which client 104 can choose for hosting the MNO and/or exclude MNO's from a list of MNO's provided to client 104 for selection).
Regarding Claim 17, Krishnaswamy teaches the system of claim 12, wherein the second check comprises: invoking, by the mobile virtual network operator, a network coverage application programming interface that returns a list of mobile network operators that are serving the mobile virtual network operator and that cover a geographic location of the client; checking whether the target mobile network operator is included within the list of mobile network operators ([0065], Fig. 5, connection module 526 may include network monitor 510, MNO evaluator 512, handover module 514 data manager 516, control manager 518 and intelligence component 520, [0069-0070], MNO evaluator 512 can select the MNO based upon system load, link quality, or a price. It should be appreciated that in some cases, client 104 may not be able to utilize all MNOs in a given region and/or all MNOs from the set of MNOs available to MVNO 102. Thus, MNO evaluator 512 can select the suitable MNO based upon a limited subset of MNOs that are available to client 104. Further detailed, infra, in connection with price comparator 506, client 104 can choose the MNO to employ for the communication session or provide input for the selection. In one embodiment, MNO evaluator 512 can reduce or narrow the set of MNO's from which client 104 can choose for hosting the MNO and/or exclude MNO's from a list of MNO's provided to client 104 for selection).
Regarding Claim 20, Krishnaswamy teaches a non-transitory computer-readable medium that has instructions stored thereon that, when executed by at least one physical computing processor ([0014]), cause a computing device ([0060], Fig. 5 illustrating example architecture of MVNO 112) to perform operations comprising:
receiving, by a graphical user interface at a mobile virtual network operator, a request ([0061], Fig. 5, Access request 504 can be associated with a client such as client 104, and may include client credentials, client preferences, and client-connection parameters 530. Access request 504 may be transmitted from client 104 to MVNO 102, via an available MNO 106, when client 104 attempts to establish a communication session)
to verify whether a network switch is available for the mobile virtual network operator to switch a client from a source mobile network operator that is serving the client for the mobile virtual network operator to a target mobile network operator that is serving clients for the mobile virtual network operator ([0068], Fig. 5, Handover manager 514 can facilitate switching client 104 to a second MNO during the communication session when the system reaches a predetermined threshold, such as with respect to load or link quality (e.g., as determined by network monitor 510). It should be appreciated that in some aspects MVNO 102 can initiate the switch to the second MNO. Additionally or alternatively, the original hosting MNO can transmit a request to MVNO 102 to make the switch. In either case, handover manager 514 can be adapted to utilize information provided by network monitor 510 in order to switch client 104 to another MNO. In addition, handover manager 514 can also manage handover events that do not relate to link quality or system load. For example, handover manager 514 can facilitate a switch from one carrier to another or from one access point to another access point within a single carrier's network, e.g., when client 104 changes location); and
outputting automatically, by the graphical user interface at the mobile virtual network operator based on an analysis of attributes of at least the client and the target mobile network operator ([0069], Fig. 5, MNO evaluator 512 may include one or both of network-based optimization rules 536 and client-based optimization rules 538, each of which may guide the definition of option (s) 532 and/or the selected communication session/MNO 536 to achieve a desired result, e.g. a network-based end value, such as minimizing the use of network resources, balancing network load, etc., or a client-based end value, such as reducing energy/battery consumption, providing a desired service quality, or providing a desired price, etc. For example, option(s) 532 and/or selected communication session/MNO 534 may be based at least in part upon information obtained by network monitor 510, such as MVNO connection parameters 528, or based at least in part on client-connection parameters 530, or based at least in part on a combination of both MVNO connection parameters 528 and client-connection parameters 530),
a positive answer indicating that the network switch is available for the mobile virtual network operator to switch the client from the source mobile network operator that is serving the client for the mobile virtual network operator to the target mobile network operator that is serving clients for the mobile virtual network operator ([0070], Fig. 5, client 104 may not be able to utilize all MNOs in a given region and/or all MNOs from the set of MNOs available to MVNO 102. Thus, MNO evaluator 512 can select the suitable MNO based upon a limited subset of MNOs that are available to client 104. Further detailed, infra, in connection with price comparator 506, client 104 can choose the MNO to employ for the communication session or provide input for the selection. In one embodiment, MNO evaluator 512 can reduce or narrow the set of MNO's from which client 104 can choose for hosting the MNO and/or exclude MNO's from a list of MNO's provided to client 104 for selection).
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.
Claims 5-6, 8-9, 15-16, and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Krishnaswamy et al (US 2010/0017861), in view of Wendeborn et al (US 2024/0244417).
Regarding Claims 5 and 15, Krishnaswamy teaches the invention of claims 4 and 14 above, except the following, which in the same field of endeavor, Wendeborn teaches wherein the system is configured such that the positive answer is output automatically based on each of the first check ([0058], Depending on the various combinations of IMEI being present or not present and the value of the device model, BYOD logic is implemented to determine the network. If there is not more than one network at 624, the process proceeds to step 636), the second check ([0059], If there is more than one network at 624, zip code filtering is performed at 626. The customer ID and zip code for the subscriber is used. If a preferred network is found for the customer ID and zip code), and the third check being true ([0068], Network(s) are then selected to provide services for UE 710 based on criteria such as the home location of UE 710, the hardware and software capabilities of UE 710, phone number eligibility, the average signal strength of the MNO networks in the area, the typical congestion on the MNO networks, the number or percentage of subscribers of the initial provisioning entity that are on the MNO networks, cost criteria, subscription criteria, MNO contract criteria, policy criteria (e.g., brand prioritization, preferring networks with certain capabilities, etc.), highest service quality, lowest voice and SMS service cost, forecasts of future traffic on MNO networks, canary factors, input from AI/ML models, and/or any other suitable criteria without deviating from the scope of the invention).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the additional considerations of device capabilities and policies, as taught in Wendeborn, in the system of in order to more intelligently allocate mobile network operators based for optimal resource utilization.
Regarding Claims 6 and 16, Krishnaswamy teaches the invention of claims 2 and 12 above, except the following, which in the same field of endeavor, Wendeborn teaches wherein the first check comprises: invoking, by the mobile virtual network operator, an international mobile equipment identity application programming interface that returns a list of mobile network operators that are serving the mobile virtual network operator and that support an international mobile equipment identity of a device of the client; checking whether the target mobile network operator is included within the list of mobile network operators ([0040], when a pSIM of UE is activated on an International Mobile Equipment Identity (IMEI), an eSIM is provisioned with an Endpoint Identifier (EID) of the UE. When the pSIM is inserted into the appropriate slot of the UE, a carrier application on the UE causes the UE to reach out to a carrier server to obtain an eSIM activation code. The carrier application communicates with an embedded Universal Integrated Circuit Card (eUICC) manager to download the eSIM profile (e.g., for Android®, using the downloadSubscription API of the eUICC manager). The eSIM is provisioned for data usage in some embodiments, [0058], Depending on the various combinations of IMEI being present or not present and the value of the device model, BYOD logic is implemented to determine the network. If there is not more than one network at 624, the process proceeds to step 636).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the additional considerations of device capabilities and policies, as taught in Wendeborn, in the system of in order to more intelligently allocate mobile network operators based for optimal resource utilization.
Regarding Claims 8 and 18, Krishnaswamy teaches the invention of claims 2 and 12 above, except the following, which in the same field of endeavor, Wendeborn teaches wherein the geographic location is specified as a zip code ([0059], If there is more than one network at 624, zip code filtering is performed at 626. The customer ID and zip code for the subscriber is used. If a preferred network is found for the customer ID and zip code).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the additional considerations of device capabilities and policies, as taught in Wendeborn, in the system of in order to more intelligently allocate mobile network operators based for optimal resource utilization.
Regarding Claims 9 and 19, Krishnaswamy teaches the invention of claims 4 and 14 above, except the following, which in the same field of endeavor, Wendeborn teaches wherein: a request to the client for client-specific information is bypassed due to the mobile virtual network operator already possessing the client-specific information ([0061], Fig. 5, Access request 504 can be associated with a client such as client 104, and may include client credentials, client preferences, and client-connection parameters 530. Access request 504 may be transmitted from client 104 to MVNO 102, via an available MNO 106, when client 104 attempts to establish a communication session such as communication session 108 (FIG. 1). Client credentials may be information, such as an IMEI, a phone number, a token, etc., that identify a client or an allowed service for the client (client-specific information provided outright, so additional request is bypassed)); and the client-specific information includes an address of the client ([0059], If there is more than one network at 624, zip code filtering is performed at 626. The customer ID and zip code for the subscriber is used. If a preferred network is found for the customer ID and zip code).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the additional considerations of device capabilities and policies, as taught in Wendeborn, in the system of in order to more intelligently allocate mobile network operators based for optimal resource utilization.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: Ramprasad (US 2014/0273944) discloses FIGS. 5a-5d illustrate exemplary graphical user interfaces ("GUIs") of the wireless account management application 312. The wireless account management application 312 can also include other GUIs that are not illustrated. The user, i.e., the wireless subscriber, of the wireless device 10 can select to run the wireless account management application 312 by selecting an icon associated with the wireless account management application 312. For example, the wireless subscriber can touch the icon associated with the wireless account management application 312 on a homepage displayed on the display 12 of the wireless device 10;
Ho et al (US 2017/0223598) discloses controlling the communication device to establish a first cellular connection between the mobile computing device and a first cellular carrier associated with an MVNO, detecting a condition indicative of (i) a level cellular activity via the first cellular connection below an inactivity threshold and (ii) an available second cellular connection with a different second cellular carrier associated with the MVNO, and in response to detecting the condition, controlling the communication device to: (a) terminate the first cellular connection, and (b) initiate the second cellular connection with the second cellular carrier associated with the MVNO ([0004]).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARGARET G WEBB whose telephone number is (571)270-7803. The examiner can normally be reached M-F 9:00-6:00 PM.
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, Charles Appiah can be reached at (571) 272-7904. 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.
/MARGARET G WEBB/Primary Examiner, Art Unit 2641