DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Remarks
This communication is considered fully responsive to the Amendment filed on 5/8/26.
Amendments to IFW specification entered.
Objection to claim 27 withdrawn since amended accordingly.
101 rejection is maintained. See details below.
Response to Arguments
Applicant's arguments filed 5/8/26 have been fully considered but they are not persuasive.
1] applicant argues: (summary Remarks 5/8/26, pg 10-12)
Independent claim 1 is directed to patent eligible subject matter under prong 2 of step 2A of the Alice/Mayo test:
MPEP 2106.04 ("Eligibility Step 2A: Whether a Claim is Directed to a Judicial Exception") states, inter alia, the following:
"Prong Two asks does the claim recite additional elements that integrate the judicial exception into a practical application? In Prong Two, examiners evaluate whether the claim as a whole integrates the exception into a practical application of that exception. If the additional elements in the claim integrate the recited exception into a practical application of the exception. then the claim is not directed to the judicial exception (Step 2A: NO) and thus is eligible at Pathway B. (MPEP
2106.04(11)(2); Emphasis added).
* * * * *
"Limitations the courts have found indicative that an additional element (or combination of elements) may have integrated the exception into a practical application include:
An improvement in the functioning of a computer, or an improvement to other technology or technical field .... " (MPEP 2106.04(d); Emphasis added).
...
Independent claim 1 of the present application integrates an alleged exception into a practical application - e.g., by virtue of requiring an element that reflects an improvement in the functioning of a computer, or an improvement to other technology or technical field.
...
Independent claim 1 as amended now explicitly recites that it is the network service orchestrator which performs the method and that the network service orchestrator is executing each of the method steps of "receiving ... ", "selecting ... ", "deploying ... ", and "providing ... " recited in claim 1.
The network service orchestrator is supported by, for example, pg. 5, lines 28-30 and pg. 13, lines 9-11 (paras. [0021] and [0051] of PGPub 2025/056195) of the instant specification of the present application. In particular, pg. 13, lines 9-11 of the instant specification of the present application teaches "For example, the method 300 may be run alongside ( or as part of) a network service orchestration system responsible for deploying service instances to edge compute nodes in a network."
As is understood by a person of ordinary skill in the art, a network service orchestrator is
a term of art in which network service orchestrators autonomously provide services over a
network. Accordingly, any allegation that the method of claim 1 is performed by a human or is a
mere automation of something a human would ordinarily do has been overcome.
...
The examiner respectfully disagrees.
As admitted by applicant, “As is understood by a person of ordinary skill in the art, a network service orchestrator is a term of art in which network service orchestrators autonomously provide services over a network” is well-known conventional components operating according to their ordinary functions.
Furthermore, as is understood in light of the specification, nothing in the claims requires anything other than off-the shelf, conventional components for “receiving ... selecting ... deploying ... providing ...” recited in claim 1.
Therefore amended claims comprising “network service orchestrator” fail to transform the abstract idea into something more. Therefore, claims are ineligible.
2] applicant argues: (summary Remarks 5/8/26, pg 12-13)
...
Moreover, the invention of claim 1 integrates an alleged exception into a practical application by providing an improvement (e.g., reduced latency, service continuity, resource optimization, and adaptability) in the functioning of a computer, or an improvement to other technology or technical field.
For example, the above claim limitations involve providing, by the network service orchestrator, a communications plan to the mobile entity, the communications plan indicating how the at least one instance of the service can be accessed during the intended journey. As a result of the communication plan, the network service orchestrator can selectively deploy the service to specific nodes, rather than having the service deployed to all nodes and attempting to reserve more resources on a predicted path for a mobile entity.
...
These technical advantages collectively address the problem stated in the background section of the present application regarding the variable quality of connection that mobile entities experience when moving around, particularly for applications sensitive to latency variations such as unmanned aerial vehicle control.
The invention of claim 1 therefore provides the technical advantages of reduced latency, service continuity, resource optimization, and adaptability. The invention of claim 1 therefore provides an improvement in the functioning of a computer, or an improvement to other technology or technical field.
...
The examiner respectfully disagrees.
Specifically, the claims themselves do not disclose performing and/or using any technical improvements of communication plans or otherwise describe how the goal(s) of reduced latency, service continuity, resource optimization and/or adaptability is/are achieved.
Furthermore, the IFW specification itself does not disclose performing and/or using any technical improvements of communication plans or otherwise describe how the goal(s) of reduced latency, service continuity, resource optimization and/or adaptability is/are achieved.
Furthermore, per applicant’s original IFW specification the problem of “latency of communications” is further disclosed as particularly associated with controlling unmanned vehicles (i.e. humans controlling the unmanned vehicles) and especially unmanned aerial vehicles may be particular [sic] sensitive and gives an example that latency of communications between an unmanned aerial vehicle and a controller may be required to be maintained below a particular threshold to ensure responsiveness and safety (see IFW: pg 2, ll 5-15 and given below)(emphasis added and comments “HUMAN” and “MAY BE A HUMAN” and “OF HUMANs” added by the examiner below):
Summary of the invention
As mobile entities (MAY BE A HUMAN), such as unmanned vehicles, move around, the quality of connection that they experience to centrally hosted services, such as a VPN, can vary greatly. For example, the latency of communications with a centrally hosted service may generally increase as the mobile entity (MAY BE A HUMAN) moves further from the location at which the cloud computing infrastructure is hosted. Some applications, particularly those associated with controlling (BY A HUMAN) unmanned vehicles (and especially unmanned aerial vehicles) may be particular sensitive to such variations. For example, latency of communications between an unmanned aerial vehicle and a controller (HUMAN) may be required to be maintained below a particular threshold to ensure responsiveness and safety (OF HUMANS).
Therefore, claims are ineligible.
3] applicant argues: (summary Remarks 5/8/26, pg 13-15)
...
Dependent claim 5 further recites "wherein at least one instance of the service is deployed after the mobile entity has begun the intended journey." Through this recited feature, claim 5 provides additional technical advantages such as reduced resource consumption as described by pg. 10, line 22 to pg. 11, line 4 of the instant specification of the present application (paragraphs [0040]-[0041] of the PGPub), which teaches, inter alia, that "delaying deployment of the instances of the service until closer to the time that they are needed by the mobile entity 240 will generally reduce the consumption of computing resources of the edge compute nodes 210 by preventing the instance of the service from running when it is not needed."
Dependent claim 6 further recites "wherein deploying, by the network service orchestrator, the respective instance of the service to each of the at least one edge compute nodes comprises scheduling deployment of each respective instance for a time prior to a scheduled start of the intended journey by the mobile entity." Through this recited feature, claim 6 provides additional technical advantages such as configuration consistency: as discussed in pg. 11, lines 22-30 of the instant specification of the present application (paragraph [0043] of the PG Pub), the communications plan allows the mobile entity to "maintain the same configuration when transitioning between different instances of the service", thereby reducing connection disruptions.
Dependent claim 10 further recites "wherein the mobile entity is an unmanned vehicle." Through this recited feature, claim 10 provides additional technical advantages such as performance-based selection: the communications plan enables the mobile entity to monitor performance metrics (such as latency, signal strength, etc.) and intelligently switch between available edge compute nodes to maintain optimal service quality. The Office Action's apparent allegation that an unmanned vehicle amounts to no more than mere instructions is clearly incorrect, particularly in view of the teachings of the specification (see pg. 1, lines 10-11 of the original specification of the present application (paragraph [0043] of the PG Pub) defining "Unmanned vehicles are vehicles which do not have an on-board driver. .. ").
...
The examiner respectfully disagrees.
Specifically, claim 5 itself does not disclose performing and/or using any technical improvements of deploying after the mobile entity has begun or otherwise describe how the goal of reduced resource consumption is/are achieved by delayed deployment. Cited IFW specification teaches that delaying deployment will “generally reduce consumption” and does not disclose performing and/or using any technical improvements of deploying after the mobile entity has begun or otherwise describe how the goal of reduced resource consumption is/are achieved by delayed deployment.
Similarly, claim 6 itself does not disclose performing and/or using any technical improvements of deploying or scheduling deploying of instances or otherwise describe how the goal of configuration consistency is/are achieved. Cited IFW specification teaches that “a mobile entity can maintain a same configuration” and does not disclose any technical improvements of deploying or scheduling deploying of instances or otherwise describe how the goal of configuration consistency is/are achieved.
Similarly, claim 10 itself does not disclose performing and/or using any technical improvements of functionality or otherwise describe how the goal of performance-based selection is/are achieved. Cited IFW specification teaches “defining” "Unmanned vehicles are vehicles which do not have an on-board driver. ..” recites well-known propert(ies) of unmanned vehicles and does not disclose any technical improvements of functionality or otherwise describe how the goal of performance-based selection is/are achieved.
Therefore, claims are ineligible.
Applicant’s other arguments with respect to claims have been considered but are moot in view of new ground(s) of rejection.
Continued Examination Under 37 CFR 1.114
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 entered.
Claim Interpretation
Claimed “network service orchestrator” is very broadly interpretable (see cited support IFW: pg. 5, lines 28-30 and pg. 13, lines 9-11 (paras. [0021] and [0051] of PGPub 2025/056195)) (given below):
pg. 5, lines 28-30 (PGPub [0021)]:
...
A service orchestrator (not shown) can be used to deploy instances of services to the edge compute nodes 210 in order to reduce the distance 30 between an end computing device and the service, as will be described in more detail below A service orchestrator (not shown) can be used to deploy instances of services to the edge compute nodes 210 in order to reduce the distance between an end computing device and the service, as will be described in more detail below.
pg. 13, lines 9-11 (PGPub [0051]):
...
For example, the method 300 may be run alongside (or as part of) a network service orchestration system responsible for deploying service instances to edge compute nodes in a network
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-27 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The independent claim(s) 1 and 13 recite(s) method(s) of a network service orchestrator performing the method comprising deploying a service to edge compute nodes located at the edge of a radio access network that are dispersed throughout a geographical area, the method comprising: receiving a travel plan for a mobile entity (see claims 10 and 21 - unmanned vehicle or unmanned aerial vehicle), the travel plan indicating a route for an intended journey by the mobile entity (see claims 10 and 21 - unmanned vehicle or unmanned aerial vehicle) through the geographical area; selecting at least one edge compute node in the network for providing the service to the mobile entity (see claims 10 and 21 - unmanned vehicle or unmanned aerial vehicle) during the intended journey, the at least one edge compute node being selected based, at least in part on a geographical proximity of the at least one edge compute node to the route; deploying a respective instance of the service to each of the at least one edge compute nodes so that it is accessible by the mobile entity (see claims 10 and 21 - unmanned vehicle or unmanned aerial vehicle) while undertaking the intended journey; and providing a communications plan to the mobile entity (see claims 10 and 21 - unmanned vehicle or unmanned aerial vehicle), the communications plan indicating how the at least one instance of the service can be accessed during the intended journey is/are mental processes and/or mathematical concepts but for the recitation of generic “instance of (application) service” “edge compute nodes” “mobile entity” radio access nodes” “mobile stations” “unmanned vehicle” “unmanned aerial vehicle” “processor” “memory”, and nothing precludes the steps from being performed in the mind and the use of computers to automate human mental processes for receiving a travel plan for a mobile entity, selecting edge compute node(s) for providing service to the mobile entity during the intended journey, deploying instances of service at edge node(s) to be accessible by the mobile entity undertaking the intended journey and providing a communication plan to the mobile entity indicating how instance(s) of service can be accessed during the intended journey.
See independent claims 1 and 13, dependent claims 10 and 21 and IFW: pg 1, ll 8-34 & pg 2, ll 1-15 (PGPub: [0002-5]) the use of unmanned vehicles is growing rapidly and, in some cases, do not have an on-board human being present within the vehicle ... however, for some operations it is necessary or at least desirable for the autonomous vehicle to interact with a remote operator, for example, where a mission’s parameters change, the autonomous vehicle may need to consult with a remote operator for input as to its next action ... similarly, it may be necessary to keep a remote operator informed of the vehicle’s current operations to allow them to be monitored for potential issues ... it may be desirable or necessary to allow a remote operator to take control of the vehicle and, accordingly, a reliable communication link is a common requirement ... so-called Beyond Visual Line of Sight (DV-LOS) operation ... the distance between the operator and vehicle is large such that the vehicle is not in the operator’s sight ... commonly involving a reasonably large geographic area ... as a result the vehicle is likely to be beyond range of direct communication with an operator (who is also referred to as a ground station) ... it is therefore common to make use of communication networks such as radio access networks to allow operator(s) to communicate with vehicle(s) ... overlay network services may be used to facilitate communication between operator(s) and vehicle(s) ... common to use VPN services in cloud to secure communications (IFW: pig 1, ll 8-22 & pg 2, ll 1-15 (PGPub: [0002-5]).
See independent claims 1, 13 and 24, dependent claims 3, 4 and 6 and cited by applicant IFW: pg 5, ll 28-30 & pg 13, ll 9-11 (PGPub: [0021;51]) for now claimed ‘network service orchestrator’ appears to map to very high-level generic IFW disclosure of ‘service orchestrator’ and service orchestrator (not shown) can be used to deploy instances of services to the edge compute nodes 210 in order to reduce the distance between an end computing device and services and IFW further discloses at a very high-level and generically that, for example, the method 300 may be run alongside (or as part of) a network service orchestration system responsible for deploying service instances to edge compute nodes in a network.
If claim limitation(s), under broadest reasonable interpretation, covers performance of the limitations automating human activity and/or performance in the mind but for the recitation of generic “computer hardware”, then it falls within the “certain methods of organizing human activity” and/or “mental processes”. Accordingly, the claim(s) recites an abstract idea (Step 2A Prong One).
This judicial exception is not integrated into a practical application because the additional elements of “network service orchestrator” “instance of (application) service” “edge compute nodes” “mobile entity” radio access nodes” “mobile stations” “unmanned vehicle” “unmanned aerial vehicle” “processor” “memory” amounts to no more than mere instructions to apply the exception using generic computer component claimed at a high-level of abstraction. That is, the additional elements are not an improvement in the functioning of a computer or other technology, they do not implement the judicial exception with a particular machine integral to the claim(s), and they do not use the judicial exception in some meaningful way beyond generally linking the use of the judicial exception to a particular technological environment of a computer. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the claim(s) as a whole, looking at the elements individually and in combination, does not integrate the abstract idea into a practical application.
Furthermore, independent claims 1 and 13, dependent claims 10 and 21 and IFW: pg 1, ll 8-34 & pg 2, ll 1-15 (PGPub: [0002-5]) recite the claimed automation of receiving, selecting, deploying, providing, etc is not a technological improvement but, rather, “automates” otherwise manual human driver processes replaced by unmanned vehicles that nonetheless by “common requirements” need/require interactions and/or monitoring by human operators (see at least IFW: pg 1, ll 7-19). Furthermore, the claims themselves and/or IFW do not disclose performing and/or using any technical improvements of claimed service controller and/or claimed communication plans or otherwise describe how the goal(s) of reduced latency, service continuity, resource optimization and/or adaptability is/are achieved (see Remarks 5/8/26, pg 10-16). Accordingly, the claim(s) recite an abstract idea. (Step 2A Prong Two, Step 2B). The claim(s) is/are not patent eligible.
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 1-7,10,13-14,19,21 and 24-25 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Publication No. 2022/0332350 to Jha et al. (“Jha”) in view of U.S. Patent No. 2018/0102831 to Murphy et al. (“Murphy”).
As to claim 1, Jha discloses a computer implemented method of deploying a service to edge compute nodes located at the edge of a radio access network that are dispersed throughout a geographical area, the method performed by a network service orchestrator (mobile edge orchestrator) (Jha: fig 1-24, [0007-345]: ... NAN (network access node) 130 enables connections 112 may be referred to as RAN node or the like ... may comprise ground stations e.g. terrestrial access points or satellite stations providing coverage within a geographic area e.g. a cell (deploying a service to ... compute nodes located at the ... radio access network that are dispersed throughout a geographical area) [0053] ... NAN 130 is co-located with an edge compute node 140 or collection of edge compute node 140 providing any number of services/ capabilities 180 to vehicles 110 ... edge nodes may also provide orchestration of multiple applications (see with [0053] above - deploying a service to edge compute nodes located at the edge of a radio access network that are dispersed throughout a geographical area) [0056] ... aspects of an edge cloud architecture that covers multiple potential deployments and addresses restrictions that some network operators or service providers may have in their own infrastructures ... like resources available to edge locations, tiers of locations, or groups of locations; the service, security, and management and orchestration capabilities; and related objectives to achieve usability and performance of end services and these deployments may accomplish processing in network layers that may be considered as "near edge", "close edge", "local edge", "middle edge", or "far edge" layers, depending on latency, distance, and timing characteristics (see with [0053;56] above - deploying a service to edge compute nodes located at the edge of a radio access network that are dispersed throughout a geographical area) [0337] ... services and functions operating on these various types of multi-entity partitions may be load-balanced, migrated, and orchestrated to accomplish necessary service objectives and operations (see with [0053;56] above - deploying a service to edge compute nodes located at the edge of a radio access network that are dispersed throughout a geographical area) [0333] ... various implementations and configurations of the edge computing system may be provided dynamically, such as when orchestrated to meet service objectives (see with [0053;56;333] above - deploying a service to edge compute nodes located at the edge of a radio access network that are dispersed throughout a geographical area) [0345]), the method comprising:
receiving, by the network service orchestrator (Jha: fig 1-24, [0007-345]: ... Maneuver Intention Container provides a way to share (receiving) a station's planned intention(s) (see with [0053;56;333;345] above - receiving, by the network service orchestrator) [0139]),
a travel plan for a mobile entity, the travel plan indicating a route for an intended journey by the mobile entity through the geographical area (Jha: fig 1-24, [0007-345]: fig 8 & 12 & 14a-b & 16 & 18 ... Maneuver Sharing Container may carry two containers, including a Maneuver Intention Container and a Planned Trajectory Container (a travel plan for a mobile entity, the travel plan indicating a route for an intended journey by the mobile entity through the geographical area) ... Maneuver Intention Container may include information of intended action(s) given the current traffic situation such as lane change, highway merge, etc. The Planned Trajectory Container includes information used to execute the intended maneuver (a travel plan for a mobile entity, the travel plan indicating a route for an intended journey by the mobile entity through the geographical area) [0138]).
Jha did not explicitly disclose selecting, by the network service orchestrator, at least one edge compute node in the network for providing the service to the mobile entity during the intended journey, the at least one edge compute node being selected based at least in part on a geographical proximity of the at least one edge compute node to the route.
Murphy discloses selecting, by the network service orchestrator (Murphy: fig 1-9, [0006-99]: fig 1 & 4-5 ... UAV network cell controller (network service orchestrator) 118 ... UAV network cell controller 118 may dispatch (select) an UAV network cell to provide network coverage at a geographical area using control commands (selecting, by the network service orchestrator) and in determining whether to dispatch an UAV network cell, the UAV network cell controller 118 may take into consideration ... a multitude of other factors and factors may include weather conditions, geographical features, network service capacity, governmental flight regulations and restrictions, and/or so forth. In some instances, the UAV network cell may be tasked to provide a network cell that covers a largest portion of the geographical area [0030]),
at least one edge compute node in the network for providing the service to the mobile entity during the intended journey, the at least one edge compute node being selected based at least in part on a geographical proximity of the at least one edge compute node to the route orchestrator (Murphy: fig 1-9, [0006-99]: fig 1 & 4-5 ... UAV network cell controller (network service orchestrator) 118 ... UAV network cell controller 118 may dispatch (select) an UAV network cell (at least one edge compute node) to provide network coverage at a geographical area using control commands (selecting, by the network service orchestrator, at least one edge compute node in the network for providing the service ...) and in determining whether to dispatch an UAV network cell, the UAV network cell controller 118 may take into consideration ... a multitude of other factors and factors may include weather conditions, geographical features, network service capacity, governmental flight regulations and restrictions, and/or so forth (... the at least one edge compute node being selected based at least in part on a geographical proximity of the at least one edge compute node to the route orchestrator) and in some instances, the UAV network cell may be tasked to provide a network cell that covers a largest portion of the geographical area (... at least one edge compute node in the network for providing the service to the mobile entity) [0030] ... parameters of the deployment may include a size of the geographical area, a number of user devices that are expected to be in the geographical area, the expected ground movement speed of the user devices to be served, the elevations of geographical features in the geographical area, the proximity of the nearest ground base station to the geographical area, and/or other factors (see with [0030] above - selecting, by the network service orchestrator, at least one edge compute node in the network for providing the service to the mobile entity during the intended journey, the at least one edge compute node being selected based at least in part on a geographical proximity of the at least one edge compute node to the route orchestrator) [0051]).
Jha and Murphy are analogous art because they are from the same field of endeavor with respect to UAVs.
Before the effective filing date, for AIA , it would have been obvious to a person of ordinary skill in the art to incorporate strategies by Murphy into the method by Jha. The suggestion/motivation would have been to provide techniques for using unmanned aerial vehicles (UAVs) to provide cellular network communication coverage and in some scenarios, UAVs (as mobile enti(ties)) carrying communication equipment that provides network cells, referred to as UAV network cells, may be dispatched to a geographical region (Murphy: [0015]).
Jha and Murphy further disclose deploying, by the network service orchestrator (Murphy: fig 1-9, [0006-99]: fig 1 & 4-5 ... UAV network cell controller (network service orchestrator) 118 ... UAV network cell controller 118 may dispatch (select/deploy) an UAV network cell to provide network coverage at a geographical area using control commands (selecting/deploying, by the network service orchestrator ...) and in determining whether to dispatch (select/deploy) an UAV network cell, the UAV network cell controller 118 may take into consideration (selecting/deploying, by the network service orchestrator ...) ... a multitude of other factors and factors may include weather conditions, geographical features, network service capacity, governmental flight regulations and restrictions, and/or so forth. In some instances, the UAV network cell may be tasked to provide a network cell that covers a largest portion of the geographical area [0030]),
a respective instance of the service to each of the at least one edge compute nodes so that it is accessible by the mobile entity while undertaking the intended journey (Murphy: fig 1-9, [0006-99]: ... the dispatch module 414 may supplement a currently operating UAV network cell with one or more additional UAV network cells by dividing an existing geographical area served by the currently operating UAV network cell into multiple portions and, in this way, each portion of the geographical area may be served by an UAV network cell and for example, the dispatch module 414 may receive a signal from the trajectory calculation module 416 indicating that a flight trajectory cannot be computed for an UAV network cell such that the UAV cell is able to reach a group of user devices in a particular section of a geographical area (a respective instance of the service to each of the at least one edge compute nodes ...) due to an obstacle in the form of a structure or terrain feature and in response, the dispatch module 414 may divide the geographical area into two portions, and dispatch another UAV network cell to reach the group of user devices in the previously unreachable portion from a different direction (a respective instance of the service to each of the at least one edge compute nodes so that it is accessible by the mobile entity while undertaking the intended journey) and dispatch module 414 may further recall an UAV network cell from a geographical area when the presence of the UAV network cell is no longer necessary and in various instances, the dispatch module 414 may recall the UAV network cell when a number of subscriber user devices in the geographical area drops below a predetermined threshold [0057]); and
providing, by the network service orchestrator (Murphy: fig 1-9, [0006-99]: fig 1 & 4-5 ... a user device may measure the signal robustness of communication signals that the user device is receiving from the UAV network cell as the UAV network cell travels along a flight path ... measured signal robustness values are then transmitted by the user device to the UAV network cell and, in turn, the UAV network cell may forward the measurements to the UAV network cell controller 118 [0059] ... in this way, the trajectory calculation module 416 (see fig 4 - the trajectory calculation module 416 is within UAV network cell controller 118) may use the multiple signal robustness values provided by each user device to triangulate a geolocation of each user device in a geographical area (providing, by the network service orchestrator ...) [0059]),
a communications plan to the mobile entity, the communications plan indicating how the at least one instance of the service can be accessed during the intended journey (Murphy: fig 1-9, [0006-99]: fig 1 & 4-5 ... in some scenarios, UAVs (as mobile enti(ties)) carrying communication equipment that provides network cells, referred to as UAV network cells (a respective instance of the service to each of the at least one edge compute nodes ...), may be dispatched to a geographical region (... so that it is accessible by the mobile entity while undertaking the intended journey) [0015] ... trajectory calculation module 416 may generate a flight trajectory for the UAV network cell based on the geolocations of user devices in the geographical area (see with [0015] above - a communications plan to the mobile entity ...) and in various embodiments, the flight trajectory may be calculated such that the UAV network cell provides supplement network coverage to different groups of user devices in the geographical area (see with [0015] above - ... the communications plan indicating how the at least one instance of the service can be accessed during the intended journey) ... trajectory calculation module 416 may use a best fit algorithm e.g., least squares function, chi square function, etc. to generate a flight trajectory that fits the UAV network cell within the geolocations of the user devices in the group (see with [0015] above - a communications plan to the mobile entity, the communications plan indicating how the at least one instance of the service can be accessed during the intended journey) [0060] ... trajectory calculation module 416 may continuously or periodically recalculate the flight trajectory as the geolocations of the user devices change (see with [0015;60] above - a communications plan to the mobile entity, the communications plan indicating how the at least one instance of the service can be accessed during the intended journey) [0061]) ... flight control module 418 may convert a flight trajectory that is calculated for an UAV network cell into control commands for the UAV network cell (see with [0015;60-61] above - a communications plan to the mobile entity, the communications plan indicating how the at least one instance of the service can be accessed during the intended journey) [0064]).
Same motivation applies as mentioned above to make the proposed modification.
As to claim 2, see similar rejection to claim 1 where the method is taught by the method.
As to claim 2, Jha and Murphy further disclose wherein a plurality of edge compute nodes are selected, each edge compute node being associated with a respective portion of the route over which it is to provide the service to the mobile entity and being selected based, at least in part on a geographical proximity of the edge compute node to the respective portion of the route (Murphy: fig 1-9, [0006-99]: fig 1 & 4-5 ... the dispatch module 414 may supplement a currently operating UAV network cell with one or more additional UAV network cells by dividing an existing geographical area served by the currently operating UAV network cell into multiple portions (wherein a plurality of edge compute nodes are selected ... and being selected based, at least in part on a geographical proximity of the edge compute node to the respective portion of the route) and, in this way, each portion of the geographical area may be served by an UAV network cell (... each edge compute node being associated with a respective portion of the route over which it is to provide the service to the mobile entity ...) [0057] ... parameters of the deployment may include (see with [0057] above - wherein a plurality of edge compute nodes are selected ...) a size of the geographical area, a number of user devices that are expected to be in the geographical area (see with [0057] above - ... each edge compute node being associated with a respective portion of the route over which it is to provide the service to the mobile entity), the expected ground movement speed of the user devices to be served, the elevations of geographical features in the geographical area, the proximity of the nearest ground base station to the geographical area (see with [0057] above - ... being selected based, at least in part on a geographical proximity of the edge compute node to the respective portion of the route), and/or other factors [0051]).
For motivation, see rejection of claim 1.
As to claim 3, see similar rejection to claims 1-2.
As to claim 3, Jha and Murphy further disclose wherein deploying, by the network service orchestrator (Murphy: fig 1-9, [0006-99]: fig 1 & 4-5 ... UAV network cell controller (network service orchestrator) 118 ... UAV network cell controller 118 may dispatch (select/deploy) an UAV network cell to provide network coverage at a geographical area using control commands (selecting/deploying, by the network service orchestrator ...) and in determining whether to dispatch (select/deploy) an UAV network cell, the UAV network cell controller 118 may take into consideration (selecting/deploying, by the network service orchestrator ...) ... a multitude of other factors and factors may include weather conditions, geographical features, network service capacity, governmental flight regulations and restrictions, and/or so forth. In some instances, the UAV network cell may be tasked to provide a network cell that covers a largest portion of the geographical area [0030]),
the respective instance of the service to each of the edge compute nodes comprises scheduling, by the network service orchestrator, deployment of each respective instance for a time prior to a time at which the mobile entity is scheduled to start the associated portion of the route (Jha: fig 1-24, [0007-345]: fig 8 & 12 & 14a-b & 16 & 18 ... Planned Trajectory Container is used to share a planned/predicted trajectory as a cumulative result of one or more intentions over a predefined time in the future (the respective instance of the service to each of the edge compute nodes comprises scheduling, by the network service orchestrator, deployment of each respective instance for a time prior to a time at which the mobile entity is scheduled to start the associated portion of the route) and stations (the respective instance of the service to each of the edge compute nodes) can send multiple trajectories with different priorities (deployment of each respective instance for a time prior to a time at which the mobile entity is scheduled to start the associated portion of the route) [0141];
Murphy: fig 1-9, [0006-99]: fig 1 & 4-5 ... the dispatch module 414 may supplement a currently operating UAV network cell with one or more additional UAV network cells by dividing an existing geographical area served by the currently operating UAV network cell into multiple portions (the respective instance of the service to each of the edge compute nodes comprises scheduling, by the network service orchestrator, deployment of each respective instance ...) and, in this way, each portion of the geographical area may be served by an UAV network cell (the respective instance of the service to each of the edge compute nodes comprises scheduling, by the network service orchestrator, deployment of each respective instance...) [0057] ... the trajectory calculation module 416 may further analyze operation condition data 424 related to a geographical area during the calculation of a flight trajectory for the UAV network cell (...deployment of each respective instance for a time prior to a time at which the mobile entity is scheduled to start the associated portion of the route) and, for example, operation condition data 424 may show natural and/or manmade structures in the geographical area that affect the calculation of the flight trajectory for the UAV network cell (...deployment of each respective instance for a time prior to a time at which the mobile entity is scheduled to start the associated portion of the route) e.g., structures that have to be evaded by the UAV network cell, terrain features that may block signal transmission, weather phenomenon that have to be avoided by the UAV network cell, and/or newly implemented governmental flight regulations or flight restrictions that may force the trajectory calculation module 416 to alter the calculated flight trajectory (...deployment of each respective instance for a time prior to a time at which the mobile entity is scheduled to start the associated portion of the route) and flight trajectory may be configured by the trajectory calculation module 416 to evade a structure or terrain feature by causing the UAV to fly around or over the structure or terrain feature [0063]).
For motivation, see rejection of claim 1.
As to claim 4, see similar rejection to claims 1-3.
As to claim 4, Jha and Murphy further disclose wherein removing, by the network service orchestrator (Murphy: fig 1-9, [0006-99]: fig 1 & 4-5 ... UAV network cell controller (network service orchestrator) 118 ... UAV network cell controller 118 may dispatch (select/deploy/remove) an UAV network cell to provide network coverage at a geographical area using control commands (selecting/deploying, by the network service orchestrator ...) and in determining whether to dispatch (select/deploy/remove) an UAV network cell, the UAV network cell controller 118 may take into consideration (selecting/deploying, by the network service orchestrator ...) ... a multitude of other factors and factors may include weather conditions, geographical features, network service capacity, governmental flight regulations and restrictions, and/or so forth. In some instances, the UAV network cell may be tasked to provide a network cell that covers a largest portion of the geographical area [0030]) ),
the respective instance of the service deployed to an edge compute node after the mobile entity has completed the respective portion of the route over which that instance is to provide the service to the mobile entity (Murphy: fig 1-9, [0006-99]: fig 1 & 4-5 ... dispatch module 414 may further recall (remove) an UAV network cell from a geographical area when the presence of the UAV network cell is no longer necessary and dispatch module 414 may recall the UAV network cell when a number of subscriber user devices in the geographical area drops below a predetermined threshold (after the mobile entity has completed the respective portion of the route over which that instance is to provide the service to the mobile entity) [0057]).
For motivation, see rejection of claim 1.
As to claim 5, see similar rejection to claims 1-4.
As to claim 5, Jha and Murphy further disclose wherein at least one instance of the service is deployed after the mobile entity has begun the intended journey (Murphy: fig 1-9, [0006-99]: fig 1 & 4-5 ... for example, the dispatch module 414 may receive a signal from the trajectory calculation module 416 indicating that a flight trajectory cannot be computed for an UAV network cell such that the UAV cell is able to reach a group of user devices in a particular section of a geographical area due to an obstacle in the form of a structure or terrain feature (... after the mobile entity has begun the intended journey) and in response, the dispatch module 414 may divide the geographical area into two portions, and dispatch another UAV network cell (wherein at least one instance of the service is deployed after the mobile entity has begun the intended journey) to reach the group of user devices in the previously unreachable portion from a different direction [0057]).
For motivation, see rejection of claim 1.
As to claim 6, see similar rejection to claim 3.
As to claim 7, see similar rejection to claims 1-6.
As to claim 7, Jha and Murphy further disclose wherein the selection of an edge compute node is further based on one or more previously recorded measurements of communications between a radio access node associated with the edge compute node and one or more mobile stations in proximity to the route (Murphy: fig 1-9, [0006-99]: fig 1 & 4-5 ... UAV database provides specifications and statuses of UAV network cells that are available for deployment (wherein the selection of an edge compute node is further based on ...) by cellular communication carrier(s) and a map database may provide geographical information, terrain information, road infrastructure information, natural or manmade structure information, and/or so forth (... one or more previously recorded measurements of communications between a radio access node associated with the edge compute node and one or more mobile stations in proximity to the route) and a network operations database may provide the locations and specifications of the ground base stations and other network components of the wireless carrier network 102, as well as historical usage patterns and trends of subscriber user devices for different geographical areas (... one or more previously recorded measurements of communications between a radio access node associated with the edge compute node and one or more mobile stations in proximity to the route) and a dispatch module 414 may use machine learning to determine whether to dispatch a particular UAV network cell based on the data from the flight operation data sources (wherein the selection of an edge compute node is further based on ...) [0054] ... UAV network cell controller (network service orchestrator) 118 ... UAV network cell controller 118 may dispatch (selection ...) an UAV network cell (... of an edge compute node) to provide network coverage at a geographical area using control commands (wherein the selection of an edge compute node is further based on ...) and in determining whether to dispatch an UAV network cell, the UAV network cell controller 118 may take into consideration ... a multitude of other factors and factors may include weather conditions, geographical features, network service capacity, governmental flight regulations and restrictions, and/or so forth (see with [0054] above - ... measurements of communications between a radio access node associated with the edge compute node and one or more mobile stations in proximity to the route) and in some instances, the UAV network cell may be tasked to provide a network cell that covers a largest portion of the geographical area (... at least one edge compute node in the network for providing the service to the mobile entity) [0030] ... parameters of the deployment may include a size of the geographical area, a number of user devices that are expected to be in the geographical area, the expected ground movement speed of the user devices to be served, the elevations of geographical features in the geographical area, the proximity of the nearest ground base station to the geographical area, and/or other factors (see with [0030;54] above - measurements of communications between a radio access node associated with the edge compute node and one or more mobile stations in proximity to the route) [0051];
Jha: fig 1-24, [0007-345]: ... aspects of an edge cloud architecture that covers multiple potential deployments and addresses restrictions that some network operators or service providers may have in their own infrastructures ... deployments may accomplish processing in network layers that may be considered as "near edge", "close edge", "local edge", "middle edge", or "far edge" layers, depending on latency, distance, and timing characteristics [0337])
For motivation, see rejection of claim 1.
As to claim 10, Jha and Murphy disclose wherein the mobile entity is an unmanned vehicle and optionally wherein the mobile entity is an unmanned aerial vehicle (Jha: fig 1-24, [0007-345]: ... embodiments described herein may also be applicable to 3D deployment scenarios where some or all of the vehicles 110 are implemented as flying objects, such as aircraft, drones, UAVs, and/or to any other like motorized devices [0032];
Murphy: fig 1-9, [0006-99]: fig 1 & 4-5 ... UAV database provides specifications and statuses of UAV network cells that are available for deployment by cellular communication carrier(s) and a map database may provide geographical information, terrain information, road infrastructure information, natural or manmade structure information, and/or so forth and a network operations database may provide the locations and specifications of the ground base stations and other network components of the wireless carrier network 102, as well as historical usage patterns and trends of subscriber user devices for different geographical areas and a dispatch module 414 may use machine learning to determine whether to dispatch a particular UAV network cell based on the data from the flight operation data sources [0054]).
For motivation, see rejection of claim 1.
As to claims 13-14, 19 and 21, see similar rejection to claims 1-2, 7 and 10, respectively, where the method is taught by the method.
As to claims 24 and 25, see similar rejection to claim 1 where the system and medium, respectively, is/are taught by the method.
Claims 8-9, 15-16 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Publication No. 2022/0332350 to Jha et al. (“Jha”) in view of U.S. Patent No. 2018/0102831 to Murphy et al. (“Murphy”) and further in view of U.S. Patent Publication No. 2020/0249039 to Lassoued et al. (“Lassoued”).
As to claim 8, see similar rejection to claims 1-7.
For motivation, see rejection of claim 1.
Jha did not explicitly disclose wherein more than one edge compute node is selected for providing the service to the mobile entity during at least part of the route and the communications plan indicates a plurality of options for accessing the service during that part of the route.
Lassoued discloses wherein more than one edge compute node is selected for providing the service to the mobile entity during at least part of the route and the communications plan indicates a plurality of options for accessing the service during that part of the route (Lassoued: fig 1-7, [0005-84]: ... cognitive system may generate one or more optimized plans of computational unit handover e.g. VM handover, state handover for each vehicle, including servers and timing (wherein more than one edge compute node is selected for providing the service to the mobile entity during at least part of the route ...) ... while assuring sufficiently low latency and smooth transition throughout the journey ... infers most probably routes e.g. k routes having a highest probability/ percentage above a defined threshold ... load balancing operation performed for selection/refinement of optimum handover schedules to balance load across MEC servers (... the communications plan indicates a plurality of options for accessing the service during that part of the route) [0066-67]).
Jha, Murphy and Lassoued are analogous art because they are from the same field of endeavor with respect to vehicles.
Before the effective filing date, for AIA , it would have been obvious to a person of ordinary skill in the art to incorporate strategies by Lassoued into the method by Jha and Murphy. The suggestion/motivation would have been to provide 3D deployment scenarios where some or all of the vehicles 110 are implemented as flying objects, such as aircraft, drones, UAVs, and/or to any other like motorized devices (Jha: [0032]) in arrangements of edge computing applications and services accessible via mobile wireless networks e.g., cellular and WiFi data networks may be referred to as "mobile edge computing" or "multiaccess edge computing", which may be referenced by the acronym "MEC" (Jha: [0391]) and provide an environment for implementing unmanned aerial vehicle (UAV)-based cellular communication service delivery (Murphy: [0020]) and provide mobility-prediction based operations for planning vehicle computational unit migration e.g., VM migration, state migration in FEC cloud computing environment and provide for planning the migration of virtual machines associated with moving vehicles in a follow-me (mobile-edge) cloud (Lassoued: [0018]).
As to claim 9, see similar rejection to claims 1-8.
As to claim 9, Jha, Murphy and Lassoued further disclose wherein the instances of the service deployed to the plurality of edge compute nodes are configured to allow the mobile entity to maintain the same configuration when transitioning between different instances of the service (Lassoued: fig 1-7, [0005-84]: ... various embodiments provide a mobility-prediction based operations for planning vehicle computational unit e.g. VM migration, state migration (configured to allow the mobile entity to maintain the same configuration when transitioning between different instances of the service) in MEC cloud computing environment (wherein the instances of the service deployed to the plurality of edge compute nodes ...) ... provides for planning the migration (scheduling deployment) of virtual machines associated with moving vehicles in a follow-me mobile-edge cloud (wherein the instances of the service deployed to the plurality of edge compute nodes ...) [0018]).
For motivation, see rejection of claim 8.
As to claims 15-16 and 20, see similar rejection to claims 8-9 and 9, respectively, where the method is taught by the method
Claims 26-27 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Publication No. 2022/0332350 to Jha et al. (“Jha”) in view of U.S. Patent No. 2018/0102831 to Murphy et al. (“Murphy”), U.S. Patent Publication No. 2020/0249039 to Lassoued et al. (“Lassoued”) and further in view of U.S. Patent Publication No. 2021/0112441 to Sabella et al. (“Sabella”).
As to claim 26, Jha, Murphy and Lassoued disclose the method of claim 1 (Lassoued: fig 1-7, [0005-84]: ... the present invention provides for planning computational unit migration e.g., VM migration, state migration (wherein the communications plan comprises ... plurality of the edge compute nodes in the network) based on vehicle mobility prediction and inferring/predicting a travel route (an ordered list of a plurality of the edge compute nodes in the network) of a user e.g., vehicle , the present invention may provide a layered Hidden Markov Model (HMM) to predict the next MEC areas (for providing the service to the mobile entity during the intended journey) and input of the first layer may be map-matched GPS coordinates and the output may be the inferred/predicted routes and the predicted routes may be used as observations to a second HMM, which predicts the sequence of traversed MEC areas (wherein the communications plan comprises an ordered list of a plurality of the edge compute nodes in the network for providing the service to the mobile entity during the intended journey) [0075).
For motivation, see rejection of claim 8.
Jha did not explicitly disclose wherein the communications plan comprises an ordered list of a plurality of the edge compute nodes in the network for providing the service to the mobile entity during the intended journey.
For clarity, Sabella discloses wherein the communications plan comprises an ordered list of a plurality of the edge compute nodes in the network for providing the service to the mobile entity during the intended journey (Sabella: fig 1-18, [0002-199]: the coverage map is used not only for travel planning but also trajectory and route sharing ratings to optimize overall, both communication and vehicular, traffic efficiency and road safety (wherein the communications plan comprises ... a plurality of the edge compute nodes in the network for providing the service to the mobile entity during the intended journey) [0081] ... PQoS system supports two communication protocols i) sensor data-based local perception communication protocol among vehicles or between vehicles and other traffic participants and ii) application-level communication protocol between in-vehicle MEC apps 206 and central MEC app 702 enabling in-vehicle construction of the city’s predicted digital twin based on parameters of a global PQoS prediction model [0082] ... vehicles are equipped with a human machine interface (HMI) 708 e.g. display, button, touchscreen to provide input on the trip origin’s location, time and end journey and display of the HMI 708 shows a map of geographical support of various services (see with [0081-82] above - wherein the communications plan comprises ... a plurality of the edge compute nodes in the network for providing the service to the mobile entity during the intended journey) ... a local PF 302 executing at each in-vehicle MEC host obtains local contextual information and shared route preferences as input and issues joint radio and edge cloud QoS predictions for all involved locations and times as output (see with [0081-82] above - wherein the communications plan comprises an ordered list of a plurality of the edge compute nodes in the network for providing the service to the mobile entity during the intended journey), based on a local update of the previously downloaded region-wide QoS prediction model ... central MEC app 702 builds a global regional PQoS prediction model by aggregating local prediction model updates tailored to a set of mobility service [0087-88] ... for example, HMI 708 may be used to enter the destination for a current trip and stopovers or waypoints (see with [0081-82;87-88] above - wherein the communications plan comprises an ordered list of a plurality of the edge compute nodes in the network for providing the service to the mobile entity during the intended journey) and for a future trip, a starting location could be entered via HMI 708 [0090] and see tables 1 and 2 and ‘routeInfo’ with cardinality 2 ... N and remarks: Information relating to a specific route. The first structure shall relate to the route origin and the last to the route destination. Intermediate waypoint locations may also be provided (see with [0081-82;87-88] above - wherein the communications plan comprises an ordered list of a plurality of the edge compute nodes in the network for providing the service to the mobile entity during the intended journey) [0098-101]).
Jha, Murphy and Lassoued are analogous art because they are from the same field of endeavor with respect to mobility.
Before the effective filing date, for AIA , it would have been obvious to a person of ordinary skill in the art to incorporate strategies by Sabella into the method by Jha, Murphy and Lassoued. The suggestion/motivation would have been to provide for improving transportation services in a multi-provider environment (Sabella: [0001]).
As to claim 27, see similar rejection to claim 26 where the medium is taught by the method.
Claims 11-12, 17-18 and 22-23 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Publication No. 2022/0332350 to Jha et al. (“Jha”) in view of U.S. Patent No. 2018/0102831 to Murphy et al. (“Murphy”), U.S. Patent Publication No. 2020/0249039 to Lassoued et al. (“Lassoued”) and further in view of U.S. Patent No. 11405801 to Qureshi et al. (“Qureshi”).
As to claim 11, Jha, Murphy and Lassoued disclose the method of claim 1.
For motivation, see rejection of claim 8.
Jha did not explicitly disclose wherein the service is a network service for enabling communication between the unmanned vehicle and a control server for controlling the unmanned.
Qureshi discloses wherein the service is a network service for enabling communication between the unmanned vehicle and a control server for controlling the unmanned (Qureshi: fig 1-8, col 1-col 21: ... a provider substrate 224 (PSE) provides resources and services of cloud provider network 203 ... UV 111 (fig 1A) or radio unit 163 (fig 1C) may include PSE 224 in order to execute customer workloads ... PSE 224 can be configured to provide capacity for cloud-based workloads to run within telecommunications network ... to provide core and/or RAN functions (wherein the service is a network service for enabling communication between the unmanned vehicle and a control server for controlling the unmanned vehicle) (col 14 ll 41-59) ... local network manager(s) 242 can run on PSE 224, for example, by acting as a VPN endpoint or endpoints between PSE 224 and proxies 245 248 in cloud provider network 203 (a virtual private network, VPN, service) (col 17 ll 11-42) ).
Jha, Murphy, Lassoued and Qureshi are analogous art because they are from the same field of endeavor with respect to unmanned vehicles (UVs).
Before the effective filing date, for AIA , it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Qureshi into the method by Jha, Murphy and Lassoued. The suggestion/motivation would have been to provide UVs for deploying and augmenting radio-based networks (Qureshi: col 3 ll 30-46)).
As to claim 12, Jha, Murphy, Lassoued and Qureshi disclose deploying a respective instance of an application service for the unmanned vehicle to each of the at least one edge compute nodes alongside the instances of the network service (Qureshi: fig 1-8, col 1-col 21: ... UVs themselves may incorporate or carry resources that can provide edge computing capacity (deploying a respective instance of an application service for the unmanned vehicle to each of the at least one edge compute nodes ...) and/or network connectivity to geographies that need such resources (... alongside the instances of the network service) ... UVs may provide edge computing capacity and/or network connectivity while flying or while stationary (col 2 ll 39-56)).
For motivation, see rejection of claim 11.
As to claim 17, Jha, Murphy, Lassoued and Qureshi disclose wherein the determination to switch is made in response to detecting that the respective performance of accessing the service via the currently selected edge compute node is below a predetermined threshold (Qureshi: fig 1-8, col 1-col 34: ... UV fleet management service 426 determines that a radio unit 163 (fig 1C) for RBN 103 (fig 1A) needs servicing or replacement ... may determine that radio unit 163 is running low on battery e.g. having a charge level below a threshold (... detecting that the respective performance of accessing the service via the currently selected edge compute node is below a predetermined threshold) ... may seek a UV 111 based on proximity of UV 111 to the location of the radio unit 163 or proximity of UV 111 to a replacement hardware component or replacement battery ... UV 111 may physically exchange a battery in the radio unit 163 (wherein the determination to switch is made in response to ...) (col 33 ll 58-67 & col 34 ll 1-64) ).
For motivation, see rejection of claim 10.
As to claim 18 Jha, Murphy, Lassoued and Qureshi disclose wherein the determination to switch is made in response to detecting that a difference in between the performance of accessing the service via the currently selected edge compute node and the performance of accessing the service via another of the edge compute nodes is greater than a predetermined threshold (Qureshi: fig 1-8, col 1-col 34: ... UV fleet management service 426 may determine that a demand for edge computing capacity or network connectivity may require radio unit 163 of a first type be replaced with a different radio unit 163 of a second type and the different radio unit 163 may have more data storage, more computing resources etc (... detecting that a difference in between the performance of accessing the service via the currently selected edge compute node and the performance of accessing the service via another of the edge compute nodes is greater than a predetermined threshold) ... UV 111 may deliver a replacement radio unit 163 and retrieve the other radio unit 163 as payload (wherein the determination to switch is made in response to ...) (col 33 ll 67 & col 34 ll 1-64)).
For motivation, see rejection of claim 10.
As to claims 22-23, see similar rejection to claims 11-12, respectively, where the method is taught by the method.
Conclusion
The following prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
A) US 20240363009 – Raghavan
This disclosure provides systems, methods, and devices for wireless communication that support vehicle path deviation reporting and updating. In a first aspect, a method of wireless communication performed at a vehicle includes generating movement data based on traversing from a first location to a second location. The traversing is based on path information that indicates a plurality of waypoints designated to be traversed by the vehicle. The method also includes transmitting statistical information generated based on the movement data and the plurality of waypoints. The movement data is associated with an actual path of the vehicle. The plurality of waypoints are associated with an interpolated path of the vehicle. Other aspects and features are also claimed and described.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUNE SISON whose telephone number is (571)270-5693. The examiner can normally be reached 9:00 am - 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, Emmanuel Moise can be reached at 571-272-3865. 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.
/JUNE SISON/Primary Examiner, Art Unit 2455
Prosecution Insights