DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
This communication is considered fully responsive to the Arguments/Remarks filed on 5/5/2026.
Claims 1, 10, 11, 12, 17, 18 and 19 have been amended.
Claims 1 and 10 objections have been withdrawn as they have been amended.
Double patenting rejections for claims 1-20 still stands until a terminal disclaimer is filed.
Response to Arguments
Applicant's arguments filed 5/5/2026 have been fully considered but they are not persuasive.
Applicant argued in its Remarks for claims 1, 10 and 17, in pages 9-10 that Banka's probe generation is driven by network topology analysis performed by the system itself, not by customer-submitted probe templates containing programmable parameters specifying probe collectors, ML models, and northbound applications. …While Banka describes probe definitions and configurations, these are generated by the probe generator service based on topology analysis, not received from a customer as a probe template with the specific programmable parameters recited in claims 1, 10, and 17.
Examiner respectfully disagrees. The cited portions of Banka include par. 0058 which states “Subscriber devices 16 may be configured to utilize the services provided by one or more of applications 30 hosted on servers that are part of cloud-based services 26… A subscriber device 16 can utilize the services of an application 30 by communicating requests to the application 30 and receiving responses from the application 30 via public network 12”, par. 0060 which states “Probe modules may be implemented as plugin modules provided as part of a cloud as a Software-as-a-Service (SaaS) solution, software deployed on premises in NFV environments, software modules installed to host computing devices, or other implementations”, par. 0064 states “Probe services 201 include services that create, configure, and/or control probe modules that collect network telemetry data (e.g., probe modules 19 of FIG. 1) and par. 0076 states “Probe configuration service 204 can receive a probe definition and is responsible for translating the desired probe intent (as expressed in the probe definition) to a specific probe configuration based on the actual probe service. This is clearly the same feature as the claimed feature of receiving, from a customer, a request for a probe-as-a-service in the cellular network, the probe template comprising a plurality of programmable parameters”. Therefore, examiner maintains the rejections on all independent claims.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of co-pending Application No. 18/542,478. Although the claims at issue are not identical, they are not patentably distinct from each other because at least the method claims 14-20 of the copending application 18/542,478 are broader versions of the instant application claims as seen in the comparison table below.
Instant Application 18/542,469
Co-pending Application 18/542,478
1. A method of operating a probe controller that provides a probe-as-a-service in a cellular network, the method comprising: receiving, from a customer, a request for a probe-as-a-service in the cellular network, the request comprising a probe template associated with the probe-as-a-service, the probe template comprising a plurality of programmable parameters, wherein a first parameter of the plurality of programmable parameters specifies a set of one or more probe collectors, wherein a second parameter of the plurality of programmable parameters specifies a machine learning (ML) model, wherein a third parameter of the plurality of programmable parameters specifies a northbound application; collecting, using the set of probe collectors, input data from a plurality of probe agents programmed by the set of probe collectors, each probe agent located at at least one of an infrastructure resource of the cellular network, a sensor associated with the cellular network, or a user equipment (UE) connected to the cellular network; generating, using the ML model, observation data based on the input data, wherein the observation data comprises at least one of a key performance indicator (KPI) or a state of the at least one of the infrastructure resource, the sensor, or the UE; and providing the observation data to the northbound application.
14. A method of operating a probe controller that provides a probe-as-a-service in a cellular network, the method comprising: receiving, from a customer, a request for a probe-as-a-service in a cellular network having network resources; collecting, using a set of probe collectors, input data from each of a plurality of data sources in the cellular network, wherein the input data comprises at least one of location information or behavior information correlated to the network resources; generating, using at least one artificial intelligence (AI)/machine learning (ML) model, observation data based on the input data; and providing the observation data to a northbound application associated with the customer.
18. The method of claim 14, wherein at least one of the plurality of data sources comprises a probe agent programmed by a respective one of the set of probe collectors.
4. The method of claim 1, wherein the infrastructure resource is at least one of a dedicated transport resource, a dedicated radio frequency (RF) resource instance, customer radio access network (RAN) data, a transport slice pipeline, secure signaling session data, a Radio Unit (RU), a radio access network (RAN) resource, or another service in the cellular network.
5. The method of claim 1, wherein collecting the input data comprises: collecting, using a first probe collector of the set of probe collectors, first data from a first probe agent of the plurality of probe agents; and collecting, using a second probe collector of the set of probe collectors, second data from a second probe agent of the plurality of probe agents, and wherein the method further comprises aggregating the first data and the second data to obtain the input data.
17. The method of claim 14, wherein collecting the input data further comprises: collecting, using a first probe collector of the set of probe collectors, first data from a first network resource, wherein the first network resource is at least one of a dedicated transport resource, a dedicated radio frequency (RF) resource instance, customer radio access network (RAN) data, a transport pipeline, secure signaling session data, a Radio Unit (RU), a radio access network (RAN) resource, or another service in the cellular network; and collecting, using a second probe collector of the set of probe collectors, second data from a sensor located in an environment of the cellular network.
8. The method of claim 1, wherein the northbound application is or comprises at least one of a dashboard, a transfer function, an analytics application, or a second ML model.
19. The method of claim 14, wherein the northbound application is at least one of a dashboard, a transfer function, an analytics application, or a second AI/ML model.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 3-5, 7, 9, 10, 12-14 and 16, 17, 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Banka et al. (US 2025/0150327, hereinafter “Banka”) in view of Aktas et al. (US 2020/0067792, hereinafter “Aktas”).
For claims 1, 10 and 17, Banka discloses A method of operating a probe controller that provides a probe-as-a-service in a cellular network, the method comprising:
receiving, from a customer, a request (subscriber device 16 can utilize the services of an application 30 by communicating requests to the application 30 and receiving responses from the application 30 via public network 12; see Banka par. 0058, 0109) for a probe-as-a-service in the cellular network, the request comprising a probe template (Probe services 201 include services that create, configure, and/or control probe modules that collect network telemetry data (e.g., probe modules 19 of FIG. 1); see Banka par. 0064) associated with the probe-as-a-service (Probe modules may be implemented as plugin modules provided as part of a cloud as a Software-as-a-Service (SaaS) solution, software deployed on premises in NFV environments, software modules installed to host computing devices, or other implementations; see Banka par. 0060), the probe template comprising a plurality of programmable parameters (Probe configuration service 204 can receive a probe definition and is responsible for translating the desired probe intent (as expressed in the probe definition) to a specific probe configuration based on the actual probe service.. probe configuration service 204 includes probe compiler plugins 2122A- 2122N and probe configuration plugins 2124A-2124N. A probe compiler plugin 2122 receives a probe definition, and compiles the probe definition into a probe configuration for a particular type of probe module; see Banka par. 0076-0078), wherein a first parameter of the plurality of programmable parameters specifies a set of one or more probe collectors (telemetry services 207 includes services that collect telemetry from probe modules across multiple layers of networked system such as system 2 of FIG. 1… telemetry services 207 include telemetry collector 216, network telemetry collector 212, and device/fabric telemetry collector 214; see Banka par. 0083-0086), wherein a second parameter of the plurality of programmable parameters specifies a machine learning (ML) model (Anomaly detector 236 can apply machine learning (ML) model 240 to time series of telemetry data from TSDB 238 to determine anomalous conditions related to the time series of telemetry data. In some aspects, ML model 240 can be trained using supervised or unsupervised learning techniques to discover relationships between KPIs in telemetry data and anomalous conditions within one or more layers of a multi-layered network system such as system 2 of FIG. 1; see Banka par. 0088, 0092, 0226);
collecting, using the set of probe collectors, input data from a plurality of probe agents programmed by the set of probe collectors (Network telemetry collector 212 can collect telemetry data that measure end-to-end network performance. For example, network telemetry collector 212 can collect network performance measurements obtained or created by probe modules 19. Device/fabric telemetry collector 214 can collect telemetry data from network devices in a network fabric of network system 2; see Banka par. 0085-0086), each probe agent located at at least one of an infrastructure resource of the cellular network (Application location service 2118 can use a knowledge graph of the system that represents all the application and corresponding infrastructure components as a graph data structure…Probe generator service 202 is responsible for determining a set of network probe modules that need to be configured for a given network which is determined based on the network topology and corresponding application placement in the network..; see Banka par. 0068), a sensor associated with the cellular network (computing devices within network system 2 may provide network monitoring services. For example, network devices 18 and/or compute nodes 10 are configured as measurement points (e.g., with probe modules) to provide network monitoring services to determine, for example, network performance and functionality, as well as interconnections of service chains3; see Banka par. 0060), or a user equipment (UE) connected to the cellular network (subscriber device 16 may be a variety of network enabled devices, referred generally to as "Internet-of-Things" (IoT) devices, such as cameras, sensors (S), televisions, appliances, etc. In addition, subscriber devices 16 may comprise mobile devices that access the data services of network system 2 via a radio access network (RAN) 4; see Banka par. 0049);
generating, using the ML model, observation data based on the input data (Data from different probe collectors may arrive in different formats. As a result, input data in an input format are transformed to a standard telemetry format by a corresponding data transformer plugin… probe telemetry data across a group of ToR switches is combined to generate a ToR group baseline from network perspective such as latency 95 percentile, loss 95 percentile, delay variation. Anomaly detection 2316 uses machine learning and rule based approaches to determine any anomalous behavior in the KPIs determined in the data aggregation layer 2314 of the pipeline; see Banka par. 0090-0092), wherein the observation data comprises at least one of a key performance indicator (KPI) or a state of the at least one of the infrastructure resource, the sensor, or the UE (ML model 241 can be trained using supervised or unsupervised learning techniques to discover relationships between KPIs in telemetry data and anomalous conditions within one or more layers of a multi-layered network system such as system 2 of FIG. 1. These relationships can be across multiple layers of the network model. For example, KPIs that are associated with a network device can be related to KPIs of an application that utilizes the network device to communicate with another service; see Banka par. 0102); and
Banka does not explicitly disclose wherein a third parameter of the plurality of programmable parameters specifies a northbound application. Providing the observation data to the northbound application. Aktas. Aktas discloses wherein a third parameter of the plurality of programmable parameters specifies a northbound application. Providing the observation data to the northbound application (Probes 310 feed KPIs and counter values to Network Monitoring Function 350 via links 367. SDN control plane 377 is also illustrated with one or more controllers 207 and one or more control applications 287. TSF 400 receives KPI violations from Network Monitoring Function 350 on interface 422, which is a simple API such as the REST APL. TSF 400 receives routing tables and network map from Controller 207 on interface 423, which is the 'Northbound' API provided by the Controller. This is the same API that all controller Applications 287 uses; see Aktas par. 0055-0057). It would have been obvious to the ordinary skilled in the art before the effective filing date to use Aktas's arrangement in Banka's invention to monitor for the health of traffic flows directly from the data plane (see Aktas par. 0001).
Specifically for claim 10, Banka discloses A computing system to facilitate a cellular network, the computing system comprising:
one or more processing devices; and
memory communicatively coupled with and readable by the one or more processing devices and having stored therein processor-readable instructions which, when executed by the one or more processing devices, cause the one or more processing devices to perform operations (computing system comprising: a memory configured to store a time series data comprising measurements of one or more performance indicators; and processing circuitry configured to execute an analysis framework system; see Banka par. 0238).
Specifically for claim 17, Banka discloses One or more non-transitory, computer-readable storage media having computer-readable instructions thereon which, when executed by one or more processing devices, cause the one or more processing devices to perform operations (A non-transitory computer-readable storage medium having instructions stored thereon that, when executed, cause one or more processors to execute a framework analysis system, wherein the framework analysis system is configured to; see Banka par. 0247).
For claims 3, 12 and 19, Banka discloses The method of claim 1, wherein the set of probe collectors comprises at least one of a device-level collector, a radio access network level (RAN-level) collector, a core-level collector, a transport-level collector, a cloud-level collector, or an enterprise application collector (telemetry services 207 include telemetry collector 216, network telemetry collector 212, and device/fabric telemetry collector 214. Telemetry collector 216 can collect application telemetry 208 such as application performance data. Application telemetry may be collected using service-mesh, Istio, etc. Telemetry collector 216 can also collect compute/pod telemetry 210. Compute/pod telemetry 210 can include Kubernetes pod and node performance telemetry data such as central processor unit (CPU) usage, memory usage, network statistics, etc. In some aspects, telemetry collector 212 can be implemented using the Prometheus monitoring system combined with the Thanos high availability and data storage systems. Both Prometheus and Thanos are open source components. Network telemetry collector 212 can collect telemetry data that measure end-to-end network performance. For example, network telemetry collector 212 can collect network performance measurements obtained or created by probe modules 19. Device/fabric telemetry collector 214 can collect telemetry data from network devices in a network fabric of network system 2 (e.g., network devices 18).
For claims 4, 13 and 20, Banka discloses The method of claim 1, wherein the infrastructure resource is at least one of a dedicated transport resource, a dedicated radio frequency (RF) resource instance (Telemetry services 207 includes services that collect telemetry from probe modules across multiple layers of networked system such as system 2 of FIG. 1. As used herein, a layer can refer to a set of components (real or virtual) that use resources and services provided by another set of components at a different layer. In cases where a first component uses resources or services of a second component, the first component can be said to be dependent on the second component. For example, applications at an application layer may use resources and services of a compute node at a compute node layer. The compute node layer may, in tum, use resources and services provided by network devices at a network layer, and so on. Thus, applications at the application layer are dependent on compute nodes at a compute node layer, which in tum, may be dependent on physical network devices (e.g., compute nodes 10 shown in the example of FIG. 1 at the network physical layer; see Banka par. 0096), customer radio access network (RAN) data, a transport slice pipeline, secure signaling session data, a Radio Unit (RU), a radio access network (RAN) resource, or another service in the cellular network (Knowledge graph generator 220 can generate, based on data in TSDB 238 and relationships discovered in ML model 241, dependencies between different application and infrastructure entities of network system 2. Causal graph generator 222 generates further graph data on top of a knowledge graph generated by knowledge graph generator 220 to form a causal graph. The causal graph captures causal relationships between different performance KPIs and anomalous conditions; see Banka par. 0104; a root cause can be determined for all service level anomalies observed in the causality graph. In the second mode, a personalized PageRank algorithm can be used that is focused on performing root cause analysis on a selected set of services or infrastructure components; see Banka par. 0215).
For claims 5 and 14, Banka discloses The method of claim 1, wherein collecting the input data comprises:
collecting, using a first probe collector of the set of probe collectors, first data from a first probe agent of the plurality of probe agents; and collecting, using a second probe collector of the set of probe collectors, second data from a second probe agent of the plurality of probe agents, and wherein the method further comprises aggregating the first data and the second data to obtain the input data (Data from different probe collectors may arrive in different formats. As a result, input data in an input format are transformed to a standard telemetry format by a corresponding data transformer plugin. For example, Netrounds transformer 2308 is used to transform the raw data collected by Netrounds collector 2302. Similarly, custom transformers 2310 and 2312 are used to transform probe data collected by custom probe collectors 2304 and 2306 respectively. Data Aggregation 2314 is a stage of the pipeline responsible for aggregating probe module data at different granularity. For example, data aggregation 2314 may aggregate probe telemetry data at per compute node, which aggregates probe telemetry data for all probe modules configured on a given computer node. Similarly, probe telemetry data across all servers under a Top-of-Rack (ToR) switch are aggregated to provide a health of the network from ToR perspective. At higher granularity, probe telemetry data across a group of ToR switches is combined to generate a ToR group baseline from network perspective such as latency 95 percentile, loss 95 percentile, delay variation.; see Banka par. 0090-0091).
For claim 7, Banka discloses The method of claim 5, wherein:
collecting the input data further comprises: collecting, using the first probe collector, third data from a third probe agent of the plurality of probe agents; collecting the second data comprises aggregating the second data and the third data to obtain combined collected data; and the method further comprises aggregating the first data and the combined collected data to obtain the input data (Data from different probe collectors may arrive in different formats. As a result, input data in an input format are transformed to a standard telemetry format by a corresponding data transformer plugin. For example, Netrounds transformer 2308 is used to transform the raw data collected by Netrounds collector 2302. Similarly, custom transformers 2310 and 2312 are used to transform probe data collected by custom probe collectors 2304 and 2306 respectively. Data Aggregation 2314 is a stage of the pipeline responsible for aggregating probe module data at different granularity. For example, data aggregation 2314 may aggregate probe telemetry data at per compute node, which aggregates probe telemetry data for all probe modules configured on a given computer node. Similarly, probe telemetry data across all servers under a Top-of-Rack (ToR) switch are aggregated to provide a health of the network from ToR perspective. At higher granularity, probe telemetry data across a group of ToR switches is combined to generate a ToR group baseline from network perspective such as latency 95 percentile, loss 95 percentile, delay variation.; see Banka par. 0090-0091).
For claims 9 and 16, Banka does not explicitly disclose The method of claim 1, wherein the probe template is received via a Northbound Application Programming Interface (Northbound API), wherein the input data is received via a plurality of APIs, each API being associated with the respective probe agent, wherein the input data comprises at least one of counters, logs, events, metrics, traces, alarms, configuration data, flow data, state information, or error messages. Aktas discloses The method of claim 1, wherein the probe template is received via a Northbound Application Programming Interface (Northbound API), wherein the input data is received via a plurality of APIs (Probes 310 feed KPIs and counter values to Network Monitoring Function 350 via links 367. SDN control plane 377 is also illustrated with one or more controllers 207 and one or more control applications 287. TSF 400 receives KPI violations from Network Monitoring Function 350 on interface 422, which is a simple API such as the REST APL TSF 400 receives routing tables and network map from Controller 207 on interface 423, which is the 'Northbound' API provided by the Controller. This is the same API that all controller Applications 287 uses; see Aktas par. 0055-0057), each API being associated with the respective probe agent, wherein the input data comprises at least one of counters, logs, events, metrics, traces, alarms, configuration data, flow data, state information, or error messages (Probes construct Key Performance Indicator (KPIs) and counter values after interpreting packets. Protocol probes interpret only decoded protocol messages such as INAP, TCAP, SIP received from the underlying protocol layer. Probes can send the KPIs and counter values to a special performance-monitoring server (referred as the Monitoring Function) that can receive KPIs from many probes, and process and display the results in graphical or tabular form for the network administrator. KPIs signify packet latency, packet loss, errors, and throughput; see Aktas par. 0046. It would have been obvious to the ordinary skilled in the art before the effective filing date to use Aktas's arrangement in Banka's invention to monitor for the health of traffic flows directly from the data plane (see Aktas par. 0001).
Claim(s) 6 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Banka and Aktas, and further in view of Bures et al. (US 2020/0322703, hereinafter “Bures”).
For claims 6 and 15, the combination of Banka and Aktas does not explicitly disclose The method of claim 5, wherein the first data is collected at a first rate, and wherein the second data is collected at a second rate different than the first rate. Bures discloses The method of claim 5, wherein the first data is collected at a first rate, and wherein the second data is collected at a second rate different than the first rate (The current mode of operation can indicate a frequency of data collection by each of the sensor devices 1-W. This can indicate a rate for collection of measurements by each sensor device, and/or amount of time between measurements collected by each sensor device. For example, the current mode of operation and/or sensor control data generated by the sensor control module 241 can dictate that a first one of the set of sensor devices collect measurements at a first measurement rate, and can dictate that a second one of the set of sensor devices collect measurements at a second measurement rate that is different from the first measurement rate. The collection rates of different sensor devices can be proportional to, and/or an increasing function of, the sensor devices weights dictating pnont1es of the sensor devices and/or different types data collected by the sensor devices, where higher priority sensor devices collect data at a higher rate than lower priority devices. An update to an updated mode of operation can cause a change in the measurement rate some or all of the sensor devices 1-W, for example, where the measurement rate of the first one of the set of sensor devices is increased or decreased…; see Bures par. 0043-0044, 0051-0052, 0080, 0082-0084). It would have been obvious to the ordinary skilled in the art before the effective filing date to use Bures's arrangement in Banka's invention to minimize and/or avoid collisions amongst the different multi-sensor units in facilitating synchronized or asynchronous scheduling of packet transmission by the different multi-sensor units (see Bures par. 0191).
Claim(s) 8 is rejected under 35 U.S.C. 103 as being unpatentable over Banka and Aktas, and further in view of Pateromichelakis et al. (US 2025/0047566, hereinafter “Pateromichelakis”).
For claim 8, the combination of Banka and Aktas does not explicitly disclose The method of claim 1, wherein the northbound application is or comprises at least one of a dashboard, a transfer function, an analytics application, or a second ML model. Pateromichelakis discloses The method of claim 1, wherein the northbound application is or comprises at least one of a dashboard, a transfer function, an analytics application, or a second ML model (stats and/or predictions may be supported and/or enhanced by collecting data from different domains based on a consumer needs. The collection may be from the 5GS via northbound application programming interfaces ("APIs") (e.g., NWDAF, management domain analytics service ("MDAS")), or from an application specific layer and/or DN ( e.g., data may be related to collecting high definition ("HD") maps, camera feeds, sensor data, data related to edge Al and/or cloud resources, data related to application server status ( e.g., load of edge application server ("EAS") and/or application server ("AS")), or data from the UE side (e.g., UE routes and/or trajectories); see Pateromichelakis par. 0056, 0067, 0069, 0051). It would have been obvious to the ordinary skilled in the art before the effective filing date to use Pateromichelakis 's arrangement in Banka's invention to combine and/or aggregate data of segments of an end to end path and the outcome may be an abstracted, correlated, and/or filtered set of data (see Pateromichelakis par. 0102).
Allowable Subject Matter
Claims 2, 11 and 18 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is an examiner’s statement of reasons for allowance: claims 2, 11 and 18 would be allowable because the closest prior arts listed above either alone or in combination, fail to anticipate or render obvious, the claimed invention of “wherein the probe template comprises probe policies, wherein the set of probe collectors programs each of the plurality of probe agents according to the probe policies”, in combination with all other limitations in the claim(s) above as defined by applicant.
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 CHAE S LEE whose telephone number is (571)272-8236. The examiner can normally be reached 8:30AM - 5:00PM.
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, Jeffrey Rutkowski can be reached at (571) 270-1215. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/CHAE S LEE/Primary Examiner, Art Unit 2415
Prosecution Insights