Prosecution Insights
Last updated: May 29, 2026
Application No. 18/360,970

APPARATUSES AND METHODS FOR FACILIATING A CARRIER-DRIVEN, DYNAMIC RESOURCE ALLOCATION AND A MANAGEMENT OF NETWORK SLICES TO SUPPORT OPERATIONS, FEATURES, AND FUNCTIONALITY

Non-Final OA §103
Filed
Jul 28, 2023
Examiner
ST LEGER, GEOFFREY R
Art Unit
2192
Tech Center
2100 — Computer Architecture & Software
Assignee
At&T Mobility Ll LLC
OA Round
3 (Non-Final)
82%
Grant Probability
Favorable
3-4
OA Rounds
0m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 82% — above average
82%
Career Allowance Rate
532 granted / 645 resolved
+27.5% vs TC avg
Strong +22% interview lift
Without
With
+21.7%
Interview Lift
resolved cases with interview
Typical timeline
2y 7m
Avg Prosecution
15 currently pending
Career history
663
Total Applications
across all art units

Statute-Specific Performance

§101
6.7%
-33.3% vs TC avg
§103
83.4%
+43.4% vs TC avg
§102
3.3%
-36.7% vs TC avg
§112
3.8%
-36.2% vs TC avg
Black line = Tech Center average estimate • Based on career data from 645 resolved cases

Office Action

