DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 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.”).
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 09/25/2025 have been fully considered but they are not persuasive.
Regarding remarks in pages 1-5 as submitted for pre-appeal brief (Pre-Appeal Brief Conference Request) in reference to independent claim 16, the instant office action does NOT refer to Li reference (2020/0136978 [Wingdings font/0xF3] an old reference), hence, moot.
There exists NO specific arguments to any other prior arts, hence, moot.
Conclusion
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