Detailed Action
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 3/5/2026 has been entered.
Claims 1-2 and 4-15 are pending and ready for examination.
The examiner has reviewed the Applicant’s arguments submitted on 3/5/2026 in their entirety. Applicant’s arguments are moot based on new prior art rejection(s) comprising Butler (US 2022/0197773). Butler provides for MECs participating in decentralized and distributed orchestration based on context rules as detail below. Moreover the Examiner respectfully reminds the Applicant Elgazzar used in previous prior art rejections also provides one of ordinary skill in the art to contemplate the Applicant’s newly amended claims.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2 ,7, 9-10, and 15 are being rejected under 35 USC 103 as being patentable over Sabella (US 2018/0183855) in view of Butler (US 2022/0197773)
Regarding claim 1, Sabella discloses an automated method for providing functionalities of a mobile unit, the method comprising:
receiving a task request from a requesting unit, the task request including a required function along with corresponding parameters and context rules (Sabella; Sabella teaches the MEC orchestrator receives a request from UE application residing on a UE device (i.e. requesting unit) and where the request includes information about (i)the application to be run (i.e. required function) and (ii)location and application rules and requirements (parameters and context rules)
see e.g.[0087] “In order to run an MEA 336 in the mobile edge system 400, the MEC-O 321 may receive requests triggered by the OSS 322, a third-party 310, or a UE application 305. In response to receipt of such requests, the MEC-O 321 may select an MEH 200 to host the MEA 336 for computational offloading. These requests may include information about the application to be run, and possibly other information, such as the location where the application needs to be active, other application rules and requirements, as well as the location of the application image if it is not yet on-boarded in the MEC system 400” )
loading the required function into the mobile unit (Sabella; Sabella teaches the MEC orchestrator loads or instantiates the requested function onto a mobile edge host (i.e. mobile unit)
The Examiner notes per dependent claim 2 below the mobile unit may be readily equivalent to a mobile edge host
see e.g.[0087] “In order to run an MEA 336 in the mobile edge system 400, the MEC-O 321 may receive requests triggered by the OSS 322, a third-party 310, or a UE application 305. In response to receipt of such requests, the MEC-O 321 may select an MEH 200 to host the MEA 336 for computational offloading. These requests may include information about the application to be run, and possibly other information, such as the location where the application needs to be active, other application rules and requirements, as well as the location of the application image if it is not yet on-boarded in the MEC system 400”
see e.g. [0074] “... instantiating on an MEH 200 ... “); and
carrying out the task by executing the required function on the Mobil unit when triggered by the context rules (Sabella; Sabella teaches execution of the function occurs on the selected MEH (i.e. mobile unit) ro which the task is offloaded. The orchestration decision is based on “application requirements”, which are the context rules supplied with the UE request. Thus, the task is executed on the mobile unit when the context rules are satisfied;
see e.g. [0088] “In various embodiments, the MEC-O 321 may select an MEH 200 for computational offloading of UE application 305 tasks based on MEH parameters, network capabilities and conditions, and application requirements... “);
and reporting a result of the function to the requesting unit (Sabella;
see e.g. [0146] “Table 2 shows input application parameters of a particular UE app 305. The application parameters of table 2 include task frequency (e.g., how often the task should be offloaded over time), computation load in terms of Giga Floating Point Operations Per Second (GFLOPS), data volume to be transferred as input for offloading the task (e.g., data to be sent by UE 101 for offloading), and data volume to be transferred as an output for offloading the task (e.g., data to be sent back to the UE 101 after offloading”). ;
wherein the function is carried out in the mobile unit only if one or more rules of the context rule system are satisfied (Sabella; Sabella teaches that execution on the MEH is conditional on application requirements. The MEH is selected only when those requirements are met if no selection is made , the function is not carried out.
See e.g. [0074] “The MEAs 336 may have a certain number of rules and requirements associated to them, such as required resources, maximum latency, required or useful services, etc. ...”
see e.g. [0088] “In various embodiments, the MEC-O 321 may select an MEH 200 for computational offloading of UE application 305 tasks based on MEH parameters, network capabilities and conditions, and application requirements... “)
Sabella does not expressly disclose:
the mobile unit storing a context rule system; and
in response to receipt of the task request from the requesting unit, the mobile unit triggering the task;
However in analogous art Butler discloses:
the mobile unit storing a context rule system( Butler teaches that context-based rules are stored and applied at MEC edge nodes participating in decentralized orchestration, because Butler teaches that individual systems or leaders monitor and control the systems, and that context changes, including a change of leader, task requirements, and system objectives, trigger an update of an actuation plan ([0225]), in the Butler MEC architecture of decentralized orchestration and edge host execution (see e.g. [0202], [0217], [0221], [0230], [0231], [0421)
Butler teaches that individual systems or leaders monitor and control the systems, and that context changes trigger updates to the actuation plan ([0225]), thereby demonstrating that context-based rules at those nodes control execution through actuation plans.
[0225] Individual systems or leaders-which could be selected upfront through bidding and negotiation schemes—can monitor and control the individual systems or SoS to assure QoS in the operation. Changes in the environment, as systems temporally become available, as well as spatial movement or context changes (e.g., change of leader, task requirements, and objectives of the system), can trigger an update of the actuation plan.);
in response to receipt of the task request from the requesting unit, the mobile unit triggering the task (Butler; Butler further teaches, in response to receipt of a task request, the system parsing task requirements and evaluating execution based on insights and capabilities, determining whether the system is part of an actuation plan, and executing the task only when selected as part of that plan (see e.g. Fig. 15, blocks 1502-1528)., thereby teaching that execution at the node is triggered and carried out based on context driven rules. Butler also teaches that context changes trigger updates to the actuation plan ([0225]). Butler further teaches that actuation plans assign sub-tasks or service execution to individual systems or groups of systems, such that particular systems are selected to perform execution (see e.g. [0221]), thereby reinforcing that the system itself triggers execution of the task when selected as part of the actuation plan., Accordingly, Butler teaches that the MEC host/edge node triggers and carries out execution of the task only when triggered by context-based conditions reflected in the actuation plan);
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Sabella to incorporate Butler’s context -based actuation control at the MEC edge host of Sabella, wherein Butler teaches that actuation plans at MEC edge nodes are updated based on context changes and that execution at the node is triggered and carried out based on those context-driven actuation plans. The motivation being to implement a known technique of context driven actuation control in a distributed MEC environment, resulting in improved system responsiveness, reduced latency, and more efficient execution of tasks at the point of execution, thereby improving performance of subscriber services and/or applications.
Regarding claim 2, Sabella in view of Butler discloses the method as claimed in claim 1, where the mobile unit comprises an edge node of an edge cloud and the request unit comprises a part of the edge cloud (Sabella, Per independent claim 1, the mobile unit is a mobile edge host and the request unit resides within the geographic region covered by the mobile unit (i.e. mobile edge system 400);
see e.g.[0087] “In order to run an MEA 336 in the mobile edge system 400, the MEC-O 321 may receive requests triggered by the OSS 322, a third-party 310, or a UE application 305. In response to receipt of such requests, the MEC-O 321 may select an MEH 200 to host the MEA 336 for computational offloading. These requests may include information about the application to be run, and possibly other information, such as the location where the application needs to be active, other application rules and requirements, as well as the location of the application image if it is not yet on-boarded in the MEC system 400”)
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Sabella to incorporate Butler’s context -based actuation control at the MEC edge host of Sabella, wherein Butler teaches that actuation plans at MEC edge nodes are updated based on context changes and that execution at the node is triggered and carried out based on those context-driven actuation plans. The motivation being to implement a known technique of context driven actuation control in a distributed MEC environment, resulting in improved system responsiveness, reduced latency, and more efficient execution of tasks at the point of execution, thereby improving performance of subscriber services and/or applications.
Regarding claim 7, Sabella discloses a system comprising:
a requesting unit to generate a task request, the task request including a required function along with corresponding parameters and context rules (Sabella; Sabella teaches the MEC orchestrator receives a request from UE application residing on a UE device (i.e. requesting unit) and where the request includes information about (i)the application to be run (i.e. required function) and (ii)location and application rules and requirements (parameters and context rules)
see e.g.[0087] “In order to run an MEA 336 in the mobile edge system 400, the MEC-O 321 may receive requests triggered by the OSS 322, a third-party 310, or a UE application 305. In response to receipt of such requests, the MEC-O 321 may select an MEH 200 to host the MEA 336 for computational offloading. These requests may include information about the application to be run, and possibly other information, such as the location where the application needs to be active, other application rules and requirements, as well as the location of the application image if it is not yet on-boarded in the MEC system 400”
A conventional unit associated with the processes above is inherently present);
a mobile unit configured to execute the required function based on the context rules system (Sabella; Sabella teaches the MEC orchestrator loads or instantiates the requested function onto a mobile edge host (i.e. mobile unit)
The Examiner notes per dependent claim 2 below the mobile unit may be readily equivalent to a mobile edge host
see e.g.[0087] “In order to run an MEA 336 in the mobile edge system 400, the MEC-O 321 may receive requests triggered by the OSS 322, a third-party 310, or a UE application 305. In response to receipt of such requests, the MEC-O 321 may select an MEH 200 to host the MEA 336 for computational offloading. These requests may include information about the application to be run, and possibly other information, such as the location where the application needs to be active, other application rules and requirements, as well as the location of the application image if it is not yet on-boarded in the MEC system 400”
see e.g. [0074] “... instantiating on an MEH 200 ... “); and
wherein a rule engine module associated with the mobile unit stores a context rule system (Sabella; Sabella teaches execution of the function occurs on the selected MEH (i.e. mobile unit) ro which the task is offloaded. The orchestration decision is based on “application requirements”, which are the context rules supplied with the UE request. Thus, the task is executed on the mobile unit when the context rules are satisfied;
see e.g. [0088] “In various embodiments, the MEC-O 321 may select an MEH 200 for computational offloading of UE application 305 tasks based on MEH parameters, network capabilities and conditions, and application requirements... “
As the rules are executed a conventional module is inherently present facilitating the conventional storage of the rules
As the mobile unit’s operations are impacted by the rules, the mobile unit is associated with the rule engine under the broadest reasonable interpretation);
wherein the function is executed only if the context rules satisfy one or more rules of the context rule system (Sabella; Sabella teaches that execution on the MEH is conditional on application requirements. The MEH is selected only when those requirements are met if no selection is made , the function is not carried out.
See e.g. [0074] “The MEAs 336 may have a certain number of rules and requirements associated to them, such as required resources, maximum latency, required or useful services, etc. ...”
see e.g. see e.g. [0088] “In various embodiments, the MEC-O 321 may select an MEH 200 for computational offloading of UE application 305 tasks based on MEH parameters, network capabilities and conditions, and application requirements... “).
Sabella does not expressly disclose:
a mobile unit storing context rule system in a rule engine module;
However in analogous art Butler discloses:
a mobile unit storing context rule system in a rule engine module ( Butler teaches that context-based rules are stored and applied at MEC edge nodes participating in decentralized orchestration, because Butler teaches that individual systems or leaders monitor and control the systems, and that context changes, including a change of leader, task requirements, and system objectives, trigger an update of an actuation plan ([0225]), in the Butler MEC architecture of decentralized orchestration and edge host execution (see e.g. [0202], [0217], [0221], [0230], [0231], [0421)
Butler teaches that individual systems or leaders monitor and control the systems, and that context changes trigger updates to the actuation plan ([0225]), thereby demonstrating that context-based rules at those nodes control execution through actuation plans.
Butler further teaches, in response to receipt of a task request, the system parsing task requirements and evaluating execution based on insights and capabilities, determining whether the system is part of an actuation plan, and executing the task only when selected as part of that plan (see e.g. Fig. 15, blocks 1502-1528)., thereby teaching that execution at the node is triggered and carried out based on context driven rules. Butler also teaches that context changes trigger updates to the actuation plan ([0225]). Butler further teaches that actuation plans assign sub-tasks or service execution to individual systems or groups of systems, such that particular systems are selected to perform execution (see e.g. [0221]), thereby reinforcing that the system itself triggers execution of the task when selected as part of the actuation plan., Accordingly, Butler teaches that the MEC host/edge node triggers and carries out execution of the task only when triggered by context-based conditions reflected in the actuation plan
wherein the function is executed only if the context rules satisfy one or more rules of the context rule system (Butler teaches that the function is executed only if the context rules satisfy one or ore rules of the context rules system, because Butler teaches that conext changes, including task requirements, system objectives, and changes of leader, trigger updates to the actuation plan ([0225]) , and that execution is performed only when the system is selected as part of that actuation plan (Fig. 14, steps 1526-1528), where each selection reflects satisfaction of the governing context-based rules ([0221]).
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Sabella to incorporate Butler’s context -based actuation control at the MEC edge host of Sabella, wherein Butler teaches that actuation plans at MEC edge nodes are updated based on context changes and that execution at the node is triggered and carried out based on those context-driven actuation plans. The motivation being to implement a known technique of context driven actuation control in a distributed MEC environment, resulting in improved system responsiveness, reduced latency, and more efficient execution of tasks at the point of execution, thereby improving performance of subscriber services and/or applications.
Regarding claim 9, Sabella in view of Butler discloses the system as claimed in claim 7, further comprising a context management module formed in the mobile unit and configured to determine the current context of the mobile unit (The combined solution per Butler as Butler teaches a context aware management at the edge node, where context changes (e.g. task requirements, system objectives, or environment) are detected and used to update system operation ([00225]). This updating of the actual plan based on current context reflects a module that determines and manages the edge nodes context. Accordingly, Butler discloses functionality corresponding to a context management module at the edge node)
Regarding claim 10, Sabella in view of Butler discloses the system as claimed in claim 7, a rule management module formed in the mobile unit configured to provide the context rule system (The combined solution per Butler as Butler teaches a context rules at the edge node, as context changes are evaluated and used to update the actuation plan ([0225]), thereby reflecting rules governing system behavior. Such functionality corresponds to a rule management module that provides context rules for execution control.)
Regarding claim 15, Sabella in view of Butler discloses the system as claimed in claim 7, wherein the system comprises an edge cloud and the mobile unit comprises an edge node (Sabella, Per independent claim 7, the mobile unit is a mobile edge host and the request unit resides within the geographic region covered by the mobile unit (i.e. mobile edge system 400);
see e.g.[0087] “In order to run an MEA 336 in the mobile edge system 400, the MEC-O 321 may receive requests triggered by the OSS 322, a third-party 310, or a UE application 305. In response to receipt of such requests, the MEC-O 321 may select an MEH 200 to host the MEA 336 for computational offloading. These requests may include information about the application to be run, and possibly other information, such as the location where the application needs to be active, other application rules and requirements, as well as the location of the application image if it is not yet on-boarded in the MEC system 400”)
Claim 4 is rejected under 35 USC 103 as being unpatentable over Sabella in view of Butler and in further view of Prakash (US 2019/0138934)
Regarding claim 4, Sabella in view of Butler discloses the method as claimed in claim 1, Sabella does not expressly disclose further comprising providing the context rule system and the function redundantly on at least two mobile units on the basis of a prediction model, wherein the prediction model is designed to achieve a predefined probability of performing the function using the provided redundancy
However in analogous art Prakash discloses:
wherein the prediction model is defined to achieve a predefined probability of performing the function using the provided redundancy (Prakash;
see e.g. [0107] “... a coding redundancy for performing load balancing or partitioning ... individual edge nodes 2101 provide operational parameters to the master node ... processing capabilities indication ...”
see e.g. [0112] “.... the load balancing engine 310 provides the coding redundancy c and the load partitions .. for each compute node ... for example, encoding circuitry of the master node 2112 to be encoded for each edge compute node 2101 at operation 330”
see e.g. [0143] “.... optimal load partitions and the minimal coding redundancy are provided to the encoder 533 of each edge compute nodes 2101 with a probability ...”
see e.g. [0100] “... a prediction based on the model ...”
see e.g. Methodology Fig. 3))
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Sabella with Prakash’s redundancy scheme. The motivation being the combined solution provides for increased efficiencies in provisioning redundancy of resources within the context of edge node deployments and/or infrastructure.
Sabella in view of Butler and in further view of Prakash disclose:
further comprising providing the context rule system and the function redundantly on at least two mobile units on the basis of a prediction model, wherein the prediction model is designed to achieve a predefined probability of performing the function using the provided redundancy (The combined solution provides per Sabella’s infrastructure may realize two mobile units on the basis of a prediction model, wherein the prediction model is designed to achieve a predefined probability of performing the function using the provided redundancy per Prakash’s implementation)
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Sabella to incorporate Butler’s context -based actuation control at the MEC edge host of Sabella, wherein Butler teaches that actuation plans at MEC edge nodes are updated based on context changes and that execution at the node is triggered and carried out based on those context-driven actuation plans. The motivation being to implement a known technique of context driven actuation control in a distributed MEC environment, resulting in improved system responsiveness, reduced latency, and more efficient execution of tasks at the point of execution, thereby improving performance of subscriber services and/or applications.
Claim 5 is rejected under 35 USC 103 as being unpatentable over Sabella in view of Butler and in further view of Casado (US 2014/0074339)
Regarding claim 5, Sabella in view of Butler discloses the method as claimed in claim 1, disclose wherein the mobile unit is configured to inform further mobile units which rules have triggered in the mobile unit and which function is carried out (The combined invention per Butler, a as Butler contemplates informing mobile edge nodes which context rules have triggered within a mobile edge node and which function was carried out, because Butler teaches that context change changes including task requirements, system objectives, and changes of leader, dynamically trigger updates to the actuation plan as conditions in the environment evolve ([0225]), and that such actuation plans are advertised to neighboring systems ([0230]) and define execution of tasks by participating systems (([0221], [0231]), thereby communicating to other nodes both the execution performed and the context driven conditions that resulted in that execution. Moreover this allow participating nodes to recognize , from the distributed updates to the actuation plan, what execution has changed and correspondingly, which context-driven conditions have triggered that change ).
As evidence of the rationale above Casado discloses:
functions caried out(Casado teaches informing other distributed nodes of which which functions have been executed, as it discloses that in a distributed system, transitions are “triggered when the current task ... changes its state” and “triggered when a request message is received” ([0095], and that following such triggered transitions, the execution of the associated tasks proceeds and results are communicated to other entities in the system ([0096]), including notifying other entities of the updated state.
Thus Casado teaches that when a rule or condition is triggered, the resulting task execution and its status are shared with other nodes, thereby informing the other nodes (i) which triggering conditions have occurred and (ii) which functions have been carried out.)
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Casado’s scheme. The motivation being the combined solution provides for implementing a known technique resulting in increased efficiencies of task management between edge nodes. Moreover Casado recognizes the deficiencies in i centralized reporting of tasks and/or triggers and emphasizes decentralization with respect to sharing actual task status between nodes (See e.g. [0005], [0006]).
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Sabella to incorporate Butler’s context -based actuation control at the MEC edge host of Sabella, wherein Butler teaches that actuation plans at MEC edge nodes are updated based on context changes and that execution at the node is triggered and carried out based on those context-driven actuation plans. The motivation being to implement a known technique of context driven actuation control in a distributed MEC environment, resulting in improved system responsiveness, reduced latency, and more efficient execution of tasks at the point of execution, thereby improving performance of subscriber services and/or applications.
Claim 6 is rejected under 35 USC 103 as being unpatentable over Sabella in view of Butler and in further view of Wang (WO201819665)
Regarding claim 6, Sabella in view of Butler discloses the method as claimed in claim 1, Sabella does not expressly disclose wherein the request unit is configured, to convey the importance and/or urgency of carrying out the function to the mobile unit
However in analogous art Wang discloses:
configured, to convey the importance and/or urgency of carrying out the function to the mobile unit (Wang;
see e.g. [0092] “... VNFD supports describing the priority of an application. Priority can indicate the possibility that services will be processed first when there are business conflicts ... urgent business priorities will be higher”
see e.g. [0094] “... indicates that the priority of the VNF’s business is low, that is, the third priority. At this time, the business in not urgent, such as non-real analysis business”
see e.g. [0027] “Determine the priority of the VNF’s services”)
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Wang’s priority scheme associated with VNFs. The motivation being the combined solution provides for increased efficiencies in provisioning applications and services.
Sabella in view of Butler and in further view of Wang discloses:
wherein the request unit is configured, to convey the importance and/or urgency of carrying out the function to the mobile unit (The combined solution provides for request processing associated with the urgency of carrying out a NFV as expressly taught by Wang)
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Sabella to incorporate Butler’s context -based actuation control at the MEC edge host of Sabella, wherein Butler teaches that actuation plans at MEC edge nodes are updated based on context changes and that execution at the node is triggered and carried out based on those context-driven actuation plans. The motivation being to implement a known technique of context driven actuation control in a distributed MEC environment, resulting in improved system responsiveness, reduced latency, and more efficient execution of tasks at the point of execution, thereby improving performance of subscriber services and/or applications.
Claims 8 and 11 are rejected under 35 USC 103 as being unpatentable over Sabella in view of Butler and in further view of Sood (US 2018/0114012)
Regarding claim 8, Sabella in view of Butler discloses the system as claimed in claim 7, Sabella does not expressly disclose further comprising:
A function runtime module formed in the mobile unit and configured to instantiate the function and carry it out in isolation from further functions
However in analogous art Sood discloses:
A function runtime module formed in the mobile unit and configured to instantiate the function and carry it out in isolation from further functions (Sood;
See e.g.[0114] “... executing environment employing multiple
VNFs running on respective VMs or containers such as NFV SGX Architecture 700 of Fig. 7 ...”
See e.g. [0115]
See e.g. [0128] “The multi-sage Service function Chaining (SFC) method isolates ... into separate VMs that may run services (applications or apps) ... VNF environment ...”
See e.g. Fig. 7 illustrating VNFs in containers providing isolation
See e.g. [0033] “.... application to instantiate a protected container, referred to as an enclave”).
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Sabella with Sood’s utilization of MEC infrastructure comprising NFVs in isolated environments. The motivation being the combined solution provides for migrating and benefiting from MEC deployments (i.e. edge services) and gaining increased efficiencies and security from NFV in containers.
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Sabella to incorporate Butler’s context -based actuation control at the MEC edge host of Sabella, wherein Butler teaches that actuation plans at MEC edge nodes are updated based on context changes and that execution at the node is triggered and carried out based on those context-driven actuation plans. The motivation being to implement a known technique of context driven actuation control in a distributed MEC environment, resulting in improved system responsiveness, reduced latency, and more efficient execution of tasks at the point of execution, thereby improving performance of subscriber services and/or applications.
Regarding claim 11, Sabella in view of Butler and in further view of Sood discloses the system as claimed in claim 8, further comprising a function repository module formed in the mobile unit and configure to store the functions which are potentially intended to be carried out and to make them available to the function runtime module (The combined solution per Sood provides for enclaves which store all the functions;
See e.g. Abstract “... Secure enclaves are created in system memory of a compute platform configured to support a virtualized execution environment including a plurality of virtual machines (VMs) or containers ...”)
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Sabella with Sood’s utilization of MEC infrastructure comprising NFVs in isolated environments. The motivation being the combined solution provides for migrating and benefiting from MEC deployments (i.e. edge services) and gaining increased efficiencies and security from NFV in containers.
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Sabella to incorporate Butler’s context -based actuation control at the MEC edge host of Sabella, wherein Butler teaches that actuation plans at MEC edge nodes are updated based on context changes and that execution at the node is triggered and carried out based on those context-driven actuation plans. The motivation being to implement a known technique of context driven actuation control in a distributed MEC environment, resulting in improved system responsiveness, reduced latency, and more efficient execution of tasks at the point of execution, thereby improving performance of subscriber services and/or applications.
Claim 13 is rejected under 35 USC 103 as being unpatentable over Sabella in view of Butler and in further view of Freese(US 2020/0393255)
Regarding claim 13, Sabella in view of Butler discloses the system as claimed in claim 7, Sabella does not expressly disclose further comprising a context sensor module formed in the mobile unit configured to generate information relating to the context
However in analogous art Freese discloses:
a context sensor module formed in the mobile unit configured to generate information relating to the context (Freese;
see e.g. [0052] “... distributed edge -computing system ...”.
see e.g. [0054] “... a variety of sensors ... to collect data ... determine (e.g. predict) a possible context ...”
see e.g. [0074] “... edge computing solution ... evaluate the data obtained by sensors ...” )
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Sabella with Freese’ sensor scheme. The motivation being the combined solution provides for increased efficiencies in provisioning resources within an edge computing environment.
Claims 12 and 14 are rejected under 35 USC 103 as being unpatentable over Sabella in view of Butler and in further view of Seed (US 2023/006671)
Regarding claim 14, Sabella in view of Butler discloses the system as claimed in claim 7, Sabella does not expressly disclose comprising a movement, path, coverage, and context predictor component configured to predict contexts for the components of the system and make them available to the mobile unit.
However in analogous art Seed discloses:
Context predictor component (Seed; Seed teaches within the realm and/or field of edge computing a context predictor component;
See e.g. [0169] “... edge computing service provider interactions ...”
See e.g. [0173] “... a route may be predicted or inferred based on real-time and/or historical context information available from various entities in the system ... commute patterns of the UE .. predictive analytics ... ... leverage predicted analytics to predict routes”
See e.g. [0053] “Using context information, a predicted route may be calculated by and EAHS and then used to select the next EAS(s) that AC9s) hosted on a UE are handed off to ...”
See e.g. [0038] “EAHS policy rules may be contingent upon context information that pertain to information such as UE’s current location, a UE’s planned or a anticipated route, status information pertaining to the network (e.g. congestion levels)”
See e.g. [0039] An EAHS may interface to various entities in a 3GPP system and receive context information from these entities including but not limited to Core Network Functions, Application Clients, Edge Enabler Clients, Edge Application Handover Clients, V2X Application Enabler Servers ...”)
Therefore it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Sabella with Seeds’s context prediction supporting edge computing infrastructure. The motivation being the combined solution provides for one of ordinary skill in the art to migrate to current edge computing deployments (e.g., Multi Access Edge Computing) and reap the known benefits from these deployments.
Regarding claim 12, claim 12 comprises the same and/or similar subject matter as claim 14 and is considered an obvious variation; therefore it is rejected under the same rationale.
Claims 1 and 7 are rejected under 35 USC 103 as being patentable over Sabella (US 2018/0183855) in view of Elgazzar, “Cloud-Assisted Computing Offloading to Support Mobile Services”, July-September 2016
Regarding claim 1, Sabella discloses an automated method for providing functionalities of a mobile unit, the method comprising:
receiving a task request from a requesting unit, the task request including a required function along with corresponding parameters and context rules (Sabella; Sabella teaches the MEC orchestrator receives a request from UE application residing on a UE device (i.e. requesting unit) and where the request includes information about (i)the application to be run (i.e. required function) and (ii)location and application rules and requirements (parameters and context rules)
see e.g.[0087] “In order to run an MEA 336 in the mobile edge system 400, the MEC-O 321 may receive requests triggered by the OSS 322, a third-party 310, or a UE application 305. In response to receipt of such requests, the MEC-O 321 may select an MEH 200 to host the MEA 336 for computational offloading. These requests may include information about the application to be run, and possibly other information, such as the location where the application needs to be active, other application rules and requirements, as well as the location of the application image if it is not yet on-boarded in the MEC system 400” )
loading the required function into the mobile unit (Sabella; Sabella teaches the MEC orchestrator loads or instantiates the requested function onto a mobile edge host (i.e. mobile unit)
The Examiner notes per dependent claim 2 below the mobile unit may be readily equivalent to a mobile edge host
see e.g.[0087] “In order to run an MEA 336 in the mobile edge system 400, the MEC-O 321 may receive requests triggered by the OSS 322, a third-party 310, or a UE application 305. In response to receipt of such requests, the MEC-O 321 may select an MEH 200 to host the MEA 336 for computational offloading. These requests may include information about the application to be run, and possibly other information, such as the location where the application needs to be active, other application rules and requirements, as well as the location of the application image if it is not yet on-boarded in the MEC system 400”
see e.g. [0074] “... instantiating on an MEH 200 ... “); and
carrying out the task by executing the required function on the Mobil unit when triggered by the context rules (Sabella; Sabella teaches execution of the function occurs on the selected MEH (i.e. mobile unit) ro which the task is offloaded. The orchestration decision is based on “application requirements”, which are the context rules supplied with the UE request. Thus, the task is executed on the mobile unit when the context rules are satisfied;
see e.g. [0088] “In various embodiments, the MEC-O 321 may select an MEH 200 for computational offloading of UE application 305 tasks based on MEH parameters, network capabilities and conditions, and application requirements... “);
and reporting a result of the function to the requesting unit (Sabella;
see e.g. [0146] “Table 2 shows input application parameters of a particular UE app 305. The application parameters of table 2 include task frequency (e.g., how often the task should be offloaded over time), computation load in terms of Giga Floating Point Operations Per Second (GFLOPS), data volume to be transferred as input for offloading the task (e.g., data to be sent by UE 101 for offloading), and data volume to be transferred as an output for offloading the task (e.g., data to be sent back to the UE 101 after offloading”). ;
wherein the function is carried out in the mobile unit only if one or more rules of the context rule system are satisfied (Sabella; Sabella teaches that execution on the MEH is conditional on application requirements. The MEH is selected only when those requirements are met if no selection is made , the function is not carried out.
See e.g. [0074] “The MEAs 336 may have a certain number of rules and requirements associated to them, such as required resources, maximum latency, required or useful services, etc. ...”
see e.g. [0088] “In various embodiments, the MEC-O 321 may select an MEH 200 for computational offloading of UE application 305 tasks based on MEH parameters, network capabilities and conditions, and application requirements... “)
Sabella does not expressly disclose:
the mobile unit storing a context rule system; and
in response to receipt of the task request from the requesting unit, the mobile unit triggering the task;
However in analogous art Elgazzar discloses:
the mobile unit storing a context rule system( Elgazarr;
Elgazzar teaches execution and context management functions at a mobile service provider that is distinct from both the user device and the cloud, indicating an intermediate execution node within the network (se e.g. Fig. 1, Fig. 2)
Elgazzar discloses functional components including a Context Manager, Execution Planner, and Execution Engine that collectively control execution based on contextual conditions (Fig. 2), One of ordinary skill in the art would have been able to implement these functional components at different nodes of a distributed system, and would have motivated to apply such context-based execution control of the mobile edge host
PNG
media_image1.png
395
506
media_image1.png
Greyscale
);
PNG
media_image2.png
270
482
media_image2.png
Greyscale
PNG
media_image3.png
110
489
media_image3.png
Greyscale
in response to receipt of the task request from the requesting unit, the mobile unit triggering the task (Elgazarr; Elgazarr teaches that upn receipt of a request, the request/response handler processes the request and forwards it to the context manager and execution planner (Fig. 2). The context manager evaluates the request conditions, and the execution planner determines execution, after which the execution engine triggers and performs the task );
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the context management and execution control function components of Elgazzar, including a Context Manager, Execution Planner, and Execution Engine, into the mobile edge host of Sabella, which performs tasks execution. The motivation being that the combined solution applies a known technique to a known device resulting in improved system responsiveness. Furthermore, one of ordinary skill in the art would have been motivated to apply such context based execution control to the mobile edge host of Sabella, in order to enable context-driven triggering of tasks at the point of execution, thereby improving execution efficiency, reducing latency, and improving user experience for subscriber services and/or applications.
This is further illustrated in Fig. 2 where the mobile service provider includes both an execution engine and a context manager that collectively control execution at that node
Regarding claim 7, claim 7 comprises the same and/or similar subject matter as claim 1 and is considered an obvious variation; therefore it is rejected under the same rationale
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to TODD L. BARKER whose telephone number is (571) 270 0257. The Examiner can normally be reached on Monday through Friday, 7:30am to 5:00pm.
If attempts to reach the Examiner by telephone are unsuccessful, the Examiner's supervisor Vivek Srivastava can be reached on (571) 272 7304.
/TODD L BARKER/ Primary Examiner, Art Unit 2449