DETAILED ACTION
The following is a final office action in response to applicant’s amendment filed on 06/02/2026 for response of the office action mailed on 12/02/2025. Claims 1-15 are were previously cancelled. Therefore, claims 16-30 are pending and addressed below.
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 .
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.
In 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 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 factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 16, 18-27 and 30 are rejected under 35 U.S.C. 103 as being unpatentable over Senthil Kumar Subramaniam (20190/335320) Subramaniam hereinafter, in view of Tofighbakhsh et al. (2020/0177671), Tofighbakhsh hereinafter.
Re. claim 16, Subramaniam teaches a method (Fig. 1- 4 & ¶0017/¶0027/¶0041/¶0043), comprising: configuring an overlay network to support processing of data using compute functionality that is migrate-able (Fig. 1-2 & ¶0017 - home network 102 and outside of home network 104. Home network 102 includes MEC platform 110a, MEC roaming manager 112a, cache 114a, base stations 120a-120b, while outside of home network (e.g., partner network) 104 includes MEC platform 110b, MEC roaming manager 112b, cache 114b, and base stations 120c-120d. Home network 102 may initially identify device 106 that is capable of or currently executing a MEC application. Based on the identification, MEC roaming manager 112b may cache a state of the MEC application and associated within cache 114a as at modules 116-118. This data may be transmitted to MEC platform 110b outside of the home network 104 so that upon device 106 roaming within the partner network 104 and/or based upon a periodic basis, MEC platform 110a transmits this data. Fig. 1-2 & ¶0019 - MEC platforms 108a-108b are components in each respective network 102 and 104 that include MEC roaming manager 110a-110b and cache 112a-112b. As such, MEC platform 108a-108b include the infrastructure at which the edge computing is performed. ..….the MEC platforms 108 and 110 are …. located at each layer of networks 102 and 104 to provide the functionality of multi-access edge computing (MEC). Fig. 1-4 & ¶0020 - MEC roaming managers 110a-110b track device 106 by attachment of device 106 to corresponding base stations 118a-118b. Accordingly, MEC roaming managers 110a-110b identify when device 106 is roaming outside of home network 104 and transmits the state of the application and associated data. Fig. 1-4 & ¶0027 - MEC platform 208g may obtain the state of the MEC application and associated data by proactive propagation or triggered by device 206 roaming within the visited network. With proactive propagation, MEC platform 208b at the EPC layer retrieves the state of the MEC application from the MEC platform at the data center layer and caches this data and transmits to MEC platforms 208c-208d at the base station layer….. With the roaming trigger, upon device 206 reaching base station 218c this triggers MEC platform 208 to request data from the MEC platform 208f which retrieves data from the data center layer. Once device 206 moves out of the home network to base station 218c within visited network, the MEC platforms 208a-208d in the home network may purge the cached state of the MEC application and associated data.); responsive to a given constraint, selectively migrating compute functionality to one or more edge-based machines in the overlay network (Fig.1-4 & ¶0039 - At operation 412, the computing device determines that the device is roaming outside of the home network. In this operation, the device may be roaming in a partner's network that is serviced by a different MEC platform. As such, based on the determination that the device is outside of the home network, the computing device may synchronize the state of the MEC application and associated data as at operation 418. Fig.1-4 & ¶0041 - At operation 416 based on the determination that the device is roaming outside of the home network and within the partner's network, the computing device transmits the state of the MEC application and associated data to the MEC platforms located at adjacent base stations to the device. This ensures the device continues execution of the MEC application without interruption and/or latency.); and executing a data processing function on the migrated compute functionality (Fig.1-4 & ¶0041 - At operation 416 based on the determination that the device is roaming outside of the home network and within the partner's network, the computing device transmits the state of the MEC application and associated data to the MEC platforms located at adjacent base stations to the device. Fig.1-4 & ¶0043 - At operation 420, the computing device transports the state of the MEC application and associated data that is transmitted at operations 416-420 using a security mechanism such as an SSL security mechanism. Using the security mechanism to transport the data provides security by encrypting data pertaining to the device. Also, see step 306 in Fig. 3).
PNG
media_image2.png
631
1135
media_image2.png
Greyscale
Even though, Subramaniam teaches responsive to a given constraint, ……………….. migrating compute functionality to one or more edge-based machines in the overlay network, Subramaniam doesn’t expressly teach the claimed feature, “selectively” as recited in the claimed limitation, however, Tofighbakhsh, in the analogous art, explicitly discloses responsive to a given constraint, selectively migrating compute functionality to one or more edge-based machines in the overlay network (Fig. 1-8 & ¶0041 - the workload management component 404 can compile the path into a group of expected passages through select edge IoT gateway nodes deployed along the path and schedule workload into these edge IoT gateway nodes. A first set of workloads can be performed in response to detecting desired/expected scenarios associated with the reported shipment states and/or sensor states and a second set of workloads can be performed in response to detecting undesired/unexpected scenarios associated with the reported shipment states and/or sensor states. The asynchronous programming of the edge IoT gateway nodes for the workloads can provide a highly efficient and optimal QoS monitoring. Fig. 1-8 & ¶0051 - method 700 that facilitates global QoS realization through management of a network of collaborative edge IoT gateways…. method 700 can be implemented by one or more control plane devices (e.g., edge IoT controller 204) of a communication network (e.g., cellular network). At 702, customer provisioning data can be received. …. the provisioning data can be utilized to identify edge IoT gateways that are located along one or more shipping routes and accordingly, at 704, QoS-aware workloads can be scheduled at the identified edge IoT gateways. Fig. 1-8 & ¶0052 - Further, at 706, internal and/or external state data can be determined. … the internal state data can be received from one or more of the distributed IoT gateway nodes and can comprise workload state information such as….. a report of tasks performed, received sensor measurements, error/failure conditions, alerts, and/or unexpected scenarios. In another example, the external state data can be received from web servers, content servers, application server, customer devices, etc. and can comprise information such as, but not limited to, schedule information, event data, news, weather data, traffic reports, customer preferences or instructions, etc. At 708, the state data can be analyzed (e.g., based on ML techniques) to facilitate a management of the QoS-aware workloads. Fig. 1-8 & ¶0053 - the workload data can comprise a set of actions that are to be performed via one or more microservices executed by the edge IoT gateway node. Further, at 804, the execution of the workload can be initiated in response to receiving communication data (e.g., broadcast messages) from an IoT device associated with the workload data. for example, the workload can be initiated in response to determining that the IoT device has entered a geographical area served by the edge IoT gateway node and/or is coupled to the edge IoT gateway node. Fig. 1-8 & ¶0054 - at 806, feedback data can be determined and provided to the edge IoT controller ……the feedback data can comprise…. a summary/list/result of actions performed via workload execution, measurements received from the IoT device, failure/error conditions, unexpected behavior ….. at 808, tracking data can be determined and provided to other edge IoT gateways via a mesh network, for example, to facilitate tracking and/or security (e.g., by employing a Blockchain technology));
PNG
media_image3.png
368
597
media_image3.png
Greyscale
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filling date of the claimed invention to combine Subramaniam’s invention of transmission outside of a home network of a state of a MEC (Multi-Access Edge computing) application in a wireless communication system to include Tofighbakhsh’s invention of global internet of things (IOT) quality of service (QoS) realization through collaborative edge gateways in a wireless network, because it provides distributed IoT gateway nodes form a structured mesh network globally over Internet that can communicate asynchronously and/or synchronously so that the distributed IoT gateway nodes can implement advanced collaborative and/or distributed technologies (e.g., Blockchain) to track/monitor QoS and SLA (service level agreement) globally in the wireless network. (¶0030, Tofighbakhsh)
Re. claim 18, Subramaniam and Tofighbakhsh teach claim 16.
Subramaniam further teaches wherein the given constraint is receipt of a request that a given number of instances of the compute functionality be configured, wherein a determination of where to migrate the compute functionality is determined dynamically. (1-4 & ¶0027 - MEC platform 208g may obtain the state of the MEC application and associated data by proactive propagation or triggered by device 206 roaming within the visited network. With proactive propagation, MEC platform 208b at the EPC layer retrieves the state of the MEC application from the MEC platform at the data center layer and caches this data and transmits to MEC platforms 208c-208d at the base station layer….. With the roaming trigger, upon device 206 reaching base station 218c this triggers MEC platform 208 to request data from the MEC platform 208f which retrieves data from the data center layer. Once device 206 moves out of the home network to base station 218c within visited network, the MEC platforms 208a-208d in the home network may purge the cached state of the MEC application and associated data. 1-4 & ¶0032 - At operation 306, the computing device transmits the state of the MEC application and associated data to other MEC platform(s) outside of the home network. The other MEC platform(s) may initially send a request for the transmission of the state of the MEC application and associated data upon the determination that the device is roaming in the area serviced by the other MEC platform(s). See claim 11, which recites, “the different roaming manager located outside of the home network and on the different MEC platform that: in response to a determination that the device is located outside of the home network, transmitting a request by the different roaming manager for the state of the MEC application and associated data; and receive, by the different roaming manager from the data center layer within the home network, the state of the MEC application and associated data.”, also, see claim 12, which recites, “the different roaming manager, located on the different MEC platform, outside of the home network that: receives on a periodic basis, from the roaming manager within the home network, the state of the MEC application and associated data. ”, that is, a plurality of number of instances is computed as determined by a plurality number of roaming managers at different MEC platform(s), outside of home network to transmit state of the MEC application and associated data (as triggered in a plurality of roaming scenarios disclosed supra) to other MEC platform(s) as disclosed supra, contrary to applicant’s arguments at least at page 8 of remarks as submitted on 06/02/2026. ).
Re. claim 19, Subramaniam and Tofighbakhsh teach claim 16.
Subramaniam further teaches wherein the given constraint is receipt of an indication that a centralized computing location cannot then provide sufficient computing resources to execute the data processing function (Fig.1-4 & ¶0010 - Multi-access edge computing, (MEC), may also be referred to as multi-access edge compute, is a standard by European Telecommunications Standards Institute (ETSI) that involves a network architecture concept that enables cloud computing capabilities and IT service environment at an edge of a communication network. In a MEC architecture, computing and storage resources are placed in closer proximity to the mobile devices they service. The idea is that executing applications and performing related processing tasks closer to the mobile device, network congestion is reduced…...Fig.1-4 & ¶0036 - Retrieving the data form the data center layer and pushing out to the MEC platform(s) that perform the computing of the MEC application at the edge reduces the latency associated with operation of the MEC application. Fig.1-4 & ¶0041 - At operation 416 based on the determination that the device is roaming outside of the home network and within the partner's network, the computing device transmits the state of the MEC application and associated data to the MEC platforms located at adjacent base stations to the device. This ensures the device continues execution of the MEC application without interruption and/or latency).
Re. claim 20, Subramaniam and Tofighbakhsh teach claim 16.
Subramaniam further teaches wherein the given constraint is receipt of an indication that a network resource necessary to support the data processing function is operating under a restriction and cannot perform the data processing function. (Fig.1-4 & ¶0036 - The retrieval of this data may be triggered based on the device roaming in the network outside of the home network or by proactive propagation in which the MEC platform at the evolved packet core (EPC) layer retrieves the data from the data center layer. In the proactive propagation situation, one of the MEC platforms within the home network retrieves the state of the MEC application and associated data from the data center layer and caches the data as at operation 410. Retrieving the data form the data center layer and pushing out to the MEC platform(s) that perform the computing of the MEC application at the edge reduces the latency associated with operation of the MEC application. Fig.1-4 & ¶0041 - At operation 416 based on the determination that the device is roaming outside of the home network and within the partner's network, the computing device transmits the state of the MEC application and associated data to the MEC platforms located at adjacent base stations to the device. This ensures the device continues execution of the MEC application without interruption and/or latency.)
Re. claim 21, Subramaniam and Tofighbakhsh teach claim 16.
Subramaniam further teaches wherein the overlay network in a content delivery network (CDN). (Fig.1-4 & ¶0010 - Multi-access edge computing, (MEC), may also be referred to as multi-access edge compute, is a standard by European Telecommunications Standards Institute (ETSI) that involves a network architecture concept that enables cloud computing capabilities and IT service environment at an edge of a communication network. In a MEC architecture, computing and storage resources are placed in closer proximity to the mobile devices they service. The idea is that executing applications and performing related processing tasks closer to the mobile device, network congestion is reduced…. Fig.1-4 & ¶0016 - a number of example implementations for transmission of the state of the MEC application across MEC platforms. The disclosed examples may include systems, devices, computer-readable storage media, and methods for transmission of the state of the MEC application. ….., all or part of the functionality of illustrated elements may co-exist or be distributed among several geographically dispersed locations. Fig.1-4 & ¶0017 - Home network 102 includes MEC platform 110a (interpreted as Overlay network ([Wingdings font/0xF3] 108a)), MEC roaming manager 112a, cache 114a, base stations 120a-120b, while outside of home network (e.g., partner network) 104 includes MEC platform 110b (interpreted as Overlay network ([Wingdings font/0xF3] 108b)),), MEC roaming manager 112b, cache 114b, and base stations 120c-120d. Please note that a content delivery network, CDN (e.g., MEC platform 110a,110b, 108a, 108b) is a distributed group of servers that caches content closer to the mobile device as disclosed supra along with Fig. 1-2).
Re. claim 22, Subramaniam and Tofighbakhsh teach claim 16.
Subramaniam further teaches wherein the overlay network is associated with a compute infrastructure. (Fig.1-4 & ¶0010 - Multi-access edge computing, (MEC), may also be referred to as multi-access edge compute, is a standard by European Telecommunications Standards Institute (ETSI) that involves a network architecture concept that enables cloud computing capabilities and IT service environment at an edge of a communication network. In a MEC architecture, computing and storage resources are placed in closer proximity to the mobile devices they service. The idea is that executing applications and performing related processing tasks closer to the mobile device, network congestion is reduced…. Fig.1-4 & ¶0016 - a number of example implementations for transmission of the state of the MEC application across MEC platforms. The disclosed examples may include systems, devices, computer-readable storage media, and methods for transmission of the state of the MEC application. ….., all or part of the functionality of illustrated elements may co-exist or be distributed among several geographically dispersed locations. Fig.1-4 & ¶0017 - Home network 102 includes MEC platform 110a (interpreted as Overlay network ([Wingdings font/0xF3] 108a)), MEC roaming manager 112a, cache 114a, base stations 120a-120b, while outside of home network (e.g., partner network) 104 includes MEC platform 110b (interpreted as Overlay network ([Wingdings font/0xF3] 108b)),), MEC roaming manager 112b, cache 114b, and base stations 120c-120d. Please note that a content delivery network, CDN (e.g., MEC platform 110a,110b, 108a, 108b) is a distributed group of servers that caches content closer to the mobile device as disclosed supra along with Fig. 1-2).
Re. claim 23, Subramaniam and Tofighbakhsh teach claim 16.
Yet, Subramaniam does not expressly teach wherein the compute functionality is migrated based on a predicted demand.
However, in the analogous art, Tofighbakhsh explicitly discloses wherein the compute functionality is migrated based on a predicted demand. (Fig. 1-8 & ¶0033 - edge IoT controller 204 can determine and/or predict arrival time of the shipment at the edge IoT gateway nodes 202.sub.1-202.sub.5 and accordingly, coordinate the workloads locally and/or internationally. Fig. 1-8 & ¶0034 - in response to determining that severe weather conditions are being experienced in an area through which the shipment is originally being routed, the edge IoT controller 204 can predict whether the shipment would be rerouted to/through another location and accordingly, reassign the workload to another IoT gateway node (e.g., IoT gateway node 202.sub.x) to perform the defined action(s) (e.g., expect the shipment, take action /perform functions on arrival/departure, report sensor measurements, check for error, failure, and/or alert conditions, etc.). Accordingly, as path changes are detected (e.g., shipment is received at an IoT gateway node that is not located on/near the original route, shipment is received earlier or later than expected, etc.) and/or are predicted (e.g., via internal state data, external state data, ML, etc.), the edge IoT controller 204 can dynamically update workload configuration across the edge IoT gateway nodes 202.sub.1-202.sub.x.)
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filling date of the claimed invention to combine Subramaniam’s invention of transmission outside of a home network of a state of a MEC (Multi-Access Edge computing) application in a wireless communication system to include Tofighbakhsh’s invention of global internet of things (IOT) quality of service (QoS) realization through collaborative edge gateways in a wireless network, because it provides distributed IoT gateway nodes form a structured mesh network globally over Internet that can communicate asynchronously and/or synchronously so that the distributed IoT gateway nodes can implement advanced collaborative and/or distributed technologies (e.g., Blockchain) to track/monitor QoS and SLA (service level agreement) globally in the wireless network. (¶0030, Tofighbakhsh)
Re. claim 24, Subramaniam and Tofighbakhsh teach claim 23.
Yet, Subramaniam does not expressly teach wherein the predicted demand is machine-learned.
However, in the analogous art, Tofighbakhsh explicitly discloses wherein the predicted demand is machine-learned. (Fig. 1-8 & ¶0029 - master IoT orchestration component 108 can receive workload state feedback from each workload triggered by its associated sensor(s). Based on an analysis of the state feedback (and/or one or more machine learning techniques), the master IoT orchestration component 108 can terminate and/or reconfigure the current workload and/or activate one or more new workloads at another IoT gateway (e.g., deployed at a next expected location for a shipment). Fig. 1-8 & ¶0032 - edge IoT controller 204 can utilize machine learning (ML)-based models for realization of additional QoS, SLA, and/or monitoring services. Fig. 1-8 & ¶0033 - edge IoT controller 204 can determine and/or predict arrival time of the shipment at the edge IoT gateway nodes 202.sub.1-202.sub.5 and accordingly, coordinate the workloads locally and/or internationally).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filling date of the claimed invention to combine Subramaniam’s invention of transmission outside of a home network of a state of a MEC (Multi-Access Edge computing) application in a wireless communication system to include Tofighbakhsh’s invention of global internet of things (IOT) quality of service (QoS) realization through collaborative edge gateways in a wireless network, because it provides distributed IoT gateway nodes form a structured mesh network globally over Internet that can communicate asynchronously and/or synchronously so that the distributed IoT gateway nodes can implement advanced collaborative and/or distributed technologies (e.g., Blockchain) to track/monitor QoS and SLA (service level agreement) globally in the wireless network. (¶0030, Tofighbakhsh)
Re. claim 25, Subramaniam and Tofighbakhsh teach claim 16.
Yet, Subramaniam does not expressly teach wherein the compute functionality is pre-positioned on the one or more edge-based machines in the overlay network in advance of demand for the compute functionality.
However, in the analogous art, Tofighbakhsh explicitly discloses wherein the compute functionality is pre-positioned on the one or more edge-based machines in the overlay network in advance of demand for the compute functionality. (Fig. 1-8 & ¶0033 - edge IoT controller 204 can determine and/or predict arrival time of the shipment at the edge IoT gateway nodes 202.sub.1-202.sub.5 and accordingly, coordinate the workloads locally and/or internationally. Fig. 1-8 & ¶0034 - in response to determining that severe weather conditions are being experienced in an area through which the shipment is originally being routed, the edge IoT controller 204 can predict whether the shipment would be rerouted to/through another location and accordingly, reassign the workload to another IoT gateway node (e.g., IoT gateway node 202.sub.x) to perform the defined action(s) (e.g., expect the shipment, take action /perform functions on arrival/departure, report sensor measurements, check for error, failure, and/or alert conditions, etc.). Accordingly, as path changes are detected (e.g., shipment is received at an IoT gateway node that is not located on/near the original route, shipment is received earlier or later than expected, etc.) and/or are predicted (e.g., via internal state data, external state data, ML, etc.), the edge IoT controller 204 can dynamically update workload configuration across the edge IoT gateway nodes 202.sub.1-202.sub.x.)
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filling date of the claimed invention to combine Subramaniam’s invention of transmission outside of a home network of a state of a MEC (Multi-Access Edge computing) application in a wireless communication system to include Tofighbakhsh’s invention of global internet of things (IOT) quality of service (QoS) realization through collaborative edge gateways in a wireless network, because it provides distributed IoT gateway nodes form a structured mesh network globally over Internet that can communicate asynchronously and/or synchronously so that the distributed IoT gateway nodes can implement advanced collaborative and/or distributed technologies (e.g., Blockchain) to track/monitor QoS and SLA (service level agreement) globally in the wireless network. (¶0030, Tofighbakhsh)
Re. claim 26, Subramaniam and Tofighbakhsh teach claim 16.
Subramaniam also teaches further including migrating a data state in association with migrating the compute functionality. (Fig.1-4 & ¶0010 - Multi-access edge computing, (MEC), may also be referred to as multi-access edge compute, is a standard by European Telecommunications Standards Institute (ETSI) that involves a network architecture concept that enables cloud computing capabilities and IT service environment at an edge of a communication network. In a MEC architecture, computing and storage resources are placed in closer proximity to the mobile devices they service. The idea is that executing applications and performing related processing tasks closer to the mobile device, network congestion is reduced…..Fig.1-4 & ¶0036 - Retrieving the data form the data center layer and pushing out to the MEC platform(s) that perform the computing of the MEC application at the edge reduces the latency associated with operation of the MEC application. Fig.1-4 & ¶0041 - At operation 416 based on the determination that the device is roaming outside of the home network and within the partner's network, the computing device transmits the state of the MEC application and associated data to the MEC platforms located at adjacent base stations to the device. This ensures the device continues execution of the MEC application without interruption and/or latency).
Re. claim 27, Subramaniam and Tofighbakhsh teach claim 16.
Subramaniam further teaches wherein the one or more edge-based machines in the overlay network comprise an ad hoc mesh network (Fig.1-4 & ¶0010 - Multi-access edge computing, (MEC), may also be referred to as multi-access edge compute, is a standard by European Telecommunications Standards Institute (ETSI) that involves a network architecture concept that enables cloud computing capabilities and IT service environment at an edge of a communication network. In a MEC architecture, computing and storage resources are placed in closer proximity to the mobile devices they service. The idea is that executing applications and performing related processing tasks closer to the mobile device, network congestion is reduced. Fig.1-4 & ¶0015 - “MEC” is meant to include a network architecture concept that enables cloud computing capabilities and an IT service environment at the edge of the communications network. As such, “MEC” may refer to multi-access edge compute and/or mobile edge computing. Further the term, “MEC application” may refer to those programs, algorithms, code, software that is executable by a processing resource to enable functionality of MEC. Fig.1-4 & ¶0019 - MEC platforms 108a-108b are components in each respective network 102 and 104 that include MEC roaming manager 110a-110b and cache 112a-112b. As such, MEC platform 108a-108b include the infrastructure at which the edge computing is performed. In an implementation, the MEC platforms 108 and 110 are considered a stack that includes the software executable by a processing resource and hardware components located at each layer of networks 102 and 104 to provide the functionality of multi-access edge computing (MEC).)
Re. claim 30, Subramaniam and Tofighbakhsh teach claim 16.
Subramaniam further teaches wherein the given constraint is associated with a constraint or requirement of a customer of the overlay network. (Fig.1-4 & ¶0036 - Retrieving the data form the data center layer and pushing out to the MEC platform(s) that perform the computing of the MEC application at the edge reduces the latency associated with operation of the MEC application. Fig.1-4 & ¶0039 - At operation 412, the computing device determines that the device is roaming outside of the home network. In this operation, the device may be roaming in a partner's network that is serviced by a different MEC platform. As such, based on the determination that the device is outside of the home network, the computing device may synchronize the state of the MEC application and associated data as at operation 418. Fig.1-4 & ¶0041 - At operation 416 based on the determination that the device is roaming outside of the home network and within the partner's network, the computing device transmits the state of the MEC application and associated data to the MEC platforms located at adjacent base stations to the device. This ensures the device continues execution of the MEC application without interruption and/or latency.)
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Subramaniam, in view of Tofighbakhsh, further in view of Sabella et al. (2019/0266496), Florissi hereinafter.
Re. claim 17, Subramaniam and Tofighbakhsh teach claim 16.
Yet, Subramaniam and Tofighbakhsh do not expressly teach wherein the given constraint is that data to be processed cannot be moved due to privacy or security restrictions.
However, in the analogous art, Florissi explicitly discloses wherein the given constraint is that data to be processed cannot be moved due to privacy or security restrictions. (Fig. 1-61 & ¶0106 - It may be assumed in some implementations of system 200 that the datasets each site or cloud collects are locked into the corresponding data zone, meaning that a given dataset cannot move outside of the boundaries of the associated site or cloud. There may be a variety of factors preventing the data from moving, including a data size that imposes severe bandwidth delays or transmission costs, privacy issues that prohibit the data from being shared outside the data zone, or GRC regulatory requirements mandating that the data remain within the data zone.)
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filling date of the claimed invention to combine Subramaniam’s invention of transmission outside of a home network of a state of a MEC (Multi-Access Edge computing) application in a wireless communication system and Tofighbakhsh’s invention of global internet of things (IOT) quality of service (QoS) realization through collaborative edge gateways in a wireless network to include Florissi’s invention of analytics platform for scalable distributed computations in a wireless network, because it provides a web-based interface permitting registration of datasets of respective data zones for use in performing distributed computations across a plurality of data processing clusters associated with the respective data zones in the wireless network. (¶0005, Florissi)
Claim 28 is rejected under 35 U.S.C. 103 as being unpatentable over Subramaniam, in view of Tofighbakhsh, further in view of Weihl et al. (2004/0093419), Weihl hereinafter.
Re. claim 28, Subramaniam and Tofighbakhsh teach claim 16.
Yet, Subramaniam and Tofighbakhsh do not expressly teach wherein the one or more edge-based machines in the overlay network are identified by trading off a cost and a performance requirement.
However, in the analogous art, Weihl explicitly discloses wherein the one or more edge-based machines in the overlay network are identified by trading off a cost and a performance requirement. (Fig. 1-8 & ¶0049 - Secure content delivery enables Web sites with secure content to take full advantage of the increased performance, reliability, and scalability benefits of the CDN managed service across the entire site while specifically addressing cost and complexity issues that are inherent in SSL Web site infrastructure. Preferably, the secure CDN comprises servers deployed in data centers and on networks that meet strict security requirements. Edge servers are not authorized to access and use SSL certificates and thus to serve content over the secure CDN until they have been first authenticated, preferably by passing an audit. The dedicated network provides significant advantages in that SSL objects and cacheable content are delivered from servers closer to the end user, thereby avoiding Internet congestion, computation-intensive SSL handshake is faster when performed at the edge (i.e., shorter Internet distance reduces latency), and secure content is retrieved over an already-established secure connection between edge server and origin server, thereby reducing the SSL handshake overhead. Offloading computation-intensive SSL processing significantly reduces the load on a Web site's infrastructure, enabling the site to handle more users.)
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filling date of the claimed invention to combine Subramaniam’s invention of transmission outside of a home network of a state of a MEC (Multi-Access Edge computing) application in a wireless communication system and Tofighbakhsh’s invention of global internet of things (IOT) quality of service (QoS) realization through collaborative edge gateways in a wireless network to include Weihl’s invention of a system and a method for secure content delivery, because it reduces load on a Web site's infrastructure, enabling the web site to handle more users by Offloading computation-intensive SSL processing. (¶0049, Weihl)
Claim 29 is rejected under 35 U.S.C. 103 as being unpatentable over Subramaniam, in view of Tofighbakhsh, further in view of Ashrafi et al. (2018/0376338), Ashrafi hereinafter.
Re. claim 29, Subramaniam and Tofighbakhsh teach claim 16.
Yet, Subramaniam and Tofighbakhsh do not expressly teach wherein the given constraint is associated with an optimization function that trades off one of: network latency, state latency, compute latency, setup time and location, and combinations thereof.
However, in the analogous art, Ashrafi explicitly discloses wherein the given constraint is associated with an optimization function that trades off one of: network latency, state latency, compute latency, setup time and location, and combinations thereof. (Fig. 11A & ¶0074 - Referring now to FIG. 11A there are illustrated the various trade-offs that must be considered within the network when trying to improve overall network performance. A number of factors may be considered in determining trade-offs in network performance 1102. By selecting improved performance of certain of these factors others of the factors would by necessity have to have a decrease performance level. The factors which must be balanced include interworking, mobility, latency, spectral efficiency, into a throughput, quality of service, simplicity, total cost of ownership, integration and security. Interworking is the method for interfacing a wireless communications network with the public switched telephone network. The interworking function (IWF) provides the function to enable a GSM system to interface with various forms of public and private networks currently available. Mobility relates to the capability of moving or being moved while a wireless device is being used. Latency is the delay within the network. Examiner interprets that only one of the claimed features to be mapped because of the presence of “one of:”).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filling date of the claimed invention to combine Subramaniam’s invention of transmission outside of a home network of a state of a MEC (Multi-Access Edge computing) application in a wireless communication system and Tofighbakhsh’s invention of global internet of things (IOT) quality of service (QoS) realization through collaborative edge gateways in a wireless network to include Ashrafi’s invention of a system and a method for providing flexible network configurations in a wireless communication system, because it provides flexible network configurations using logically independent network slicing and data center based cloud architecture to support various applications and services in the wireless communication system. (¶0049, Ashrafi)
Response to Arguments
Applicant's arguments filed on 06/02/2026 have been fully considered but they are not persuasive.
At the outset, Examiner notes that despite the lengthy arguments presented by the applicant, this case turns on a few focused questions.
First, In reference to independent claim 1, the applicant attempts to read more meaning into the claim limitations than is reasonable. In some cases, the applicant attempts to read entire sections of the specification into the claims. Examiner contends that the claim limitations are not nearly as narrow as the applicant attempts to argue. For example, in reference to independent claim 1, the applicant states that the claim relates to configuring an overlay network to support processing of data using compute functionality that is migrate-able as claimed in the independent claim 1. Please note that the compute functionality as defined in the instant application, refers to compute capacity demand in an overlay network and predict it so that the predicted/anticipated compute capacity is pre-positioned in advance of application-specific demands. In other words, the computed capacity (application instances) is made available, in advance of application-specific demands at a set co-located edge servers of an edge server region. With this approach, data associated with an application instance is migrated to be close to the instance, to facilitate compute-at-the-edge services, which requires data (state) to be close to the pre-positioned application instance, in order to address low latency sensitive application instances. Overlay network (or content delivery network” [Wingdings font/0xF3]CDN, see Fig. 3-4/Fig. 6) is used for long-term positioning, whereas, short-duration scheduling is done with the deployment of edge serves as needed. Moreover, the compute infrastructure or edge components are comprised of Mobile Edge Computing (MEC) elements, configured at locations within a cellular network itself, e.g., at a base station, and the MEC is a network architecture concept that enables cloud computing capabilities at the edge of the cellular network or at the edge of any network. The aforesaid mechanism as disclosed is deployed for content delivery and application acceleration using overlay (e.g., content delivery network (CDN)) edge networks < See Fig. 3-4/Fig. 6>. See at least in abstract along with at least in ¶0002-¶0005/¶0037-¶0041 along with at least Fig. 3-4 & Fig. 6 of the instant application.
Similarly, the primary reference, Subramaniam (2019/0335320) discloses a mechanism that ensures mobile MEC (Multi-access edge computing) applications continue throughout various networks, ensuring that a mobile device continues to operate the MEC application without impact, such as delay or interruption of delivery, in particular to delay/latency sensitive MEC application, by transmitting a state of the MEC application and associated data (similar concepts as disclosed by the instant application, at least in ¶0005) to those MEC platforms located adjacently to where the device is residing. In fact, in a MEC architecture, computing and storage resources are placed in closer proximity to the mobile devices they service, and executing applications and performing related processing tasks closer to the mobile device, in turns, ensures that network congestion is reduced and applications are able to perform more efficiently, in particular to delay/latency sensitive MEC application. For example, when mobile devices roam from its home network to other communication providers' networks, subscriber data and associated application information are also moved from the home network to the other providers' networks, which would create problems for those highly mobile applications, such as an autonomous vehicle that by its nature moves from network to network. In this situation, the application and subscriber data are moved from the home network MEC platform to the partner provider's MEC platform. The move of the subscriber data and associated applications increases the latency as the application state may be rebuilt again at the new MEC platform. To mitigate the increased latency issue, Subramaniam’s disclosure discloses a mechanism that ensures mobile MEC (Multi-access edge computing) applications continue throughout various networks, by synchronizing a state of the MEC application across multiple MEC platforms both inside and outside of the home network, the synchronization of the state of the MEC application, is done by transmitting a state of the MEC application and associated data (similar concepts as disclosed by the instant application, at least in ¶0005) to those MEC platforms located adjacently to where the device is residing, the associated data (similar concepts as disclosed by the instant application, at least in ¶0005) is transmitted to those MEC platforms that are located adjacently to the MEC platform at which the device is located, which creates a much more efficient mechanism such that the MEC application continues operation even when the device is roaming in partner network, enables the device to continue operation of the MEC application with minimal delay and interruption. See ¶0012-¶0013/¶0017-¶0020/¶0036/¶0039/¶0041 along with Fig.1-4, quite a contrast to applicant’s arguments at least at pages 2-6 of remarks as submitted on 06/02/2026.
Also, please see the following snapshot of Fig.1 as reproduced next, which is in connection with the aforesaid disclosure by Subramaniam (2019/0335320).
PNG
media_image4.png
554
827
media_image4.png
Greyscale
Second, Similar to the alleged remarks towards the primary reference, the applicant further asserts that the secondary reference, (Tofighbakhsh [Wingdings font/0xF3] 2020/0177671) doesn’t have anything towards migrating actual compute functionality. Examiner respectfully disagrees with the applicant. As mentioned supra, the applicant attempts to read more meaning into the claim limitations than is reasonable. For example, Tofighbakhsh discloses a mechanism of a global IoT services, comprising collaborative edge gateways, enhanced by logically extending cellular networks with roaming partners to manage the globally deployed edge IoT gateways. The distributed edge IoT gateway nodes (See Fig. 1-2) can interact with both a software-defined networking (SDN)-like control plane and a mesh formation of the distributed edge IoT gateway nodes (See Fig. 1-2), to collectively provide opportunity for global workload management and interaction. The distributed edge IoT gateway nodes (which are mobile network operator (MNO)-certified IoT gateways as shown in Fig. 1-2) can communicate with IoT clients (See Fig. 1-2), by moving IoT client devices installed in trucks, airplanes, containers, drones, and/or other shipping elements. The distributed edge IoT gateway nodes (MNO- certified IoT gateways as shown in Fig. 1-2) form a structured mesh network globally over the Internet that can communicate asynchronously and/or synchronously. For example, the distributed IoT gateway nodes (MNO- certified IoT gateways as shown in Fig. 1-2) can implement advanced collaborative and/or distributed technologies (e.g., Blockchain) to track/monitor QoS and SLA globally, such as, a metadata (e.g., token) that represents workload state (e.g., summary of tasks performed, verified parameters, estimated time of arrival at next location, expected state at next location, etc.) can be transferred from one IoT gateway node to another. Collectively these states can be analyzed (e.g., by the master IoT orchestration component, as shown in Fig. 1-2) to determine expected and unexpected scenarios, and accordingly, appropriate QoS and SLA service monitoring can be provided. For example, when a customer is shipping a shipment that is tracked by sensors inside the shipment from US city of Cupertino to city of Milan, Italy, the path for this shipment can be provided to the master IoT orchestration component (see Fig. 1-2) The master IoT orchestration component (see Fig. 1-2) can compile the path into the expected passages through the edge IoT gateway nodes (see Fig. 1-2) along the path and can schedule workloads into these nodes. The desired/expected scenarios are that the shipment states and sensor states are reported as the shipment moves through the nodal IoT gateway passages. Furthermore, the edge IoT controller (See Fig. 1-2) can define one or more policies for the initiation of workloads based on various parameters, for example, IoT arrival time, IoT measurement data, current time, historical preferences, etc. Typically, the edge IoT gateway node (see Fig. 1-2) can initiate different workloads in response to detecting expected scenarios or detecting anomalies. For example, if determined that the IoT device (see Fig. 1-2) arrives at the expected time, a first set of actions can be performed; if determined that the IoT device (see Fig. 1-2) arrives before the expected time, a second set of actions can be performed; and if determined that the IoT device (see Fig. 1-2) arrives after the expected time, a third set of actions can be performed.
In other words, a plurality of actions is performed by the edge IoT controller by determining/computing/analyzing state data (e.g., IoT arrival time, IoT measurement data, timing data associated with arrival and/or departure of IoT device, workload QoS and/or SLA measurements), in collaboration with tracking component ( which provides feedback in assisting the determination of a state data associated with the workload <e.g., summary of actions performed, anomalies detected, etc.> and report the state data to the edge IoT controller, see Fig. 1-7), which transfers status/state data to edge IoT gateway nodes via a structured mesh network (e.g., through LTE networks and/or Internet).
In summary, in response to detecting expected/unexpected scenarios/anomalies by the distributed IoT gateway nodes, the edge IoT controller (see Fig. 1-2) determines/computes/analyzes from a plurality of actions (as disclosed supra) by taking feedback from tracking components associated with the distributed IoT gateway nodes (see Fig. 1-5), the feedback contains transfers status/state data (e.g., IoT arrival time, IoT measurement data, timing data associated with arrival and/or departure of IoT device, workload QoS and/or SLA measurements) to edge IoT gateway nodes via a structured mesh network (e.g., through LTE networks and/or Internet), in order to provide a secure monitoring and/or diagnostic capability for the global IoT services. See ¶0026/¶0030-¶0033/¶0037/¶0040/¶0041/¶0045/¶0051-¶0054 along with Fig. 1-7, quite contrary to applicant’s arguments at least at pages 6-8 of remarks as submitted on 06/02/2026.
Also, please see the following snapshot of Fig. 2 as reproduced next, which is in connection with the aforesaid disclosure by Tofighbakhsh [Wingdings font/0xF3] 2020/0177671.
PNG
media_image3.png
368
597
media_image3.png
Greyscale
Third, In reference to Subramaniam’s reference (i.e., Primary reference), applicant argues that Subramaniam merely teaches that a computing device ''may synchronize the state of the MEC application and associated data'' [0039] when a device roams outside of the home network. With due respect, the Examiner has equated - incorrectly - the transmission of an application's ''state'' and ''associated data'' with the actual migration of the ''compute functionality'' itself. The Examiner's overly broad interpretation of ''compute functionality'' here is directly contradicted by Subramaniam's own explicit definitions. See applicant’s arguments at least at page 4 of remarks as submitted on 06/02/2026.
Examiner respectfully disagrees with such an assertion as made by applicant. Examiner would like to refer to MPEP 2111.01, where it is recited, “an applicant is entitled to be their own lexicographer and may rebut the presumption that claim terms are to be given their ordinary and customary meaning by clearly setting forth a definition of the term that is different from its ordinary and customary meaning(s) in the specification at the time of filing. See In re Paulsen, 30 F.3d 1475, 1480, 31 USPQ2d 1671, 1674 (Fed. Cir. 1994) (holding that an inventor may define specific terms used to describe invention, but must do so "with reasonable clarity, deliberateness, and precision" and, if done, must "‘set out his uncommon definition in some manner within the patent disclosure’ so as to give one of ordinary skill in the art notice of the change" in meaning) (quoting Intellicall, Inc. v. Phonometrics, Inc., 952 F.2d 1384, 1387-88, 21 USPQ2d 1383, 1386 (Fed. Cir. 1992) “. Under a broadest reasonable interpretation (BRI), words of the claim must be given their plain meaning. See MPEP 2173.01. As mentioned earlier, the primary reference, Subramaniam (2019/0335320) discloses a mechanism that ensures mobile MEC (Multi-access edge computing) applications continue throughout various networks, ensuring that a mobile device continues to operate the MEC application without impact, such as delay or interruption of delivery, in particular to delay/latency sensitive MEC application, by transmitting a state of the MEC application and associated data (similar concepts as disclosed by the instant application, at least in ¶0005) to those MEC platforms located adjacently to where the device is residing. In fact, in a MEC architecture, computing and storage resources are placed in closer proximity to the mobile devices they service, and executing applications and performing related processing tasks closer to the mobile device, in turns, ensures that network congestion is reduced and applications are able to perform more efficiently, in particular to delay/latency sensitive MEC application. For example, when mobile devices roam from its home network to other communication providers' networks, subscriber data and associated application information are also moved from the home network to the other providers' networks, which would create problems for those highly mobile applications, such as an autonomous vehicle that by its nature moves from network to network. In this situation, the application and subscriber data are moved from the home network MEC platform to the partner provider's MEC platform. The move of the subscriber data and associated applications increases the latency as the application state may be rebuilt again at the new MEC platform. To mitigate the increased latency issue, Subramaniam’s disclosure discloses a mechanism that ensures mobile MEC (Multi-access edge computing) applications continue throughout various networks, by synchronizing a state of the MEC application across multiple MEC platforms both inside and outside of the home network, the synchronization of the state of the MEC application, is done by transmitting a state of the MEC application and associated data (similar concepts as disclosed by the instant application, at least in ¶0005) to those MEC platforms located adjacently to where the device is residing, the associated data (similar concepts as disclosed by the instant application, at least in ¶0005) is transmitted to those MEC platforms that are located adjacently to the MEC platform at which the device is located, which creates a much more efficient mechanism such that the MEC application continues operation even when the device is roaming in partner network, enables the device to continue operation of the MEC application with minimal delay and interruption. See ¶0012-¶0013/¶0017-¶0020/¶0036/¶0039/¶0041 along with Fig.1-4, quite a contrast to applicant’s arguments at least at page 4 of remarks as submitted on 06/02/2026.
Fourth, In reference to Tofighbakhsh’s reference (i.e., Secondary reference), applicant argues that there is no notion in the Tofighbakhsh reference of migrating actual compute functionality. In this regard, the notion of ''scheduling a workload'' is not ''migrating compute functionality.". See applicant’s arguments at least at page 7 of remarks as submitted on 06/02/2026.
Examiner respectfully disagrees with such an assertion as made by applicant. Examiner would like to refer to MPEP 2111.01, where it is recited, “an applicant is entitled to be their own lexicographer and may rebut the presumption that claim terms are to be given their ordinary and customary meaning by clearly setting forth a definition of the term that is different from its ordinary and customary meaning(s) in the specification at the time of filing. See In re Paulsen, 30 F.3d 1475, 1480, 31 USPQ2d 1671, 1674 (Fed. Cir. 1994) (holding that an inventor may define specific terms used to describe invention, but must do so "with reasonable clarity, deliberateness, and precision" and, if done, must "‘set out his uncommon definition in some manner within the patent disclosure’ so as to give one of ordinary skill in the art notice of the change" in meaning) (quoting Intellicall, Inc. v. Phonometrics, Inc., 952 F.2d 1384, 1387-88, 21 USPQ2d 1383, 1386 (Fed. Cir. 1992) “. Under a broadest reasonable interpretation (BRI), words of the claim must be given their plain meaning. See MPEP 2173.01. As mentioned earlier, the Secondary reference, Tofighbakhsh (2020/0177671) discloses a mechanism of a global IoT services, comprising collaborative edge gateways, enhanced by logically extending cellular networks with roaming partners to manage the globally deployed edge IoT gateways. The distributed edge IoT gateway nodes (See Fig. 1-2) can interact with both a software-defined networking (SDN)-like control plane and a mesh formation of the distributed edge IoT gateway nodes (See Fig. 1-2), to collectively provide opportunity for global workload management and interaction. The distributed edge IoT gateway nodes (which are mobile network operator (MNO)-certified IoT gateways as shown in Fig. 1-2) can communicate with IoT clients (See Fig. 1-2), by moving IoT client devices installed in trucks, airplanes, containers, drones, and/or other shipping elements. The distributed edge IoT gateway nodes (MNO- certified IoT gateways as shown in Fig. 1-2) form a structured mesh network globally over the Internet that can communicate asynchronously and/or synchronously. For example, the distributed IoT gateway nodes (MNO- certified IoT gateways as shown in Fig. 1-2) can implement advanced collaborative and/or distributed technologies (e.g., Blockchain) to track/monitor QoS and SLA globally, such as, a metadata (e.g., token) that represents workload state (e.g., summary of tasks performed, verified parameters, estimated time of arrival at next location, expected state at next location, etc.) can be transferred from one IoT gateway node to another. Collectively these states can be analyzed (e.g., by the master IoT orchestration component, as shown in Fig. 1-2) to determine expected and unexpected scenarios, and accordingly, appropriate QoS and SLA service monitoring can be provided. For example, when a customer is shipping a shipment that is tracked by sensors inside the shipment from US city of Cupertino to city of Milan, Italy, the path for this shipment can be provided to the master IoT orchestration component (see Fig. 1-2) The master IoT orchestration component (see Fig. 1-2) can compile the path into the expected passages through the edge IoT gateway nodes (see Fig. 1-2) along the path and can schedule workloads into these nodes. The desired/expected scenarios are that the shipment states and sensor states are reported as the shipment moves through the nodal IoT gateway passages. Furthermore, the edge IoT controller (See Fig. 1-2) can define one or more policies for the initiation of workloads based on various parameters, for example, IoT arrival time, IoT measurement data, current time, historical preferences, etc. Typically, the edge IoT gateway node (see Fig. 1-2) can initiate different workloads in response to detecting expected scenarios or detecting anomalies. For example, if determined that the IoT device (see Fig. 1-2) arrives at the expected time, a first set of actions can be performed; if determined that the IoT device (see Fig. 1-2) arrives before the expected time, a second set of actions can be performed; and if determined that the IoT device (see Fig. 1-2) arrives after the expected time, a third set of actions can be performed.
In other words, a plurality of actions is performed by the edge IoT controller by determining/computing/analyzing state data (e.g., IoT arrival time, IoT measurement data, timing data associated with arrival and/or departure of IoT device, workload QoS and/or SLA measurements), in collaboration with tracking component ( which provides feedback in assisting the determination of a state data associated with the workload <e.g., summary of actions performed, anomalies detected, etc.> and report the state data to the edge IoT controller, see Fig. 1-7), which transfers status/state data to edge IoT gateway nodes via a structured mesh network (e.g., through LTE networks and/or Internet).
In summary, in response to detecting expected/unexpected scenarios/anomalies by the distributed IoT gateway nodes, the edge IoT controller (see Fig. 1-2) determines/computes/analyzes from a plurality of actions (as disclosed supra) by taking feedback from tracking components associated with the distributed IoT gateway nodes (see Fig. 1-5), the feedback contains transfers status/state data (e.g., IoT arrival time, IoT measurement data, timing data associated with arrival and/or departure of IoT device, workload QoS and/or SLA measurements) to edge IoT gateway nodes via a structured mesh network (e.g., through LTE networks and/or Internet), in order to provide a secure monitoring and/or diagnostic capability for the global IoT services. See ¶0026/¶0030-¶0033/¶0037/¶0040/¶0041/¶0045/¶0051-¶0054 along with Fig. 1-7, quite contrary to applicant’s arguments at least at page 7 of remarks as submitted on 06/02/2026.
Fifth, applicant argues that the Examiner has not established the requisite skill in the art or how a person having such skill would find these differences to be obvious at the time of Applicant's invention here. As such, the Office has failed in its burden to establish that the subject matter as a whole in claim 16 is primafacie obvious. See applicant’s arguments at least at page 8 of remarks as submitted on 06/02/2026.
Examiner respectfully disagrees with such an assertion as made by applicant. In response of applicant’s argument that Tofighbakhsh’s reference would not be an obvious combination with the teachings of Subramaniam so as to suggest applicants' invention. The Examiner would like to point out the following statement as identified by court “It is not required that the prior art disclose or suggest the properties newly-discovered by an applicant in order for there to be a prima facie case of obviousness. See In re Dillon, 919 F.2d 688, 16 USPQ2d 1897, 1905 (Fed. Cir. 1990). Moreover, as long as some motivation or suggestion to combine the references is provided by the prior art taken as a whole, the law does not require that the references be combined for the reasons contemplated by the inventor. See In re Beattie, 974 F.2d 1309, 24 USPQ2d 1040 (Fed. Cir. 1992); In re Kronig, 539 F.2d 1300, 190 USPQ 425 (CCPA 1976) and In re Wilder, 429 F.2d 447, 166 USPQ 545 (CCPA 1970)”. In this case, the suggestion to combine the references, is provided by Tofighbakhsh to enable distributed IoT gateway nodes form a structured mesh network globally over Internet that can communicate asynchronously and/or synchronously so that the distributed IoT gateway nodes can implement advanced collaborative and/or distributed technologies (e.g., Blockchain) to track/monitor QoS and SLA (service level agreement) globally in the wireless network. (¶0030, Tofighbakhsh)
Sixth, applicant argues that neither Subramaniam nor Tofighbakhsh migrates any ''compute functionality," for claim 18, so the notion that they the recited ''constraint'' involves ''a given number of instances of the compute functionality'' that are to be migrated, or that any decision ''where to migrate the compute functionality'' actually occurs are likewise incorrect. See applicant’s arguments at least at page 8 of remarks as submitted on 06/02/2026.
Examiner respectfully disagrees with such an assertion as made by applicant. Examiner would like to refer to MPEP 2111.01, where it is recited, “an applicant is entitled to be their own lexicographer and may rebut the presumption that claim terms are to be given their ordinary and customary meaning by clearly setting forth a definition of the term that is different from its ordinary and customary meaning(s) in the specification at the time of filing. See In re Paulsen, 30 F.3d 1475, 1480, 31 USPQ2d 1671, 1674 (Fed. Cir. 1994) (holding that an inventor may define specific terms used to describe invention, but must do so "with reasonable clarity, deliberateness, and precision" and, if done, must "‘set out his uncommon definition in some manner within the patent disclosure’ so as to give one of ordinary skill in the art notice of the change" in meaning) (quoting Intellicall, Inc. v. Phonometrics, Inc., 952 F.2d 1384, 1387-88, 21 USPQ2d 1383, 1386 (Fed. Cir. 1992) “. Under a broadest reasonable interpretation (BRI), words of the claim must be given their plain meaning. See MPEP 2173.01. As mentioned supra, Subramaniam Subramaniam (2019/0335320) discloses a mechanism that ensures mobile MEC (Multi-access edge computing) applications continue throughout various networks, ensuring that a mobile device continues to operate the MEC application without impact, such as delay or interruption of delivery, in particular to delay/latency sensitive MEC application, by transmitting a state of the MEC application and associated data (similar concepts as disclosed by the instant application, at least in ¶0005) to those MEC platforms located adjacently to where the device is residing. In fact, in a MEC architecture, computing and storage resources are placed in closer proximity to the mobile devices they service, and executing applications and performing related processing tasks closer to the mobile device, in turns, ensures that network congestion is reduced and applications are able to perform more efficiently, in particular to delay/latency sensitive MEC application. For example, when mobile devices roam from its home network to other communication providers' networks, subscriber data and associated application information are also moved from the home network to the other providers' networks, which would create problems for those highly mobile applications, such as an autonomous vehicle that by its nature moves from network to network. In this situation, the application and subscriber data are moved from the home network MEC platform to the partner provider's MEC platform. The move of the subscriber data and associated applications increases the latency as the application state may be rebuilt again at the new MEC platform. To mitigate the increased latency issue, Subramaniam’s disclosure discloses a mechanism that ensures mobile MEC (Multi-access edge computing) applications continue throughout various networks, by synchronizing a state of the MEC application across multiple MEC platforms both inside and outside of the home network, the synchronization of the state of the MEC application, is done by transmitting a state of the MEC application and associated data (similar concepts as disclosed by the instant application, at least in ¶0005) to those MEC platforms located adjacently to where the device is residing, the associated data (similar concepts as disclosed by the instant application, at least in ¶0005) is transmitted to those MEC platforms that are located adjacently to the MEC platform at which the device is located, which creates a much more efficient mechanism such that the MEC application continues operation even when the device is roaming in partner network, enables the device to continue operation of the MEC application with minimal delay and interruption. See ¶0012-¶0013/¶0017-¶0020/¶0027/¶0032/¶0036/¶0039/¶0041 along with Fig.1-4. Also, see claim 12, which recites, “the different roaming manager, located on the different MEC platform, outside of the home network that: receives on a periodic basis, from the roaming manager within the home network, the state of the MEC application and associated data. ”, that is, a plurality of number of instances is computed as determined by a plurality number of roaming managers at different MEC platform(s), outside of home network to transmit state of the MEC application and associated data (as triggered in a plurality of roaming scenarios disclosed supra) to other MEC platform(s) as disclosed supra, contrary to applicant’s arguments at least at page 8 of remarks as submitted on 06/02/2026.
Similar arguments are applicable for dependent claims 19-20.
For these reasons, it is maintained that independent claim 16 is are rejected under 35 U.S.C. 103 as being unpatentable over Subramaniam, in view of Tofighbakhsh.
As all other dependent claims depend either directly or indirectly from the independent claim 16, similar rationale also applies to all respective dependent claims.
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 MOHAMMED SHAMSUL CHOWDHURY whose telephone number is (571)272-0485. The examiner can normally be reached on Monday-Thursday 9 AM- 6 PM EST (Friday Var.).
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, Hassan Phillips can be reached on 571-272-3940. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MOHAMMED S CHOWDHURY/Primary Examiner, Art Unit 2467
