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 02/25/2026; 05/26/2026 and 07/08/2026 have been fully considered by examiner and entered into record.
Response to Arguments
Applicant’s arguments have been fully considered but are moot because they do not apply to the new combination of references being used in the current rejection.
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, 11, and 20 are rejected under 35 U.S.C. 102(a)(1) & 102(a)(2) as being anticipated by Yoda et al (US 2017/0264592).
Regarding Claim 1, Yoda teaches a method (Fig. 20) comprising: receiving, by a graphical user interface at a mobile virtual network operator, a request to verify whether a network switch is available ([0080], FIG. 19 illustrates a graphical user interface of the MVNE Resource Manager Page, which is to be used by an operator of MVNE. The page enables the MVNE to check and act upon resource requests that are placed by MVNO partners) 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 ([0081], At block 2002, in response to Operator of at MVNO placing a resource change request, the system places the request to Request Requests 1201a in the MVNE Resource Manager 1210. At block 2003, MVNE uses MVNE Resource Manager 1209 to review availability and usage of the overall resource as provided by MNO, as well as resource allocations and usage by all of its MVNO partners); 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 ([0080], Fig. 19, The Page may consist of multiple sections. A section on Resource Allocation Requests by MVNO Pending MVNE Decision lists resource allocation requests by MVNO partners, allowing the MVNE to select one of them and select wither to accept or deny the request. Currently a Request #8001 is selected (as indicated by the star icon), which indicates that MVNO X has requested to increase the number of subscribers allocation to 400,000. Request #8002 indicates that MVNO Y has requested to increase the maximum bandwidth to 80 Mbps. The MVNE may accept or deny the request based on the overall resource availability of the MVNE by selectin either Accept or Deny button. The page also displays consumption status of both computing and network resources that are being maintained by the MVNE. A section on computing resources may indicate a level of resources that are allocated to and being used by respective MVNO partners),
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 ([0081], At block 2004, a determination is made as to whether MVNE accepts the resource change request by the MVNO. If yes, at block 2006, the MVNE Resource Manager 1210 identifies components that are affected by the change based on the approved request. Additionally, at block 2007, MVNE Resource Manager 1209 instructs the affected components via MVNE Control channel to change the resource allocation configurations).
Regarding Claim 11, Yoda teaches a system 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 ([0089]), cause the computing device to perform operations (Fig. 20) comprising: receiving, by a graphical user interface at a mobile virtual network operator, a request to verify whether a network switch is available ([0080], FIG. 19 illustrates a graphical user interface of the MVNE Resource Manager Page, which is to be used by an operator of MVNE. The page enables the MVNE to check and act upon resource requests that are placed by MVNO partners)
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 ([0081], At block 2002, in response to Operator of at MVNO placing a resource change request, the system places the request to Request Requests 1201a in the MVNE Resource Manager 1210. At block 2003, MVNE uses MVNE Resource Manager 1209 to review availability and usage of the overall resource as provided by MNO, as well as resource allocations and usage by all of its MVNO partners); 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 ([0080], Fig. 19, The Page may consist of multiple sections. A section on Resource Allocation Requests by MVNO Pending MVNE Decision lists resource allocation requests by MVNO partners, allowing the MVNE to select one of them and select wither to accept or deny the request. Currently a Request #8001 is selected (as indicated by the star icon), which indicates that MVNO X has requested to increase the number of subscribers allocation to 400,000. Request #8002 indicates that MVNO Y has requested to increase the maximum bandwidth to 80 Mbps. The MVNE may accept or deny the request based on the overall resource availability of the MVNE by selectin either Accept or Deny button. The page also displays consumption status of both computing and network resources that are being maintained by the MVNE. A section on computing resources may indicate a level of resources that are allocated to and being used by respective MVNO partners),
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 ([0081], At block 2004, a determination is made as to whether MVNE accepts the resource change request by the MVNO. If yes, at block 2006, the MVNE Resource Manager 1210 identifies components that are affected by the change based on the approved request. Additionally, at block 2007, MVNE Resource Manager 1209 instructs the affected components via MVNE Control channel to change the resource allocation configurations).
Regarding Claim 20, Yoda teaches a non-transitory computer-readable medium that has instructions stored thereon that, when executed by at least one physical computing processor ([0089], Fig. 20), cause a computing device to perform operations comprising: receiving, by a graphical user interface at a mobile virtual network operator, a request to verify whether a network switch is available ([0080], FIG. 19 illustrates a graphical user interface of the MVNE Resource Manager Page, which is to be used by an operator of MVNE. The page enables the MVNE to check and act upon resource requests that are placed by MVNO partners)
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 ([0081], At block 2002, in response to Operator of at MVNO placing a resource change request, the system places the request to Request Requests 1201a in the MVNE Resource Manager 1210. At block 2003, MVNE uses MVNE Resource Manager 1209 to review availability and usage of the overall resource as provided by MNO, as well as resource allocations and usage by all of its MVNO partners); 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 ([0080], Fig. 19, The Page may consist of multiple sections. A section on Resource Allocation Requests by MVNO Pending MVNE Decision lists resource allocation requests by MVNO partners, allowing the MVNE to select one of them and select wither to accept or deny the request. Currently a Request #8001 is selected (as indicated by the star icon), which indicates that MVNO X has requested to increase the number of subscribers allocation to 400,000. Request #8002 indicates that MVNO Y has requested to increase the maximum bandwidth to 80 Mbps. The MVNE may accept or deny the request based on the overall resource availability of the MVNE by selectin either Accept or Deny button. The page also displays consumption status of both computing and network resources that are being maintained by the MVNE. A section on computing resources may indicate a level of resources that are allocated to and being used by respective MVNO partners), 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 ([0081], At block 2004, a determination is made as to whether MVNE accepts the resource change request by the MVNO. If yes, at block 2006, the MVNE Resource Manager 1210 identifies components that are affected by the change based on the approved request. Additionally, at block 2007, MVNE Resource Manager 1209 instructs the affected components via MVNE Control channel to change the resource allocation configurations).
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 2-4, 7, 10, 12-14, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Yoda et al (US 2017/0264592), in view of Krishnaswamy et al (US 2010/0017861).
Regarding Claim 2, Yoda teaches the method of claim 1, except the following, which in the same field of endeavor, Krishnaswamy teaches 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).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate automatic checks for compatibility between MNOs, as taught in Krishnaswamy, in the system of Yoda, in order to take advantage of prearranged access agreements improve communications across network devices.
Regarding Claim 3, Yoda, modified by 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, Yoda, modified by Krishnaswamy, teaches the method of claim 2, Krishnaswamy further teaches 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).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate automatic checks for compatibility between MNOs, as taught in Krishnaswamy, in the system of Yoda, in order to take advantage of prearranged access agreements improve communications across network devices.
Regarding Claim 7, Yoda, modified by Krishnaswamy, teaches the method of claim 2, Krishnaswamy further teaches 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).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate automatic checks for compatibility between MNOs, as taught in Krishnaswamy, in the system of Yoda, in order to take advantage of prearranged access agreements improve communications across network devices.
Regarding Claim 10, Yoda teaches the method of claim 1, except the following, which in the same field of endeavor, Krishnaswamy teaches 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)).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate automatic checks for compatibility between MNOs, as taught in Krishnaswamy, in the system of Yoda, in order to take advantage of prearranged access agreements improve communications across network devices.
Regarding Claim 12, Yoda teaches the system of claim 11, except the following, which in the same field of endeavor, Krishnaswamy teaches 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).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate automatic checks for compatibility between MNOs, as taught in Krishnaswamy, in the system of Yoda, in order to take advantage of prearranged access agreements improve communications across network devices.
Regarding Claim 13, Yoda, modified by 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, Yoda, modified by Krishnaswamy, teaches the system of claim 12, Krishnaswamy further teaches 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).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate automatic checks for compatibility between MNOs, as taught in Krishnaswamy, in the system of Yoda, in order to take advantage of prearranged access agreements improve communications across network devices.
Regarding Claim 17, Yoda, modified by Krishnaswamy, teaches the system of claim 12, Krishnaswamy further teaches 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).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to incorporate automatic checks for compatibility between MNOs, as taught in Krishnaswamy, in the system of Yoda, in order to take advantage of prearranged access agreements improve communications across network devices.
Claims 5-6, 9, 15-16, and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Yoda et al (US 2017/0264592), in view of Krishnaswamy et al (US 2010/0017861), and further 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 Yoda, modified by Krishnaswamy, 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 Yoda, modified by Krishnaswamy, in order to more intelligently allocate mobile network operators based for optimal resource utilization.
Regarding Claim 18, Krishnaswamy teaches the invention of claim 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 Yoda, modified by Krishnaswamy, 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 Yoda, modified by Krishnaswamy, in order to more intelligently allocate mobile network operators based for optimal resource utilization.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Yoda et al (US 2017/0264592), in view of Wendeborn et al (US 2024/0244417).
Regarding Claim 8, Yoda teaches the method of claim 1, except the following, which in the same field of endeavor, Wendeborn teaches wherein: the analysis comprises a specific 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 specific value ([0068], Intent engine 730 then uses this information, if provided, along with other information used by that provider for intelligent initial provisioning. 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. This may be accomplished using a process similar to that of FIGS. 4A-C, 5A and 5B, and/or 6A-C in some embodiments).
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 Yoda, in order to more intelligently allocate mobile network operators based for optimal resource utilization.
Conclusion
Applicant's submission of an information disclosure statement under 37 CFR 1.97(c) with the timing fee set forth in 37 CFR 1.17(p) on 07/08/2026 prompted the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 609.04(b). 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 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
Prosecution Insights