§103
DETAILED ACTION The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicants' submission filed on January 27, 2026 has been entered. Claims 1, 18 and 20 have been amended. Claim 14 has been cancelled. New claim 21 has been added. Claims 1-13 and 15-21 have been examined and are pending. Allowable Subject Matter Claim 21 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Response to Arguments Applicants have argued the cited art fails to teach or suggest one or more features recited by the amended independent claims (Remarks, pages 7-9). Applicants' arguments have been fully considered but are moot in view of the new ground(s) of rejection set forth below. Claim Rejections - 35 USC § 103 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 of this title, 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 1, 2, 5, 7, 11-13 and 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over US 20200104113 A1 - hereinafter "Grill", in view of US 20040214599 A1 - hereinafter "Ogino", and in view of US 12603824 B2 - hereinafter "Vaishnavi". With respect to claim 1, Grill teaches, A device, comprising: - mobility services platform (MSP) 103 [0022]; Fig. 1 a processing system including a processor; and a memory that stores executable instructions that, when executed by the processing system, facilitate performance of operations, the operations comprising: - "MSP 103 includes a plurality of interconnected processors, routers, hubs, gateways, storage devices and other hardware that communicate data, commands and signals, over one or more buses." [0031] obtaining a plurality of inputs, - "Based on a number of inputs, MSP 103 determines a cost-optimized approach for scaling cloud infrastructure, allocating communications resources and scheduling communications with mobility clients 102 or components/devices installed or embedded in mobility clients 102." [0032]; Fig. 1; the plurality of inputs including a first input corresponding to a feature that is to be implemented in respect of at least one vehicle - "Some examples of inputs include but are not limited to: the number and/or types of mobility clients to be updated, the update file size, the priority level for the update (feature), the allowed update campaign duration..." [0032] "As used herein, the term “mobility client” means any non-autonomous, autonomous or semi-autonomous vehicle,..." [0024]; and a second input including an identification of a capability of a network operator or service provider to support the feature; - "...and various wireless communication parameters (e.g., geographic coverage, network capacity, link speed, resource availability, service availability) provided by, for example, MNO 101 or other entities." [0032] "As used herein, the term “MNO” means any wireless service provider, wireless carrier, cellular company or mobile network carrier (e.g., Verizon®, AT&T®)." [0023] processing the plurality of inputs to generate an output, the output including a specification of one or more conditions under which the feature is to be implemented in respect of the at least one vehicle, - "Using the inputs, MSP 103 automatically procures and allocates the required infrastructure and/or wireless communications resources (output) for the OTA updates." [0032] "Process 200 continues by procuring and allocating infrastructure and/or wireless communications resources for the cost-optimal infrastructure scaling option (206). For example, suitable infrastructure hardware and software components and systems can be procured and/or allocated to handle the OTA updates according to the OTA update requirements. In an embodiment, one or more load models can be used that utilize statistical analysis of mobility clients crossing major infrastructural facilities, such as bridges. The load model can consider the effective bit rate of a particular access technology, download size, number of mobility clients, and a maximum allowed number of concurrent updates. The output of the load model is the maximum number of concurrent updates (condition), which can be translated into the cloud resources required to support the OTA updates." [0053] and effectuating the feature - "MSP 103 then schedules communication sessions with mobility clients 102, assigns update channels and initiates the OTA updates using the procured and allocated IT infrastructure components and/or wireless communication resources." [0036] Grill does not explicitly teach wherein the specification of the one or more conditions includes...an identification of interference relative to a first threshold; However, in the analogous field of software updates, Ogino teaches: "Here, a control center 1 includes a center communications terminal (TML) 2 that has a control unit 3, a communications unit 4, and a software storage 5." [0017]; Fig. 1 "The in-vehicle communications terminal (TML) 7 includes a control unit 9, a wireless communications unit 10, an operating unit 11, a displaying unit 12, a storage 13, an in-vehicle LAN interface (I/F) 14." [0019]; Fig. 1 "When the control unit 9 detects that the accessory switch 15 is being turned off (YES at Step V7), that the parking brake 16 is being turned on (YES at Step V8), and then that the door-lock is opened, closed, and locked (YES at Step V9), the control unit 9 compares the wireless communications environment level between the in-vehicle communications terminal 7 and center communications terminal 2 with a previously predetermined wireless communications environment level (first threshold) at Step V10. Here, the wireless communications level includes a reception electric field strength level or an interference potential level of the in-vehicle communications terminal 7." [0032] It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Grill with Ogino's teachings because doing so would provide Grill's system with the ability to enhance the efficiency of software downloading for vehicles, as suggested by Ogino [0063]. Grill does not explicitly teach the following limitations which, in the analogous field of software deployment, are taught by Vaishnavi: assigning a resource to effectuate the feature, wherein the resource includes a network slice; and - "FIG. 6 is a flowchart diagram of a method 600 for network slice installation-based deployment testing. The method 600 may be performed by a network node as described herein, for example, a gNB, a base unit 121, and/or the network equipment apparatus 400." (col. 21:57-61) "In one embodiment, the method 600 begins and receives 605 a request to create a new network slice instance according to a incorporation plan for deployment of a new version of network software and migrating one or more user equipment (“UE”) devices to the new network slice instance. In one embodiment, the method 600 creates 610 the new network slice instance according to the incorporation plan. In one embodiment. The method 600 either assigns 615 the new network slice instance to a new single network slice selection assistance information (“S-NSSAI”) or assigns 620 the new network slice instance to an existing S-NSSAI, and the method 600 ends." (col. 21:66 → col. 22:10) effectuating the feature utilizing the resource in respect of the at least one vehicle in accordance with the output. - "FIG. 5 is a flowchart diagram of a method 500 for network slice installation-based deployment testing. The method 500 may be performed by a UE as described herein, for example, the remote unit 105 and/or the user equipment apparatus 300." (col. 21:36-40) "In one embodiment, the method 500 monitors 520 performance of the one or UE devices using the new version of the network software in the new network slice instance, and the method 500 ends." (col. 21:53-56) "The user equipment apparatus 300 may be one embodiment of a UE, such as the remote unit 105 and/or the UE 205, as described above." (col. 16:18-20) "In one embodiment, the remote units 105 may include computing devices, such as...vehicle on-board computers," (col. 6:50-57) It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Grill and Ogino with Vaishnavi's teachings because doing so would provide Grill/Ogino's system with the ability to reduce significant operating costs for operators via automatic testing of new software components, as suggested by Vaishnavi (col. 12:45-50). With respect to claim 2, Grill teaches, wherein the at least one vehicle includes a plurality of vehicles. - "Some examples of inputs include but are not limited to: the number and/or types of mobility clients to be updated,..." [0032] "As used herein, the term “mobility client” means any non-autonomous, autonomous or semi-autonomous vehicle,..." [0024]; Fig. 1 With respect to claim 5, Grill teaches, wherein the first input is obtained from a manufacturer of the at least one vehicle or a distributor of the at least one vehicle. - "Process 200 begins by obtaining OTA update requirements from an MSP operator or from another source (201). The OTA update requirements can include but are not limited to: the number and types of mobility clients to receive updates, the duration of the update campaign, the size of the update files and the priority level for the updates. In an embodiment, the requirements can be obtained through a GUI (e.g., a dashboard GUI) and/or data feed (e.g., XML data feed) provided by the MSP or through any other suitable interface. The OTA update requirements can be provided by OEMs or any other entity." [0046] With respect to claim 7, Grill teaches, wherein the specification of the one or more conditions includes an identification of a time of day, a day of week, or any combination thereof. - "In addition to vertical infrastructure scaling options and cost, MSP 103 also generates horizontal infrastructure scaling options. For example, MSP 103 determines the number and/or type of distribution nodes needed to satisfy concurrent download requirements for an OTA update campaign. The horizontal scaling cost depends on the specific MNOs used and their geographic locations. An example cost consideration is avoiding roaming charges. Costs can also depend on a geographic zone and/or time of the day based on the assumption that the network capacity at certain times of the day is less utilized, and therefore faster and less expensive OTA updates can be performed." [0039] With respect to claim 11, Grill teaches, wherein the effectuating of the feature comprises transmitting firmware, software, or a combination thereof, to the at least one vehicle. - "MSP 103 then schedules communication sessions with mobility clients 102, assigns update channels and initiates the OTA updates using the procured and allocated IT infrastructure components and/or wireless communication resources." [0036] With respect to claim 12, Grill teaches, wherein the transmitting occurs over-the-air (OTA). - "MSP 103 then schedules communication sessions with mobility clients 102, assigns update channels and initiates the OTA updates using the procured and allocated IT infrastructure components and/or wireless communication resources." [0036] With respect to claim 13, Grill teaches, wherein the effectuating of the feature comprises causing at least one of the at least one vehicle or a second vehicle to relocate from a first location to a second location that is different from the first location. - "Mobility client data can include but is not limited to: location data (e.g., timestamp, latitude, longitude, and altitude), sensor data (e.g., acceleration data, gyroscope data) and environment data (e.g., temperature data). In an embodiment, the location data can be used to determine if a mobility client has entered or exited a geofence (a virtual geographic boundary) to trigger a download of a software package or perform some other location-based service." [0066] With respect to claim 15, Grill teaches, wherein the identification of the capability is based on an identification of an amount of bandwidth that is available to support the feature. - "In an embodiment, the costs for various communication options are compared for supporting the OTA update campaign, including options for scheduling downloads, distributing downloads evenly (load balancing) and scheduling downloads at preferred time periods (e.g., at night). Each of these communications options can be evaluated based on its respective communications characteristics (e.g., bandwidth, throughput, error rate) and associated costs." [0037] With respect to claim 16, Grill teaches, wherein the plurality of inputs includes: ...a third input that is generated by the at least one vehicle. - "MSP 103 uses the infrastructure scaling data obtained from one or more MNOs and mobility clients 102 (e.g., bandwidth, link speed) to determine a number of infrastructure scaling options for an OTA update campaign." [0036] With respect to claim 17, Grill teaches, wherein the effectuating of the feature comprises disabling an operation of the at least one vehicle. - "Control Info field 308d includes commands for remote control of an OTA client, such as a disable command to disable a particular software version installed on the mobility client." [0061] Claims 3 and 4 are rejected under 35 U.S.C. 103 as being unpatentable over Grill, Ogino and Vaishnavi, in view of US 20240403021 A1 - hereinafter "Antinori". With respect to claim 3, Grill does not explicitly teach, wherein the specification of the one or more conditions includes an identification of a first priority of a first vehicle included in the plurality of vehicles relative to a second priority of a second vehicle included in the plurality of vehicles in terms of the feature being effectuated in respect of each of the first vehicle and the second vehicle. However, in the analogous field of software deployment, Antinori teaches: "The install threshold 197 (priority) may indicate a minimum duration over which an application 117 is to have executed on the second vehicle 115B before the ECU controller 110 of the first vehicle 115A will consider it for execution." [0085] "Though the described example describes increasing the install threshold 197, embodiments of the present disclosure are not limited to this operation. In some embodiments, the vehicle data 114 may be processed to determine that the install threshold 197 should be decreased. For example, the vehicle data 114 may indicate that the first vehicle 115A is a test vehicle, and it may be desired to install updates as quickly as possible. As another example, the vehicle data 114 may indicate that the first vehicle 115A is a rental vehicle, and it may be desired to install features that may be important to customers as quickly as possible. As a result, in some embodiments, install threshold 197 may be dynamically altered to be shorter than the default install threshold 197." [0095] Logically, different vehicles can have different install thresholds (priorities). It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Grill, Ogino and Vaishnavi with Antinori's teachings because doing so would provide Grill/Ogino/Vaishnavi's system with the ability to increase the security of the operation of embedded systems, such as those used in computing devices for vehicles, as suggested by Antinori [0028]. With respect to claim 4, Grill does not explicitly teach, wherein the first vehicle is associated with a first responder, and the first priority is greater than the second priority. However, in the analogous field of software deployment, Antinori teaches: "As an example, the vehicle data 114 may indicate if the vehicle 115 is involved in public services (e.g., a security drone, an ambulance, a police vehicle) or other categories, such as a military vehicle, that may indicate a higher desired level of stability for the vehicle 115." [0093] "As a result, in some embodiments, install threshold 197 may be dynamically altered to be shorter than the default install threshold 197." [0095] It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Grill, Ogino and Vaishnavi with Antinori's teachings because doing so would provide Grill/Ogino/Vaishnavi's system with the ability to increase the security of the operation of embedded systems, such as those used in computing devices for vehicles, as suggested by Antinori [0028]. Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Grill, Ogino and Vaishnavi, in view of US 20200174779 A1 - hereinafter "David". With respect to claim 6, Grill does not explicitly teach, wherein the specification of the one or more conditions further includes an identification of a signal strength relative to a third threshold. However, in the analogous field of software deployment, David teaches: "In some embodiments, the OTA updater device 108 receives information that can be used to determine the vehicle state conditions from other components of the vehicle 106 via the vehicle communication bus to determine whether the vehicle 106 is ready to be updated and that it is safe for the update to proceed. Non-limiting and non-exclusive examples of vehicle state conditions that may be monitored to determine whether installation is ready to begin include whether the HMI device 214 of the vehicle has been actuated for a threshold amount of time, whether the engine of the vehicle 106 is off, whether an ignition key of the vehicle 106 is in an “on” position, whether a battery voltage of the vehicle 106 meets a battery voltage threshold to allow for successful updating, whether a wireless signal strength detected by the OTA updater device 108 meets a signal strength threshold, whether the vehicle speed is zero, and whether a parking brake of the vehicle 106 is set." [0046] It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Grill, Ogino and Vaishnavi with David's teachings because doing so would provide Grill/Ogino/Vaishnavi's system with the ability to reduce or eliminate trips to a dealership or service center to resolve software problems, as suggested by David [0018]. Claims 8 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Grill, Ogino and Vaishnavi, in view of WO 2019070235 A1 - hereinafter "Ramic". With respect to claim 8, Grill does not explicitly teach, wherein the feature is a safety feature pertaining to operations of the at least one vehicle. However, in the analogous field of software deployment, Ramic teaches: "The vehicular computing device 244 may schedule different updates from a single update package, each update scheduled independently. An update can be classified with a severity level, e.g., updates addressing the safety of the vehicle 140 may be more severe (more important) than updates to an entertainment function." [0078] It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Grill, Ogino and Vaishnavi with Ramic's teachings because doing so would provide Grill/Ogino/Vaishnavi's system with the ability to minimize or eliminate any disruption when updating functionality of vehicular computing devices, as suggested by Ramic [0016]. With respect to claim 9, Grill does not explicitly teach, wherein the feature pertains to entertainment within a cabin of the at least one vehicle, climate within the cabin, or a combination thereof. However, in the analogous field of software deployment, Ramic teaches: "The vehicular computing device 244 may schedule different updates from a single update package, each update scheduled independently. An update can be classified with a severity level, e.g., updates addressing the safety of the vehicle 140 may be more severe (more important) than updates to an entertainment function." [0078] It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Grill, Ogino and Vaishnavi with Ramic's teachings because doing so would provide Grill/Ogino/Vaishnavi's system with the ability to minimize or eliminate any disruption when updating functionality of vehicular computing devices, as suggested by Ramic [0016]. Claim 10 and rejected under 35 U.S.C. 103 as being unpatentable over Grill, Ogino and Vaishnavi, in view of US 20200218531 A1 - hereinafter "Kushwaha". With respect to claim 10, Grill does not explicitly teach, wherein the processing of the plurality of inputs to generate the output is based on a use of machine learning, artificial intelligence, deep-learning, or any combination thereof. However, in the analogous field of software deployment, Kushwaha teaches: "In generating the update plan, update engine 406 selects updated software components 410-415 for installation in a vehicle or fleet of vehicles, and determines an order or sequence for installing the updated software components 410-415 in the vehicle or fleet. Update engine 406 may use a variety of analysis tools in generating the update plans. For instance, update engine 406 may utilize machine learning or artificial intelligence (AI) techniques to generate the update plans, such as with machine learning system 407. Machine learning system 407 may be trained (using machine learning techniques) with the prior software updates on vehicles, and/or with other contextual information to develop a model for machine learning system 407. Based on this training, machine learning system 407 is able to generate an update plan for a vehicle or fleet." [0036] It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Grill, Ogino and Vaishnavi with Kushwaha's teachings because doing so would provide Grill/Ogino/Vaishnavi's system with the ability to update a vehicle wherever a wireless signal is available to the vehicle, as suggested by Kushwaha [0045]. Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over US 20240046799 A1 - hereinafter "Vemuri", in view of US 20040214599 A1 - hereinafter "Ogino", and in view of US 12603824 B2 - hereinafter "Vaishnavi". With respect to claim 18, Vemuri teaches, A non-transitory machine-readable medium, comprising executable instructions that, when executed by a processing system including a processor, facilitate performance of operations, the operations comprising: - [0054]; Fig. 4 obtaining an update to a feature present within a fleet of assets; - "The system 5 is illustrated including a remote communication device 30 and a plurality of vehicles 10, including vehicle 11, vehicle 12, vehicle 13, vehicle 14, vehicle 15, vehicle 16, vehicle 17, vehicle 18, vehicle 19, vehicle 20, vehicle 21, and vehicle 22. The remote communication device is a transmitter/receiver unit embodied as a wireless communication device useful to enable data transfer and/or OTA updates to at least one of the plurality of vehicles 10." [0042]; Fig. 1 based on the obtaining of the update, analyzing data to identify first assets included within the fleet of assets for receiving the update, the first assets being less than an entirety of the fleet of assets, - "At step 404, a plurality of vehicles to receive a data transfer is identified. The data transfer may include an OTA update. At step 406, a first portion of a plurality of vehicles is identified as alpha vehicles (first assets) including hardware identified enabling excellent wireless capabilities." [0063] "The system includes a remote communication device configured to transmit data, vehicles to receive the data, and a computerized controller. The controller includes programming to analyze hardware of the vehicles to identify alpha vehicles including excellent wireless capabilities, ..." (Abstract); wherein the analyzing results in a specification of one or more conditions under which the update is to be implemented in respect of the first assets, - "In one embodiment, the system and method may analyze the plurality of vehicles to identify within the plurality of vehicles a portion of the plurality of vehicles with hardware enabling excellent wireless capabilities. Such an analysis may include determining which vehicles have most up to date hardware and/or software configured to facilitate rapid data transfer. Such an analysis may include determining which vehicles have upgraded or excellent processor speed or increased quantities of random-access-memory (RAM) useful to facilitate rapid data transfer. Such an analysis may include determining which vehicles include sufficient memory capacity to accomplish both receiving the data transfer for that vehicle and additionally including additional data that may be required to update other vehicles with different hardware or software configurations. Such an analysis may include determining which vehicles include wireless communication devices capable of establishing high-speed data transfer connections. Vehicles selected from the plurality of vehicles may be described as a more capable portion of the plurality of vehicles or as alpha vehicles of the plurality of vehicles." [0031] transmitting the update to the first assets in accordance with the analyzing. - "At step 412, a series of sequential data transfers are identified and configured for distributing the data between the plurality of vehicles. The distributing includes the data first being transferred from the access point to at least one of the highly functioning vehicles and then being transferred from the highly functioning vehicle(s) to at least one of the other vehicles of the plurality of vehicles. At step 414, an iteration of the series of sequential data transfers is performed." [0063] Vemuri does not explicitly teach wherein the specification of the one or more conditions includes an identification of...interference relative to a first threshold. However, in the analogous field of software updates, Ogino teaches: "Here, a control center 1 includes a center communications terminal (TML) 2 that has a control unit 3, a communications unit 4, and a software storage 5." [0017]; Fig. 1 "The in-vehicle communications terminal (TML) 7 includes a control unit 9, a wireless communications unit 10, an operating unit 11, a displaying unit 12, a storage 13, an in-vehicle LAN interface (I/F) 14." [0019]; Fig. 1 "When the control unit 9 detects that the accessory switch 15 is being turned off (YES at Step V7), that the parking brake 16 is being turned on (YES at Step V8), and then that the door-lock is opened, closed, and locked (YES at Step V9), the control unit 9 compares the wireless communications environment level between the in-vehicle communications terminal 7 and center communications terminal 2 with a previously predetermined wireless communications environment level (first threshold) at Step V10. Here, the wireless communications level includes a reception electric field strength level or an interference potential level of the in-vehicle communications terminal 7." [0032] It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Vemuri with Ogino's teachings because doing so would provide Vemuri's system with the ability to enhance the efficiency of software downloading for vehicles, as suggested by Ogino [0063]. Vemuri does not explicitly teach the following limitations which, in the analogous field of software deployment, are taught by Vaishnavi: assigning a resource to effectuate the feature, wherein the resource includes a network slice; and - "FIG. 6 is a flowchart diagram of a method 600 for network slice installation-based deployment testing. The method 600 may be performed by a network node as described herein, for example, a gNB, a base unit 121, and/or the network equipment apparatus 400." (col. 21:57-61) "In one embodiment, the method 600 begins and receives 605 a request to create a new network slice instance according to a incorporation plan for deployment of a new version of network software and migrating one or more user equipment (“UE”) devices to the new network slice instance. In one embodiment, the method 600 creates 610 the new network slice instance according to the incorporation plan. In one embodiment. The method 600 either assigns 615 the new network slice instance to a new single network slice selection assistance information (“S-NSSAI”) or assigns 620 the new network slice instance to an existing S-NSSAI, and the method 600 ends." (col. 21:66 → col. 22:10) transmitting the update to the first assets in accordance with the analyzing to effectuate the feature utilizing the resource. - "In one embodiment, the processor 305 is configured to deploy the new version of the network software on a current network that the one or more UE devices are connected to according to the incorporation plan." (col. 18:62-65) "FIG. 5 is a flowchart diagram of a method 500 for network slice installation-based deployment testing. The method 500 may be performed by a UE as described herein, for example, the remote unit 105 and/or the user equipment apparatus 300." (col. 21:36-40) "In one embodiment, the method 500 monitors 520 performance of the one or UE devices using the new version of the network software in the new network slice instance, and the method 500 ends." (col. 21:53-56) "The user equipment apparatus 300 may be one embodiment of a UE, such as the remote unit 105 and/or the UE 205, as described above." (col. 16:18-20) "In one embodiment, the remote units 105 may include computing devices, such as...vehicle on-board computers," (col. 6:50-57) It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Vemuri and Ogino with Vaishnavi's teachings because doing so would provide Vemuri/Ogino's system with the ability to reduce significant operating costs for operators via automatic testing of new software components, as suggested by Vaishnavi (col. 12:45-50). Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Vemuri, Ogino and Vaishnavi, and in view of US 20200153898 A1 - hereinafter "Sabath". With respect to claim 19, Vemuri does not explicitly teach the following limitations which, in the analogous field of software updates are taught by Sabath as follows: wherein the analyzing of the data comprises identifying a first amount of time for the first assets to implement the update and a second amount of time for second assets included in the fleet of assets to implement the update, the operations further comprising: - "At block 702 of FIG. 7, a set of one or more nodes, such as worker nodes 410 of FIG. 4, in a cluster of nodes is selected for an update." [0069] "The aspects taken into account by the planner micro-service when selecting the set of one or more nodes can include, but are not limited to: the time that it takes to perform the update,..." [0069] "The planner micro-service can also select the set that is likely to minimize the amount of time taken to perform a full upgrade of the cluster." [0070] selecting the first assets for receiving the update based on the first amount of time being less than the second amount of time, - "The planner micro-service can also select the set that is likely to minimize the amount of time taken to perform a full upgrade of the cluster." [0070] wherein the transmitting is based on the selecting. - "At block 708, the selected node(s) in the set are redeployed, or updated with the new version of the infrastructure code." [0074] It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Vemuri, Ogino and Vaishnavi with Sabath's teachings because doing so would provide Vemuri/Ogino/Vaishnavi's system with the ability to optimize the update process, as suggested by Sabath [0027]. Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over US 20240314139 A1 - hereinafter "Kairali" in view of US 20040214599 A1 - hereinafter "Ogino", and in view of US 12603824 B2 - hereinafter "Vaishnavi". With respect to claim 20, Kairali teaches, A method, comprising: identifying, by a processing system including a processor, a modification to a feature pertaining to operations of equipment, resulting in a first identification; - "In some situations where a vehicle 301 (equipment) is determined by the SBOM checker 319 to violate one or more location-enforced policies 401 along a route, embodiments of the route mapping service 307 may search for an update or upgrade to the existing software or dependencies thereof within the vehicle's SBOM or diff SBOM that, if updated or upgraded, would place the vehicle 301 in compliance with the location, region, zone or area of the route that is currently deemed non-compliant by the SBOM checker 319." [0050]; Figs. 1 & 3 determining, by the processing system, that the equipment is mobile, resulting in a first determination; - "In other circumstances, where a vehicle is already engaged and traveling along a generated route..." [0051]; Figs. 1 & 3 determining, by the processing system and based on the first identification and the first determination, that the modification is capable of being implemented on the equipment within a threshold amount of time, resulting in a second determination; and - "Route mapping service 307 may notify the vehicle 301 about the lack of compliance with location-enforced policies 401 and inform a user of the vehicle 301 about updates or upgrades to software that would place the vehicle 301 in compliance with one or more location-enforced policies 401 of a generated route." [0050] "...if there is enough time to retrieve and apply the update or upgrade before entering the location, region, zone, etc., where the vehicle lacks compliance with the location-enforced policy 401, vehicle 301 may upgrade or update one or more software systems during the route in order to be placed into compliance and verified by SBOM checker 319. If there is not enough time to update or upgrade software systems to place the vehicle in compliance with the location-enforced policy 401, the velocity of the vehicle may be adjusted to slow the vehicle down, allowing more time to retrieve and apply the updates or upgrades to the software systems of the vehicle 301 and thus not enter the location, area, region or zone while muted." [0051]; Figs. 1 & 3 transmitting, by the processing system - "...if there is enough time to retrieve and apply the update or upgrade before entering the location, region, zone, etc., where the vehicle lacks compliance with the location-enforced policy 401, vehicle 301 may upgrade or update one or more software systems during the route in order to be placed into compliance and verified by SBOM checker 319. If there is not enough time to update or upgrade software systems to place the vehicle in compliance with the location-enforced policy 401, the velocity of the vehicle may be adjusted to slow the vehicle down, allowing more time to retrieve and apply the updates or upgrades to the software systems of the vehicle 301 and thus not enter the location, area, region or zone while muted." [0051]; Figs. 1 & 3 Kairali does not explicitly teach the following limitations which, in the analogous field of software updating, are taught by Ogino as follows: determining, by the processing system, a specification of one or more conditions under which the modification is to be implemented in respect of the equipment, resulting in a third determination, - "Here, a control center 1 includes a center communications terminal (TML) 2 that has a control unit 3, a communications unit 4, and a software storage 5." [0017]; Fig. 1. "The in-vehicle communications terminal (TML) 7 includes a control unit 9, a wireless communications unit 10, an operating unit 11, a displaying unit 12, a storage 13, an in-vehicle LAN interface (I/F) 14." [0019]; Fig. 1. "When the control unit 9 detects that the accessory switch 15 is being turned off (YES at Step V7), that the parking brake 16 is being turned on (YES at Step V8), and then that the door-lock is opened, closed, and locked (YES at Step V9), the control unit 9 compares the wireless communications environment level between the in-vehicle communications terminal 7 and center communications terminal 2 with a previously predetermined wireless communications environment level at Step V10." [0032]; wherein the specification of the one or more conditions includes an identification of...interference relative to a first threshold; and - "...the control unit 9 compares the wireless communications environment level between the in-vehicle communications terminal 7 and center communications terminal 2 with a previously predetermined wireless communications environment level (first threshold) at Step V10. Here, the wireless communications level includes a reception electric field strength level or an interference potential level of the in-vehicle communications terminal 7." [0032]; transmitting, by the processing system - "When the wireless communications environment level is determined to be equal or more than the predetermined (PD) level (YES at Step V11), the control unit 9 performs as follows: ..." [0033][0034-0039] "In the center communications terminal 2, when the control unit 3 detects that the communications unit 4 receives the download start request signal sent by the in-vehicle communications terminal 7 (YES at Step C3), it thereby detects that the time of day for starting the software downloading is not included in the request (NO at Step C4). The control unit 4 then extracts the terminal ID and version of the software at Step C10. The control unit 3 generates a download start permit signal including the file name of the software to cause the communications unit 4 to send it to the in-vehicle communications terminal 7 via the wireless base station 8 at Step C8. It then starts the software downloading to the in-vehicle communications terminal 7 at Step C9." [0040] It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Kairali with Ogino's teachings because doing so would provide Kairali's system with the ability to enhance the efficiency of software downloading for vehicles, as suggested by Ogino [0063]. Kairali does not explicitly teach the following limitations which, in the analogous field of software deployment, are taught by Vaishnavi: assigning, by the processing system, a resource to effectuate the feature, wherein the resource includes a network slice; and - "FIG. 6 is a flowchart diagram of a method 600 for network slice installation-based deployment testing. The method 600 may be performed by a network node as described herein, for example, a gNB, a base unit 121, and/or the network equipment apparatus 400." (col. 21:57-61) "In one embodiment, the method 600 begins and receives 605 a request to create a new network slice instance according to a incorporation plan for deployment of a new version of network software and migrating one or more user equipment (“UE”) devices to the new network slice instance. In one embodiment, the method 600 creates 610 the new network slice instance according to the incorporation plan. In one embodiment. The method 600 either assigns 615 the new network slice instance to a new single network slice selection assistance information (“S-NSSAI”) or assigns 620 the new network slice instance to an existing S-NSSAI, and the method 600 ends." (col. 21:66 → col. 22:10) transmitting, by the processing system and via the resource - "In one embodiment, the processor 305 is configured to deploy the new version of the network software on a current network that the one or more UE devices are connected to according to the incorporation plan." (col. 18:62-65) "FIG. 5 is a flowchart diagram of a method 500 for network slice installation-based deployment testing. The method 500 may be performed by a UE as described herein, for example, the remote unit 105 and/or the user equipment apparatus 300." (col. 21:36-40) "In one embodiment, the method 500 monitors 520 performance of the one or UE devices using the new version of the network software in the new network slice instance, and the method 500 ends." (col. 21:53-56) "The user equipment apparatus 300 may be one embodiment of a UE, such as the remote unit 105 and/or the UE 205, as described above." (col. 16:18-20) "In one embodiment, the remote units 105 may include computing devices, such as...vehicle on-board computers," (col. 6:50-57) It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Kairali and Ogino with Vaishnavi's teachings because doing so would provide Kairali/Ogino's system with the ability to reduce significant operating costs for operators via automatic testing of new software components, as suggested by Vaishnavi (col. 12:45-50). Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to GEOFFREY R ST LEGER whose telephone number is (571)270-7720. The examiner can normally be reached M-F (IFP) ~9:00-5: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, Hyung S Sough can be reached at 571-272-6799. 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. /GEOFFREY R ST LEGER/Primary Examiner, Art Unit 2192
Read full office action

