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 1/9/26.
Amendments to the IFW specification is not entered. See details below.
101 rejection is maintained. See details below.
Response to Arguments
Applicant's arguments filed 1/9/26 have been fully considered but they are not persuasive.
1] applicant argues (Remarks 1/9/26 summary pg 13-16)(emphasis added)
...
A. 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:
<omitted citation of MPEP>
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.
For example, claim 1 recites the following features:
<omitted citation of claim 1>
Through these recited features, 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 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 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 limitations of claim 1 involving the "communications plan" that tells the mobile entity (such as, for example, an unmanned vehicle) how to access services along its journey provide multiple technical advantages that collectively improve network connection for the mobile entity when moving around, including:
• Reduced latency: by providing information about which edge compute nodes to connect to along the route, the mobile entity can access services from nodes that are geographically closer, resulting in lower communication latency compared to accessing centralized cloud services;
• Service continuity: the communications plan enables the mobile entity to maintain continuous access to services throughout its journey by providing a structured way to transition between different edge compute nodes as it moves;
• Resource optimization: by having a plan that specifies which nodes to connect to and when, the system avoids unnecessary resource usage and ensures services are deployed only when and where needed; and
• Adaptability: the mobile entity can use the communications plan to select the most appropriate edge compute node based on current network conditions rather than being locked into a predetermined connection.
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.
Per applicant’s original IFW specification “remote operator” “controller” “ground station” “mobile entity” are interchangeably used to describe humans operating and/or controlling and/or monitoring unmanned vehicles as a common requirement over reliable communication (i.e. “reduced latency” “resource optimization” “adaptability”) between the unmanned vehicle and human(s) (see IFW: pg 1, ll 7-33 & pg 2, ll 1-4; pg. 6, ll 11-19 and given below)(emphasis added and comments “HUMAN” and “BY A HUMAN” and “UNMANNED VEHICLE AND HUMAN” added by the examiner below):
[IFW: pg 1, ll 7-33 & pg 2, ll 1-4]
Background to the Invention
The use of unmanned vehicles is growing rapidly and the range of fields within which such vehicles are being applied is ever increasing, especially in the case of unmanned aerial vehicles (or drones). Unmanned vehicles are vehicles which do not have an on-board driver and, in some cases, do not have any human being present within the vehicle. Unmanned vehicles can be programmed to carry out various operations autonomously without needing any human intervention. However, for some operations, it is necessary (or at least desirable) for the autonomous vehicle to interact with a remote operator (HUMAN). For example, where a mission's parameters have changed, the autonomous vehicle may need to consult with a remote operator (HUMAN) for input as to its next action. Similarly, it may be necessary to keep a remote operator (HUMAN) informed of the vehicle's current operations to allow them to be monitored (BY A HUMAN) for any potential issues that could result. It may also be desirable or necessary to allow a remote operator (HUMAN) to take control of the vehicle should the need arise. This may be required, for example, in order to guarantee the safety of anyone (HUMAN) in the vicinity of the vehicle. Accordingly, a reliable communications link for allowing a controller (HUMAN) to communicate with an unmanned vehicle is a common requirement for unmanned vehicles.
Increasingly, the use cases for unmanned vehicles are involving so-called Beyond Visual Line of Sight (BVLOS) operation, wherein the distance between an operator (HUMAN) and the vehicle is large (such that the vehicle is not in the operator's (HUMAN) sight). Commonly such use cases involve the unmanned vehicle travelling across a reasonably large geographic area. As a result, the vehicle is likely to also be beyond range of direct communication with an operator (HUMAN) (who may also be referred to as a ground station (HUMAN). It is therefore common to make use of communications networks, such as radio access networks (e.g. 3G, 4G, 5G networks), to allow the operator (HUMAN) to communicate with the vehicle in such scenarios. Various overlay network services may be used to facilitate communication between an operator (HUMAN) and an unmanned vehicle (or between the unmanned vehicle and an application service that provides service that support the operation of the unmanned vehicle). For example, it is common to make use of a virtual private network (VPN) service that is hosted in a centralised cloud computing infrastructure to secure the communications with the unmanned vehicle using encryption and thereby prevent unwanted eavesdropping or tampering (BY A HUMAN) of the vehicle's control commands or telemetry.
...
[IFW pg. 6, ll 11-19]
In the following description, examples will be described in which the mobile entity is an unmanned aerial vehicle (UAV). However, it will be appreciated that the invention can also be applied to the deployment of network services for other types of unmanned vehicles, such as an unmanned ground vehicle (UGV), or indeed, to any other types of mobile entities (HUMAN) that may move within the geographical area 230 covered by the radio access network. Indeed, where the ground control station (HUMAN) for an unmanned vehicle is also mobile (i.e. where the ground control station may be considered to be a mobile entity (HUMAN)), the same techniques may also be used to provide services to the ground control station (HUMAN) as well as the unmanned vehicle (e.g. to facilitate communication between the two (UNMANNED VEHICLE AND HUMAN)).
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).
Accordingly, it would be beneficial to mitigate these disadvantages.
In other words, per applicant’s original IFW specification “remote operator” “controller” “ground station” “mobile entity” are interchangeably used to describe humans operating and/or controlling and/or monitoring unmanned vehicles as a common requirement over reliable communication (i.e. “reduced latency” “resource optimization” “adaptability”) between the unmanned vehicle and human(s) is not a technological improvement – instead, it is a common requirement to ensure human operators, controllers and monitors can ensure, among other things, the safety of humans in the vicinity of the unmanned vehicles, particularly unmanned aerial vehicles (see IFW citations above). Therefore the 101 rejection is maintained.
2] applicant argues (Remarks 1/9/26 summary pg 13-16)(emphasis added)
...
John A. Squires, the Under Secretary of Commerce for Intellectual Property and Director of USTPO issued a Memorandum entitled "Subject Matter Eligibility Declarations" on December 4, 2025, stating, inter alia, the following:
On November 4, 2025, I designated the Desjardins decision as precedential to 1) ensure the case reasoning binds all examination and appeals activity, and 2) underscore that improvements in computational performance, learning, storage, data sets and structures, for example, can constitute patent-eligible technological advancements under the Alice framework.
Additionally, Desjardin's reaffirmed that 35 U.S.C. §§ 102, 103, and 112- rather than § 101 - are the proper inquiries for defining the scope of patent protection. To be sure, § 101 remains a subject matter gatekeeper but must be applied properly, as set forth in Desjardins." (Emphasis added).
...
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 redundancy and reliability: when the communications plan indicates multiple edge compute nodes for parts of the route (as described in paragraph [0053] of the original specification of the present application), it provides backup options if the primary connection point is uncontactable, or communications are poor.
Dependent claim 6 further recites "wherein deploying 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 paragraph [0065] of the original specification of the present application, 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 (pages 3-4) 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 defining "Unmanned vehicles are vehicles which do not have an on-board driver. .. ").
The examiner respectfully disagrees.
Specifically, see response to argument 1] above.
Furthermore, it is respectfully requested that in future responses, that applicant either cite the instant specification from the IFW specification (which does not use paragraphs and instead uses pages and line numbers) or the PGPub (which uses paragraphs and does not use pages and line numbers) and not intermix the two without clarifying text of which is being cited (IFW specification vs PGPub) to reduce confusion.
Furthermore, in response to argument with respect to dependent claims 5 -6 claimed “mobile entity” and citation of what appears to be PGPub [0053; 65] related to claimed “mobile entity”, the examiner points to this examiner’s response to argument 1] above where “mobile entity” is one of many terms interchangeably used to disclose “a human” in communication with the unmanned vehicle(s) as is a common requirement.
Furthermore, in response to argument with respect to dependent claim 10 and citation of IFW specification, pg 1, ll 10-11, the examiner cited the section title and full paragraph above and again gives below that same paragraph which discloses, among other information, that reliable communication is a common requirement between the unmanned vehicle and human operator, human controller and/or human monitor (see IFW pg 1, ll 7-19 and given below)(emphasis added and comments “HUMAN” added by the examiner below):
[IFW: pg 1, ll 7-19]
Background to the Invention
The use of unmanned vehicles is growing rapidly and the range of fields within which such vehicles are being applied is ever increasing, especially in the case of unmanned aerial vehicles (or drones). Unmanned vehicles are vehicles which do not have an on-board driver and, in some cases, do not have any human being present within the vehicle. Unmanned vehicles can be programmed to carry out various operations autonomously without needing any human intervention. However, for some operations, it is necessary (or at least desirable) for the autonomous vehicle to interact with a remote operator (HUMAN). For example, where a mission's parameters have changed, the autonomous vehicle may need to consult with a remote operator (HUMAN) for input as to its next action. Similarly, it may be necessary to keep a remote operator (HUMAN) informed of the vehicle's current operations to allow them to be monitored (BY A HUMAN) for any potential issues that could result. It may also be desirable or necessary to allow a remote operator (HUMAN) to take control of the vehicle should the need arise. This may be required, for example, in order to guarantee the safety of anyone (HUMAN) in the vicinity of the vehicle. Accordingly, a reliable communications link for allowing a controller (HUMAN) to communicate with an unmanned vehicle is a common requirement for unmanned vehicles.
Therefore the 101 rejection is maintained.
3] applicant argues (Remarks 1/9/26 summary pg 17-18)(emphasis added)
B. Independent claim 1 is directed to patent eligible subject matter under Step 2B of the Alice/Mayo test:
MPEP 2106.05 ("Eligibility Step 2B: Whether a Claim Amounts to Significantly More") states, inter alia, the following:
"In determining patent eligibility, examiners should consider whether the claim "purport(s) to improve the functioning of the computer itself' or "any other technology or technical field." Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225, 110 USPQ2d 1976, 1984 (2014). This consideration has also been referred to as the search for a technological solution to a technological problem. See e.g., DDR Holdings, LLC. v. Hotels.com, L.P., 773 F.3d 1245, 1257, 113 USPQ2d 1097, 1105 (Fed. Cir. 2014); Amdocs (Israel), Ltd. v. Openet Telecom, Inc., 841 F.3d 1288, 1300-01, 120 USPQ2d 1527, 1537 (Fed. Cir. 2016)." (MPEP 2106.05(a); Emphasis added).
Claim 1 is also patent-eligible because it is directed to significantly more than a patent-ineligible
concept - per step 2B of the Alice/Mayo test. That is, claim 1 recites an element, or combination of elements, that is enough to ensure that the claim is directed to significantly more than an abstract idea.
The invention of claim 1, including the above quoted claim features, provides a technological solution to a technological problem and thus is directed to significantly more than an abstract idea.
For example, the specification discusses at least the following technological problems:
"As mobile entities, 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 moves further from the location at which the cloud computing infrastructure is hosted. Some applications, particularly those associated with controlling 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 may be required to be maintained below a particular threshold to ensure responsiveness and safety." (Pg. 2, lines 6-14 of the specification; Emphasis added).
As discussed above, example embodiments of the present invention resolve the above noted technological problems by providing technological solutions (e.g., reduced latency).
...
The examiner respectfully disagrees.
Specifically, see response to arguments 1] and 2] above. Therefore the 101 rejection is maintained.
4] applicant argues (Remarks 1/9/26 summary pg 18-22)(emphasis added)
...
The three-way combination of Sabella, Lassoued and GB fails to teach or suggest the following limitations of independent claim 1 and its dependents (including new dependent claim 26):
[A] "selecting 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;
[B] 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 while undertaking the intended journey; and
[C] providing 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."
The Office Action (pg. 5) admits that the base reference Sabellla fails to disclose claim feature [A]. That is, the Office Action (pg. 5) admits that "Sabella did not explicitly disclose selecting 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."
This admitted deficiency is not resolved by Lassoued as alleged by the Office Action. The Office Action (pgs. 5-6) specifically cites para. [0016] of Lassoued, which states the following in its entirety:
"In the MEC or FEC, a set of server nodes may be responsible for a "small" geographic area each, allowing local processing of UE data with low latency. A challenge arises when the UE, which is connected to a cloud computing environment/network, is mobile. As the UE is moving, the associated VM, which is processing the UE data in the cloud or the state associated with the UE, needs to be dynamically handed over from one server to another. The objective is to allow the moving UE to be connected to an appropriate node in its geographic proximity, guaranteeing the latency level required by the application. Low latency is particularly relevant for traffic safety applications in the context of connected vehicles."
This portion of Lassoued merely discloses that an associated VM is dynamically handed over from one server to another as the UE is moving so that the UE is connected to an appropriate node in its geographic proximity. This portion (and all other portions) of Lassoued fail to disclose selecting 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 (wherein that route is for the intended journey by the mobile entity through the geographical area).
The examiner respectfully disagrees.
Specifically, as is well-known by persons of ordinary skill in the art, and as disclosed by Sabella and Lassoued, edge computing is all about selecting edge nodes based on geographic proximity (i.e. closer) for at least reducing latency (see at least Sabella [0046] and Lassoued [0014] given below: (emphasis added)
Sabella [0046]
Further, edge computing refers to the implementation, coordination, and use of computing and resources at locations closer to the "edge" or collection of "edges" of the network, where the edge refers to the parts of the network close to the users. The purpose of this arrangement is to improve total cost of ownership, reduce application and network latency, reduce network backhaul traffic and associated energy consumption, improve service capabilities, and improve compliance with security or data privacy requirements ( especially as compared to conventional cloud computing). Components that can perform edge computing operations ("edge nodes") can reside in whatever location needed by the system architecture or ad hoc service ( e.g., in a high-performance computing data center or cloud installation; a designated edge node server, an enterprise server, a roadside server, a telecom central office; or a local or peer at-the-edge device being served consuming edge services).
Lassoued [0014]
Moreover, cloud-based mobile applications have become increasingly popular and one key issue therein is to ensure that services are always delivered with good performance. Current centralized structure of the cloud has led to a generally large geographical separation between the users and the cloud infrastructure. In such a setting, end-to-end communication between user and cloud can involve many network hops resulting in high latency; the ingress bandwidth to the cloud may also suffer from saturation as the cloud infrastructure is accessed on a many-to-one basis. A promising approach for resolving the above problems is to install computing infrastructures at the network edge. Particularly for real-time applications such as instantaneous object recognition and safety assistance in intelligent transportation systems (ITS), service applications have to remain in relatively close proximity to their end users in order to ensure low latency and high bandwidth connectivity. This is captured by the newly emerged concept of mobile edge clouds ("MECs"), as well as similar concepts such as cloudlet, fog computing, follow-me cloud ("FMC"), mobile micro-cloud and small cell cloud. It should be noted that the FMC is a concept according to which services are migrating in unison with the user's movements. An MEC is to move computation closer to users, where small servers or data centers that can host cloud applications are distributed across the network and connected directly to entities (such as cellular base stations) at the network edge. A "server node" ( or simply "server") may be defined as a cloud server providing compute and/or storage power for hosting VMs in a follow-me or mobile-edge cloud.
That is, both Sabella and Lassoued disclose that edge refers to use of computing and resources at locations closer to the user (i.e. 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) (see Sabella and Lassoued above) and Lassoued further discloses mobile edge clouds (MEC) moves computation closer to users and follow-me-cloud (FMC) is a concept of services are migrating in unison with a user’s movements (i.e. 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 while undertaking the intended journey && the communications plan indicating how the at least one instance of the service can be accessed during the intended journey) (see Lassoued above).
That is, Sabella and Lassoued discloses selecting at least one edge compute node in the network for providing the service to the mobile entity during the intended journey (Lassoued: fig 1-7, [0005-84]: ... a promising approach for resolving the above problems is to install computing infrastructures at the network edge ... service applications have to remain in relatively close proximity to their end users (selecting at least one edge compute node in the network for providing the service to the mobile entity ...) in order to ensure low latency and high bandwidth connectivity and this is captured by the newly emerged concept of mobile edge clouds ("MECs"), as well as similar concepts such as cloudlet, fog computing, follow-me cloud ("FMC"), mobile
micro-cloud and small cell cloud ... mobile edge clouds (MEC) moves computation closer to users and follow-me-cloud (FMC) is a concept of services are migrating in unison with a user’s movements (selecting at least one edge compute node in the network for providing the service to the mobile entity during the intended journey) [0014] ... in the MEC or FEC (follow-me-cloud) (... providing the service to the mobile entity during the intended journey) a set of servers are responsible for a “small” geographic area each, allowing local processing of UE data with low latency (... at least one edge compute node in the network for providing the service to the mobile entity during the intended journey) ... as the UE is moving (the mobile entity during the intended journey), the associated VM processing the UE data in cloud needs to be dynamically handed over from one server or another (selecting at least one edge compute node in the network for providing the service to the mobile entity during the intended journey) [0016]),
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 (Lassoued: fig 1-7, [0005-84]: ... a promising approach for resolving the above problems is to install computing infrastructures at the network edge ... service applications have to remain in relatively close proximity to their end users (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 ...) ... mobile edge clouds (MEC) moves computation closer to users and follow-me-cloud (FMC) is a concept of services are migrating in unison with a user’s movements (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) [0014] ... the objective is to allow the moving UE to be connected to an appropriate node in its geographic proximity guaranteeing latency level required by application(s) (see with [0014] above -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) [0016]).
Sabella and Lassoued further disclose 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 while undertaking the intended journey (Lassoued: fig 1-7, [0005-84]: ... a promising approach for resolving the above problems is to install computing infrastructures at the network edge ... service applications have to remain in relatively close proximity to their end users (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 ...) ... mobile edge clouds (MEC) moves computation closer to users and follow-me-cloud (FMC) is a concept of services are migrating in unison with a user’s movements (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) [0014] ... the objective is to allow the moving UE to be connected to an appropriate node in its geographic proximity guaranteeing latency level required by application(s) (see with [0014] above -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) [0016] ... an optimized plan may be generated for migrating each vehicle’s computational unit migration e.g. VM migration (see with [0014;16] above - deploying a respective instance of the service to each of the at least one edge compute nodes ...) according to criteria ... minimization of migration cost for each vehicle while assuring sufficiently low latency throughout the journey (see with [0014;16] above ... so that it is accessible by the mobile entity while undertaking the intended journey) [0019] ... this invention provides for planning the migration of virtual machines associated with moving vehicles in a follow-me (mobile-edge) cloud (see with [0014;16] above - 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 while undertaking the intended journey) [0018];
Sabella: fig 1-18, [0002-199]: ... MEC apps 412 instantiated on MEC hosts 402 403 can be used to provide V2X-related services (deploying a respective instance of the service to each of the at least one edge compute nodes ...) ... other remote application server instances can be located elsewhere such as in remote cloud 410 (see with [0030;34] - ... so that it is accessible by the mobile entity while undertaking the intended journey) [0053]).
Sabella did not explicitly disclose providing 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.
GB discloses providing 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 (GB: fig 1-22, [0006-162]: fig 11 ... implementing speculative QoS-based allocation of edge computing resources ... which operate a subject service and functionality that forecasts and communicates service needs and targets [0078] ... flowchart identifies resource requirements used for applicable service ... includes configuration information used to setup particular resource settings or environments on an edge computing node ... identifies potential mobility location paths and computing nodes and resources available within such location paths ... identification identifies possible resource configurations and types of setups needed in order to pre-allocate applicable resources (... the communications plan indicating how the at least one instance of the service can be accessed during the intended journey) [0079] ... forecasts of future resource needs for usage of service ... to forecast probability and estimated timing for usage of service at respective targets ... forecasts produced for deployment of multiple targets along multiple paths ... predicted service pre-allocation information is communicated among target nodes in multiple paths to enable speculative pre-allocation of the resources at the respective nodes ... concludes with operations to perform migration of resources and nodes along the actual used or selected path of mobility and migration (providing a communications plan to the mobile entity ...) [0080-81]).
Sabella, Lassoued and GB are analogous art because they are from the same field of endeavor with respect to edge computing resources.
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 GB into the method by Sabella and Lassoued. The suggestion/motivation would have been to provide migration of resources and nodes along an actual used or selected path of mobility and migration (GB: [0081]).
Therefore, the rejection is maintained.
Specification
The substitute specification filed 1/9/26 has not been entered because it does not conform to 37 CFR 1.125(b) and (c) because: the statement as to a lack of new matter under 37 CFR 1.125(b) is missing and, although a marked-up copy of the substitute specification has not been supplied, a clean copy of the substitute specification has not been supplied (in addition to the marked-up copy).
Claim Objections
Claim 27 is objected to because of the following informalities: New claim 27 ends with a typo (colon) that should be removed:
27. (New) The method of claim 13, 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.[[:]]
Appropriate correction is required.
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 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]).
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 “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). 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-9, 13-16, 19-20, 24-27 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Publication No. 2021/0112441 to Sabella et al. (“Sabella”) in view of U.S. Patent Publication No. 2020/0249039 to Lassoued et al. (“Lassoued”) and further in view of U.S. Patent Publication No. 2019/0158606 to Guim Bernat et al. (“GB”).
As to claim 1, Sabella 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 (Sabella: fig 1-18, [0002-36]: MEC (multi-access edge computing) 206 and V2X (vehicle-to-everything) application 210 provide functionality ... MEC allows applications to be instantiated at the edge of an access network and provides low-latency and close-proximity environment to user equipment (UE) ... deployment of MEC infrastructure together with deployment of radio access networks (RANs) (... deploying a service to edge compute nodes located at the edge of a radio access network) [0034] ... MaaS (mobility as a service) operators ... have useful data regarding people mobility patterns for various geographic areas and times of day (... dispersed throughout a geographical area) [0030]), the method comprising:
receiving 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 (Sabella: fig 1-18, [0002-199]: fig 7 ... the coverage map is used not only for travel planning (receiving a travel plan for a mobile entity ...) but also for trajectory and route sharing ratings to optimize the overall, both communication and vehicular, traffic efficiency and road safety (... the travel plan indicating a route for an intended journey by the mobile entity through the geographical area) [0081]).
Sabella did not explicitly disclose selecting 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.
Lassoued discloses selecting at least one edge compute node in the network for providing the service to the mobile entity during the intended journey (Lassoued: fig 1-7, [0005-84]: ... a promising approach for resolving the above problems is to install computing infrastructures at the network edge ... service applications have to remain in relatively close proximity to their end users (selecting at least one edge compute node in the network for providing the service to the mobile entity ...) in order to ensure low latency and high bandwidth connectivity and this is captured by the newly emerged concept of mobile edge clouds ("MECs"), as well as similar concepts such as cloudlet, fog computing, follow-me cloud ("FMC"), mobile micro-cloud and small cell cloud ... mobile edge clouds (MEC) moves computation closer to users and follow-me-cloud (FMC) is a concept of services are migrating in unison with a user’s movements (selecting at least one edge compute node in the network for providing the service to the mobile entity during the intended journey) [0014] ... in the MEC or FEC (follow-me-cloud) (... providing the service to the mobile entity during the intended journey) a set of servers are responsible for a “small” geographic area each, allowing local processing of UE data with low latency (... at least one edge compute node in the network for providing the service to the mobile entity during the intended journey) ... as the UE is moving (the mobile entity during the intended journey), the associated VM processing the UE data in cloud needs to be dynamically handed over from one server or another (selecting at least one edge compute node in the network for providing the service to the mobile entity during the intended journey) [0016]),
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 (Lassoued: fig 1-7, [0005-84]: ... a promising approach for resolving the above problems is to install computing infrastructures at the network edge ... service applications have to remain in relatively close proximity to their end users (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 ...) ... mobile edge clouds (MEC) moves computation closer to users and follow-me-cloud (FMC) is a concept of services are migrating in unison with a user’s movements (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) [0014] ... the objective is to allow the moving UE to be connected to an appropriate node in its geographic proximity guaranteeing latency level required by application(s) (see with [0014] above -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) [0016]).
Sabella and Lassoued are analogous art because they are from the same field of endeavor with respect to new edge-of-network application aware proxy server or EdgeApp.
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 Lassoued into the method by Sabella. The suggestion/motivation would have been to provide for use of new EdgeApp server that may need to be migrated from an old EdgeApp to a new EdgeApp at a destination node (Lassoued: [0015]).
Sabella and Lassoued further disclose 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 while undertaking the intended journey (Lassoued: fig 1-7, [0005-84]: ... a promising approach for resolving the above problems is to install computing infrastructures at the network edge ... service applications have to remain in relatively close proximity to their end users (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 ...) ... mobile edge clouds (MEC) moves computation closer to users and follow-me-cloud (FMC) is a concept of services are migrating in unison with a user’s movements (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) [0014] ... the objective is to allow the moving UE to be connected to an appropriate node in its geographic proximity guaranteeing latency level required by application(s) (see with [0014] above -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) [0016] ... an optimized plan may be generated for migrating each vehicle’s computational unit migration e.g. VM migration (see with [0014;16] above - deploying a respective instance of the service to each of the at least one edge compute nodes ...) according to criteria ... minimization of migration cost for each vehicle while assuring sufficiently low latency throughout the journey (see with [0014;16] above ... so that it is accessible by the mobile entity while undertaking the intended journey) [0019] ... this invention provides for planning the migration of virtual machines associated with moving vehicles in a follow-me (mobile-edge) cloud (see with [0014;16] above - 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 while undertaking the intended journey) [0018];
Sabella: fig 1-18, [0002-199]: ... MEC apps 412 instantiated on MEC hosts 402 403 can be used to provide V2X-related services (deploying a respective instance of the service to each of the at least one edge compute nodes ...) ... other remote application server instances can be located elsewhere such as in remote cloud 410 (see with [0030;34] - ... so that it is accessible by the mobile entity while undertaking the intended journey) [0053]).
Sabella did not explicitly disclose providing 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.
GB discloses providing 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 (GB: fig 1-22, [0006-162]: fig 11 ... implementing speculative QoS-based allocation of edge computing resources ... which operate a subject service and functionality that forecasts and communicates service needs and targets [0078] ... flowchart identifies resource requirements used for applicable service ... includes configuration information used to setup particular resource settings or environments on an edge computing node ... identifies potential mobility location paths and computing nodes and resources available within such location paths ... identification identifies possible resource configurations and types of setups needed in order to pre-allocate applicable resources (... the communications plan indicating how the at least one instance of the service can be accessed during the intended journey) [0079] ... forecasts of future resource needs for usage of service ... to forecast probability and estimated timing for usage of service at respective targets ... forecasts produced for deployment of multiple targets along multiple paths ... predicted service pre-allocation information is communicated among target nodes in multiple paths to enable speculative pre-allocation of the resources at the respective nodes ... concludes with operations to perform migration of resources and nodes along the actual used or selected path of mobility and migration (providing a communications plan to the mobile entity ...) [0080-81]).
Sabella, Lassoued and GB are analogous art because they are from the same field of endeavor with respect to edge computing resources.
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 GB into the method by Sabella and Lassoued. The suggestion/motivation would have been to provide migration of resources and nodes along an actual used or selected path of mobility and migration (GB: [0081]).
As to claim 2, see similar rejection to claim 1 where the method is taught by the method.
As to claim 2, Sabella, Lassoued and GB 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 (Lassoued: fig 1-7, [0005-84]: fig 5 ... to maintain the benefits of running services close to vehicle 502 as vehicle 502 moves away from its original location, its services may need to be migrated to a new MEC server (... being selected based, at least in part on a geographical proximity of the edge compute node to the respective portion of the route), for example, one of the MEC servers 510AE-G (wherein a plurality of edge compute nodes are selected ...) along one or more routes (associated with a respective portion) in map 500 that is near current vehicle location 502 (... at least in part on a geographical proximity of the edge compute node to the respective portion of the route) [0073]).
For motivation, see rejection of claim 1.
As to claim 3, see similar rejection to claims 1-2.
As to claim 3, Sabella, Lassoued and GB further disclose wherein deploying the respective instance of the service to each of the edge compute nodes comprises scheduling 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 (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 (deploying the respective instance of the service) in MEC cloud computing environment (... to each of the edge compute nodes) ... provides for planning the migration (scheduling deployment) of virtual machines associated with moving vehicles in a follow-me mobile-edge cloud (of each respective instance) ... makes use of the predictability of vehicle destinations and routes to plan in real-time, but in advance (for a time prior to a time), the migration of their computational unit e.g. VM migration, state migration in an optimal way and one or more destinations and most likely routes (... comprises scheduling 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) ... an optimized plan may be generated for migrating each vehicles’ computational unit e.g. VM migration, state migration according to criteria minimization of migration cost for each vehicle while assuring sufficiently low latency throughout the journey ... a computational unit handover operation may be dynamically planned associated with a vehicle using one or more predicted routes (... comprises scheduling 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) [0018-20]).
For motivation, see rejection of claim 1.
As to claim 4, see similar rejection to claims 1-3.
As to claim 4, Sabella, Lassoued and GB further disclose removing 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 (GB: fig 1-22, [0006-162]: ... communicating service pre-allocation information among the potential mobility location paths ... service pre-allocation is used for speculative allocation of resources along respective nodes in the potential mobility location paths (respective portion(s) of the rout(s)e over which instance(s) is/are to provide the service to the mobile entity) ... after migration ( ...after the mobile entity has completed the respective portion of the route ...), to perform a cleanup of resources along one or more unselected paths, including operations to communicate service de-allocation information to a third edge computing apparatus (removing the respective instance of the service deployed to an edge compute node ...) [0099]).
For motivation, see rejection of claim 1.
As to claim 5, see similar rejection to claims 1-4.
As to claim 5, Sabella, Lassoued and GB further disclose wherein at least one instance of the service is deployed after the mobile entity has begun the intended journey (Lassoued: fig 1-7, [0005-84]: in the MEC or FEC a set of servers are responsible for a “small” geographic area each, allowing local processing of UE data with low latency (... wherein at least one instance of the service is deployed ...) ... as the UE is moving (after the mobile entity has begun), the associated VM processing the UE data in cloud needs to be dynamically handed over from one server or another (see with [0018] - at least one instance of the service is deployed after the mobile entity has begun the intended journey) [0016] .... the present invention provides for planning the migration of virtual machines associated with moving vehicles (after the mobile entity has begun) in a follow-me mobile-edge cloud (see with [0016] - at least one instance of the service is deployed after the mobile entity has begun the intended journey) [0018]).
For motivation, see rejection of claim 1.
As to claim 6, Sabella, Lassoued and GB disclose wherein deploying 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 (GB: fig 1-22, [0006-162]: proactive reservation of edge computing resources ... edge computing QoS optimization techniques may be applied to achieve a proactive reservation (... comprises scheduling deployment of each respective instance for a time prior to a scheduled start of the intended journey by the mobile entity) of edge computing resources based on a mobility path ... the geographic path of a car known based on an expectation of a route plan e.g. a map service route planner (wherein deploying the respective instance of the service to each of the at least one edge compute nodes ...).
For motivation, see rejection of claim 1.
As to claim 7, see similar rejection to claims 1-6.
As to claim 7, Sabella, Lassoued and GB 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 (Sabella: fig 1-18, [0002-199]: ... edge computing refers to the implementation, coordination, and use of computing and resources at locations closer to the "edge" or collection of "edges" of the network, where the edge refers to the parts of the network close to the users. The purpose of this arrangement is to improve total cost of ownership, reduce application and network latency, reduce network backhaul traffic and associated energy consumption, improve service capabilities, and improve compliance with security or data privacy requirements ( especially as compared to conventional cloud computing) and components that can perform edge computing operations ("edge nodes") can reside in whatever location needed by the system architecture or ad hoc service (... communications between a radio access node associated with the edge compute node and one or more mobile stations in proximity to the route) [0046] ... providing users with a seamless mobility experience with reduced operational cost involves collection, aggregation, and sharing of data from various entities and, for example, historical data about user preferences and trips can be collected from the MaaS User Application during trip initiation, selection, journey, and trip completion (see with [0046] above - 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) and TSPs have data about user demands, congestion on the road, environment, charging conditions, etc., through the sensors of their vehicles and MaaS operators also may have agreements with network service providers, which have useful data regarding people mobility patterns for various geographic areas and times of day (see with [0046] above - 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) [0030] ... one system includes means for receiving, by a multi-access edge computing (MEC) application, parameters of a global quality of service (QoS) prediction model, and means for sending, to a local prediction function (PF), an update of a local QoS prediction mode and further, the system includes means for detecting a journey of a vehicle requested by a user, and means for sending to the local PF, a request for a value of the QoS along the journey and the value of the QoS is a measure of quality of transportation services delivered during the journey (see with [0046;30] above - 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) ... system further includes means for receiving the predicted value of the QoS along the journey, and means for providing, by the MEC application, the predicted value of the QoS to the vehicle ... system further includes means for receiving the predicted value of the QoS along the journey, and means for providing, by the MEC application, the predicted value of the QoS to the vehicle (see with [0046;30] above - 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) [0026] ... MEC app 610, executes and is collocated with respective RANs ... RAN PF 606 associated with RAN 502 responsible for predicting radio signal quality at specific vehicular UE locations (mobile stations) and times of interest (see with [0046;30] above - 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) ... cloud PF 608 predicts edge resource availability at specific edge deployment locations and times of interest [0070-71] ... MEC is technology that allows applications to be instantiated at the edge of access networks and provide low-latency (a latency measurement) and a close-proximity environment to user equipment (UEs) (mobile stations) ... automotive industries are expected to significantly benefit from deployment of MEC infrastructure together with deployment of RANs (see with [0046;30] above - 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) [0034]).
As to claim 8, see similar rejection to claims 1-7.
As to claim 8, Sabella, Lassoued and GB further 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: 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]).
For motivation, see rejection of claim 1.
As to claim 9, see similar rejection to claims 1-8.
As to claim 9, Sabella, Lassoued and GB 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 1.
As to claims 13-16, 19-20, see similar rejection to claims 1-2, 8-9,7,9, 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.
As to claim 26, see similar rejection to claims 1-9.
As to claim 26, Sabella, Lassoued and GB further 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 (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];
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 1.
As to claim 27, see similar rejection to claim 26 where the medium is taught by the method.
Claims 10-12, 17-18 and 21-23 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Publication No. 2021/0112441 to Sabella et al. (“Sabella”) in view of U.S. Patent Publication No. 2020/0249039 to Lassoued et al. (“Lassoued”), U.S. Patent Publication No. 2019/0158606 to Guim Bernat et al. (“GB”) and further in view of U.S. Patent No. 11405801 to Qureshi et al. (“Qureshi”).
As to claim 10, Sabella, Lassoued and GB disclose the medium of claim 10.
For motivation, see rejection of claim 1.
Sabella did not explicitly disclose wherein the mobile entity is an unmanned vehicle (emphasis added).
Specifically, Sabella discloses vehicle 104 may be any type of vehicle ... able to operate partially autonomous ... fully autonomous (such as an unmanned vehicle)... or semi-autonomous mode (Sabella: [0032)].
Nonetheless, Sabella did not explicitly disclose wherein the mobile entity is an unmanned vehicle (emphasis added).
For clarity, Qureshi discloses wherein the mobile entity is an unmanned vehicle (emphasis added) (Qureshi: fig 1-8, col 1-col 2: ... unmanned vehicles (UVs) such as unmanned aerial vehicles e.g. a drone and unmanned terrestrial vehicles e.g. driverless vehicles (col 1 ll 65-67 & col 2 ll 1-19)).
Sabella, Lassoued, GB 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 Sabella, Lassoued and GB. 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 11 Sabella, Lassoued, GB and Qureshi disclose 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) ).
For motivation, see rejection of claim 10.
As to claim 12 Sabella, Lassoued, GB and Qureshi disclose further comprising 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 10.
As to claim 17 Sabella, Lassoued, GB 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 Sabella, Lassoued, GB 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 21-23, see similar rejection to claims 10-12, respectively, where the method is taught by the method.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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