Prosecution Timeline

Jul 28, 2023
Application Filed
Jun 11, 2025
Non-Final Rejection mailed — §103
Sep 09, 2025
Response Filed
Oct 29, 2025
Final Rejection mailed — §103
Jan 27, 2026
Request for Continued Examination
Feb 04, 2026
Response after Non-Final Action
Apr 20, 2026
Non-Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12639058
SOFTWARE UPDATES IN A NETWORK INTERFACE DEVICE
3y 1m to grant Granted May 26, 2026
Patent 12639059
AUTOMATIC FIRMWARE UPDATING
2y 4m to grant Granted May 26, 2026
Patent 12639053
COMPILE-TIME LINK TYPE OBJECT MANAGEMENT
2y 4m to grant Granted May 26, 2026
Patent 12639056
ADAPTIVE SEARCH-BASED ALLOCATION OF COMPUTATIONS TO SYNCHRONIZED, INTERCONNECTED PROCESSING ELEMENTS FOR IMPLEMENTING MACHINE LEARNING NETWORKS
2y 7m to grant Granted May 26, 2026
Patent 12632232
SYSTEMS AND METHODS FOR UNIFIED COMPUTING ON DIGITAL AND QUANTUM COMPUTERS
2y 5m to grant Granted May 19, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
82%
Grant Probability
99%
With Interview (+21.7%)
2y 7m (~0m remaining)
Median Time to Grant
High
PTA Risk
Based on 645 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month