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 Arguments
Applicant's arguments filed 8/17/26 have been fully considered but they are not persuasive.
Claim 1:
The applicant argues “They are not statistics concerning traffic that has
passed through the transmitting device, and they are not organized or reported according to any "statistics data model for statistics data" as recited by claim 1. Naik's transmission is a distribution of a model to a peer device; claim 1 requires a reporting of measured traffic statistics to a computing device…None of them describes transmitting traffic statistics data to a separate computing device based on a statistics data model, as required by claim 1.” See applicant’s remarks, pages 10-11. The examiner respectfully disagrees.
Naik discloses a first device may receive signaling associated with a traffic class from a second device. The first device may determine that the traffic class is included in a set of known traffic classes based on a set of features associated with the signaling. In response to determining that the traffic class is included in the set of known traffic classes, the first device may use a machine learning model to obtain a prediction of an application associated with the signaling. See abstract. According to Naik, device 205-a sends to device 205-b how traffic flow may be prioritized based on detected traffic types, QoS classes and other collected traffic statistics as described in paragraphs [0125] and [0126]. Therefore, it is clear that Naik teaches reporting of measured traffic statistics to a computing device and transmitting traffic statistics data to a separate computing device based on a statistics data model as required in the claims.
The applicant argues “…Claim 1 recites a single access device that performs all three recited operations - it transmits the traffic statistics data to the computing device, it receives the traffic configuration information back from that same computing device, and it then configures the traffic. The mapping presented in the Office Action cannot be reconciled with that requirement: device 205-a is the transmitter and device 205-c is the recipient, so no single device in the cited passages performs both the "transmit, to a computing device" step and the "receive, from the computing device" step of claim 1. Nor is the difficulty cured by re-designating device 205-c as the access device, because device 205-c is not shown transmitting traffic statistics data at all…” See applicant’s remarks, page 11. The examiner respectfully disagrees.
Naik discloses the device 205-a (e.g., an AP) may send a signal to a STA (e.g., the device 205-b) to indicate, to the STA, how the traffic flow may be prioritized (e.g., for an access category)… the device 205-a may send the IP-tuple to one or more QoS characteristic element parameters to the device 205-b to improve uplink scheduling at the device 205-b. In other words, the device 205-a may output signal to the device 205-b that indicates one or more parameters associated with the QoS class, such that the device 205-b may use the one or more parameters for prioritization of uplink data traffic to the device 205-a (or another device) (in other words, the access device/device 205-a transmits traffic statistics to the computing device/device 205-b). See paragraph [0126]. Naik further discloses for instance, in examples in which a traffic type is detected for the traffic associated with the signaling 210-a, the device 205-a may map the traffic (e.g., such a flow) to a QoS class (e.g., a particular QoS class) for a Wi-Fi operation, including scheduling with the collected traffic statistics. For example, the device 205-a may schedule Wi-Fi operations based on a delay associated with the detected traffic type. In some examples, to map the traffic, the device 205-a may map one or more parameters associated with the traffic (in other words, transmitting traffic statistics data based on statistics data model). The device 205-a collects traffic data and identifies traffic class based on machine learning model (in other words, statistics data model) as described in paragraph [0121]. See paragraph [0125].
Naik discloses the device 205-a may detect VoIP traffic associated with the signaling 210-a. In such an example, the device may prioritize the detected VoIP traffic and video traffic (e.g., detected or undetected video traffic) from the device 205-b according to a QoS class (in other words, configuration data model) associated with the VoIP traffic, such that the VoIP traffic and the video traffic may have a same priority (in other words, the VoIP traffic and video traffic is received by device 210-a/access device from device 205-b/computing device is considered as “traffic consideration information”). See paragraph [0127]. Paragraph [0126] of Naik teaches one or more parameters associated with the QoS class, such that the device 205-b may use the one or more parameters for prioritization of uplink data traffic to the device 205-a (or another device). Therefore, the QoS class is considered as “configuration data model” for traffic configuration where the “traffic configuration information” is the VoIP traffic and video traffic. The device 205-a collects traffic data and identifies traffic class based on machine learning model (in other words, statistics data model) as described in paragraph [0121]. In other words, Naik discloses the access device/device 205-a receiving the traffic configuration information (i.e., VoIP traffic and video traffic) from the computing device/device 205-b.
The applicant argues “Naik describes the opposite allocation of functions. In the
cited passage, the recipient device performs the classification locally: The device 205-c may use the machine learning model information 235 to obtain (e.g., build, construct, updated) the machine learning model for classifying traffic. For example, the device 205-c may identify a traffic class associated with the signaling 210-b. In such an example, the device 205-c (e.g., a non-AP STA, such as a client device) may perform one or more operations in accordance with the identified traffic class. [124] Nothing is returned to device 205-a as traffic configuration information; device 205-c simply applies its own locally identified traffic class.” See applicant’s remarks, page 12. The examiner respectfully disagrees.
As described above, traffic configuration information is returned to device 205-a/access device from device 205-b/computing device. Also, the examiner would like to point out that Naik discloses a first device (e.g., an AP 102, a STA 104) may receive signaling associated with a traffic class from a second device (e.g., another AP 102, another STA 104) as described in paragraph [0104]. Therefore, according to Naik, the stations/APs later described and shown in figure 2 can be used intertwined and/or either or.
The applicant argues “The sentence relied upon for the third step of claim 1 confirms this. Naik states that the device 205-a may determine to communicate with the device 205-a in accordance with (or based on) the identified traffic class [124]. Configuring communications in accordance with a traffic class identified by the device itself is not configuring traffic "based on the traffic configuration information" received from a computing device, as recited by claim 1. A locally derived classification label is not information generated by a remote computing device from transmitted traffic statistics data, and it is not delivered "based on at least one configuration data model for traffic configuration" as recited by claim 1. The claimed closed loop - statistics reported upward, AI/ML inference performed at the computing device, configuration information returned, and the traffic configured accordingly - is simply absent from Naik.” See applicant’s remarks, pages 12-13. The examiner respectfully disagrees.
Naik discloses the device 205-a may assign data packets (e.g., MAC service data units (MSDUs)) included in the traffic to a first access category. Accordingly, the data packets may be assigned to a first queue associated with the first access category (i.e., traffic configuration information). Additionally, the device 205-a may detect an changed prediction result (e.g., the result of the inference 220 or the supervised learning 225, or both) for the same traffic flow. In some examples, such as example in which the traffic detection result changes for a same flow (e.g., the traffic associated with the signaling 210-a), the device 205-a may move the MSDUs (e.g., all MSDUs) of the first queue (e.g., the queue that includes the data packets assigned to the first access category) to a second access category (e.g., associated with the second traffic class) (in other words, configuring traffic based on traffic configuration information) to reduce out of order delivery of the traffic associated with the signaling 210-a. See paragraph [0128]. Based on the traffic and class/category received, the device 205-a uses the learning model to configure, set up and//or arrange the traffic providing for an easy flow reducing out of order delivery of traffic. In other words, Naik discloses the access device/device 205-a configure the traffic based on the traffic configuration information as required in the claims.
Claim 13:
The applicant argues “…The Office Action identifies no passage of Naik in which any device processes traffic statistics data received from an access device in order to determine traffic configuration information, nor any passage in which such information is transmitted back to the access device…” See applicant’s remarks, page 13. The examiner respectfully disagrees for the same reasons as already presented above.
Claims 2 and 24:
The applicant argues “…Since Naik's prioritization proceeds from a locally obtained confidence level rather than from traffic configuration information received from a computing device, the antecedent limitation is not met and claims 2 and 24 are allowable at least for the reasons given for claims 1 and 13.” See applicant’s remarks, page 13. The examiner respectfully disagrees.
Naik discloses associating traffic types (such as, VoIP traffic and video traffic/traffic configuration information) with QoS classes for prioritizing traffic flow. See paragraph [0127]. Naik discloses the access device/device 205-a causes to configure the traffic by controlling QoS based on the traffic configuration information as required in the claims.
Claims 3 and 15:
The applicant argues “Paragraph [0101] of Naik, the sole basis cited, is a statement of general background concerning the IEEE 802.11 standards, namely that these standards define the WLAN radio and baseband protocols for the PHY and MAC layers. That the 802.11 standards define MAC-layer protocols says nothing whatever about "the at least one statistics data model and the at least one configuration data model" being "applied to at least one of a media access control (MAC) layer, an Internet protocol (IP) layer, or a transport layer" as recited by claims 3 and 15. The cited paragraph does not mention a statistics data model or a configuration data model in any form.” See applicant’s remarks, page 14. The examiner respectfully disagrees.
Naik discloses machine learning models to support traffic classification and the supervised learning 225 used for identifying the traffic class of a traffic flow. Further, Naik mentions machine learning model used for the supervised learning 225 may be a same (or different) machine learning model. See paragraphs [0121]-[0128]. In other words, the machine learning model used to support traffic classification and the supervised learning 225 used for identifying the traffic class of a traffic flow are two different models considered as at least one statistic data model and at least one configuration data model. Naik mentions the data packets assigned to MAC service data units (MSDUs) in a network using one or more of the IEEE 802.11 family of wireless communication protocol standards. These standards define the WLAN radio and baseband protocols for the PHY and MAC layers. See paragraphs [0101] and [0128]. Therefore, Naik discloses "the at least one statistics data model and the at least one configuration data model" being "applied to at least one of a media access control (MAC) layer as required in the claims.
Claims 4 and 16:
The applicant argues “Paragraph [0168] of Naik describes a request of an entirely different kind. Naik states that at step / message flow 815, the device 805-a may receive a request for machine learning model information from the device 805-b. Claim 4 requires the access device to "transmit a request message to the computing device to request that the computing device to transmit the traffic configuration information to the access device" and claim 16 correspondingly requires the computing device to receive such a request message, as recited by those claims. A request for machine learning model information - that is, a request for layer counts, neuron counts and weights - is not a request that a computing device transmit traffic configuration information. Moreover, the request in paragraph [0168] is received by device 805-a, the device the Office Action equates with the access device, which is the reverse of the direction required by claim 4.” See applicant’s remarks, page 14. The examiner respectfully disagrees.
Naik discloses the wireless communications system 100, or devices of the wireless communications system 100, may support a framework for determining whether a traffic class is known to a machine learning model. In some examples, a first device (e.g., an AP 102, a STA 104) may receive signaling associated with a traffic class from a second device (e.g., another AP 102, another STA 104) as described throughout paragraph [0104]. In other words, determining of traffic class/QoS class and applying of the learning models described throughout the Naik reference can be done by any of the APs or STAs (i.e., devices 205) as discussed throughout Naik. For example, the first device can be considered as device 205-a and the second device can be considered as device 205-b or the first device can be considered as device 205-b and the second device can be considered as device 205-a. When considering paragraph [0168] of Naik, the device 805-a may receive a request for machine learning model information from the device 805-b or the device 805-b may receive a request for machine learning model information from the device 805-a. Therefore, access devices and/or computing devices (i.e., device 805-a and/or device 805-b) can transmit the request. As such, Naik discloses "transmit a request message to the computing device to request that the computing device to transmit the traffic configuration information to the access device" as required in the claims.
Claims 5 and 17:
The applicant argues “Paragraph [0128] of Naik, the sole basis cited, concerns queue management. Naik states that the device 205-a may use the identified traffic class for channel access behavior continuity and describes assigning MSDUs to a first access category and then moving them to a second access category when the prediction result changes, so as to reduce out-of-order delivery. Claims 5 and 17 require that one device "perform a part of computation associated with utilizing the AI/ML model to process the traffic statistics data, wherein the other part of the computation is performed by" the other device, as recited by those claims. Paragraph [0128] describes no division of AI/ML computation between two devices whatsoever; the operations it describes are performed entirely at device 205-a.” See applicant’s remarks, page 14. The examiner respectfully disagrees.
Naik discloses the device 205-a may perform (or adjust, modify) one or more operations based on a prediction of the machine learning model. For example, the device 205-a may perform one or more operations based on determining that the traffic class associated with the signaling 210-a is a known traffic class (e.g., an interested traffic class) (in other words, device 205-a performs a part in applying the rules/algorithms (i.e., computation) associated with the learning model (i.e., AI/ML model) for receiving an output of specific operations (i.e., for processing traffic statistics data))… Although the example of FIG. 2 illustrates the analysis 215, the inference 220, and the supervised learning 225 being performed at the device 205-a, it is to be understood that the device 205-b, the device 205-c, and the device 205-d may also perform the analysis 215, the inference 220, and the supervised learning 225, or some combination thereof, to identify a traffic class. See paragraphs [0120]-[0121]. For example, both the access device/device 205-a and computing device/device 205-b both perform computations associated with the learning models. Naik discloses "perform a part of computation associated with utilizing the AI/ML model to process the traffic statistics data, wherein the other part of the computation is performed by" the other device, as recited in the claims.
Claims 6 and 18:
The applicant argues “Paragraph [0128] is again the sole basis cited. As noted above, it describes access-category assignment and EDCA adjustment at a single device. It does not describe "a first statistics data model for MAC layer connection information," nor any of the second, third or fourth statistics data models recited as alternatives in claims 6 and 18. That certain of Naik's operations occur at the MAC layer does not establish disclosure of a statistics data model for MAC layer connection information as recited by those claims.” See applicant’s remarks, page 15. The examiner respectfully disagrees.
Naik discloses machine learning models to support traffic classification and the supervised learning 225 used for identifying the traffic class of a traffic flow. Further, Naik mentions machine learning model used for the supervised learning 225 may be a same (or different) machine learning model. See paragraphs [0121]-[0128]. In other words, the machine learning model used to support traffic classification and the supervised learning 225 used for identifying the traffic class of a traffic flow are two different models considered as at least one statistic data model and at least one configuration data model. Naik mentions the data packets assigned to MAC service data units (MSDUs) in a network using one or more of the IEEE 802.11 family of wireless communication protocol standards. These standards define the WLAN radio and baseband protocols for the PHY and MAC layers. See paragraphs [0101] and [0128]. Therefore, Naik discloses "a first statistics data model for MAC layer connection information," as required in the claims.
Claims 7 and 19:
The applicant argues “Paragraph [0126] of Naik describes signaling for uplink prioritization, in which for uplink traffic handling, the device 205-a may send a DSCP, user priority (UP), and IP-tuple mapping (e.g., DSCP/UP+ IP-tuple/DSCP/UP mapping). This is a prioritization mapping sent to a peer station on the basis of a locally obtained detection result. It is not "a second configuration data model for IP layer control information," nor any other of the configuration data models recited in claims 7 and 19, and it is not received by an access device from a computing device as required by the claims from which claims 7 and 19 depend.” See applicant’s remarks, page 15. The examiner respectfully disagrees.
Naik discloses machine learning models to support traffic classification and the supervised learning 225 used for identifying the traffic class of a traffic flow. Further, Naik mentions machine learning model used for the supervised learning 225 may be a same (or different) machine learning model. See paragraphs [0121]-[0128]. In other words, the machine learning model used to support traffic classification and the supervised learning 225 used for identifying the traffic class of a traffic flow are two different models considered as at least one statistic data model and at least one configuration data model. Paragraph [0126] further teaches, the IP-tuple (e.g., the IP-5 tuple) may include an source IP address, a source port, a destination IP address…describing IP layer configuration information required for packet routing as described throughout Naik. Naik discloses "a second configuration data model for IP layer control information," as required in the claims.
Claims 8-11 and 20-23:
The applicant argues “These claims recite the constituent fields of the first and second statistics data models and of the first and second configuration data models introduced in claims 6 and 7 and claims 18 and 19 respectively. Because Naik does not disclose those data models at all, as shown above, the constituent fields recited in claims 8-11 and 20-23 have no disclosed data model to populate. Applicant acknowledges that isolated parameters resembling certain of the recited fields appear in Naik - for example, paragraph [0126] notes that the IP-tuple (e.g., the IP-5 tuple) may include an source IP address, a source port, a destination IP address, a destination port, and a transport protocol. The presence of such parameters in a QoS classifier does not, however, disclose "the second statistics data model" comprising "a source IP address associated with the IP layer connection" as recited by claims 9 and 21, or the corresponding limitations of the remaining dependent claims, because Naik discloses no statistics data model or configuration data model of which those parameters could form part.” See applicant’s remarks, page 15. The examiner respectfully disagrees.
As discussed above, Naik discloses machine learning models to support traffic classification and the supervised learning 225 used for identifying the traffic class of a traffic flow. Further, Naik mentions machine learning model used for the supervised learning 225 may be a same (or different) machine learning model. See paragraphs [0121]-[0128]. In other words, the machine learning model used to support traffic classification and the supervised learning 225 used for identifying the traffic class of a traffic flow are two different models considered as at least one statistic data model and at least one configuration data model. For example, the IP-tuple (e.g., the IP-5 tuple) may include an source IP address, a source port, a destination IP address…describing IP layer configuration information required for packet routing (see paragraph [0126]) as described throughout Naik. Therefore, Naik discloses statistics data model and configuration data model (i.e., first/second data models) comprising "a source IP address associated with the IP layer connection" as required in claims 9 and 21, and the corresponding limitations of the remaining dependent claims.
Claim 14:
The applicant argues “Claim 14 requires "utilizing the AI/ML model to determine at least one of network topology information, traffic distribution information, traffic allocation information, and traffic pattern information based on the traffic statistics data" and then "utilizing the AI/ML model to determine the traffic configuration information based on the at least one of" those items, as recited by claim 14. Paragraphs [0124] and [0125] describe no such two-stage determination. Paragraph [0125] describes the mapping of a detected traffic type to a QoS class, including scheduling with the collected traffic statistics and the supply of parameters such as a nominal delay constraint, a nominal packet arrival interval and a nominal throughput. These are parameters supplied to a scheduler from a classification result; they are not network topology information, traffic distribution information, traffic allocation information or traffic pattern information determined by an AI/ML model from received traffic statistics data, and they are not thereafter processed by an AI/ML model to determine traffic configuration information, as claim 14 requires. In particular, no network topology information is determined anywhere in the cited paragraphs.” See applicant’s remarks, pages 15-16. The examiner respectfully disagrees.
Naik discloses for example, the computing device (such as device 205-c) uses the machine learning model (in other words, AI/ML model) for obtaining classifying traffic (in other words, traffic configuration information) based on transmitted/detected data packets and the information may correspond to a type of feature associated with data packets received at the device 205-a via the signaling 210-a. That is, the information may include a set of features that correspond to a type of feature, such as a quantity of data packets (e.g., received at the device 205-a via the signaling 210-a), a size of data packets, one or more statistics associated with the quantity of data packets, or one or more statistics associated with a packet inter-arrival time (in other words, considered as any one of traffic distribution information or traffic allocation information where the information of the data packets are determined by the learning model for determining the classification of traffic/traffic configuration information), or any combination thereof. See paragraphs [0114], [0124] and [0125]. In this case, the traffic distribution or traffic allocation is the actual information obtained regarding the distributed/allocated data packets/traffic transmitted/received in the network described. As such, Naik discloses "utilizing the AI/ML model to determine at least one of network topology information, traffic distribution information, traffic allocation information, and traffic pattern information based on the traffic statistics data" and then "utilizing the AI/ML model to determine the traffic configuration information based on the at least one of" those items, as required in the claims.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-11 and 13-24 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Naik et al. (Naik), U.S. Publication No. 2024/0154912.
Regarding Claims 1 and 13, Naik discloses an access device (i.e., a device
(e.g., a station (STA) or an access point (AP)); see paragraph [0090]), comprising:
at least one processor (i.e., processor 1440; see figure 14); and
at least one memory (i.e., memory 1430; see figure 14) storing instructions that,
when executed by the at least one processor, cause the access device at least to:
transmit, to a computing device, traffic statistics data related to traffic passing through the access device based on at least one statistics data model for statistics data (i.e., the device 205-a (e.g., an AP) may offer downloadable identification or classification models to the device 205-c (e.g., or one or more other associated non-AP STAs) that support machine learning and the traffic classification. In such an example, the device 205-a may receive a request 230 for information associated with the machine learning model to be used at the device 205-c for classifying traffic. In response, the device 205-a may transmit a message indicating machine learning model information 235 to the device 205-c.; see paragraph [0123]);
receive, from the computing device, traffic configuration information for the traffic based on at least one configuration data model for traffic configuration, wherein the traffic configuration information is determined by utilizing an artificial intelligence (AI)/machine learning (ML) model to process the traffic statistics data (i.e., The device 205-c may use the machine learning model information 235 to obtain (e.g., build, construct, updated) the machine learning model for classifying traffic. For example, the device 205-c may identify a traffic class associated with the signaling 210-b. In such an example, the device 205-c (e.g., a non-AP STA, such as a client device) may perform one or more operations in accordance with the identified traffic class.; see paragraph [0124]); and
configure the traffic based on the traffic configuration information (i.e., For example, the device 205-a may determine to communicate with the device 205-a in accordance with (or based on) the identified traffic class.; see paragraphs [0124]). Also, see paragraphs [0117]-[0118] and [0121].
Regarding Claims 2 and 24, Naik discloses wherein the access device is
caused to configure the traffic by: controlling at least one of quality of service (QoS) (see paragraph [0126]), bandwidth allocation, or traffic scheduling based on the traffic configuration information.
Regarding Claims 3 and 15, Naik discloses wherein the at least one statistics
data model and the at least one configuration data model are applied to at least one of a media access control (MAC) layer (see paragraph [0101]), an Internet protocol (IP) layer, or a transport layer.
Regarding Claims 4 and 16, Naik discloses wherein the access device is further
caused to: transmit a request message to the computing device to request that the computing device transmit the traffic configuration information to the access device (see paragraph [0168]).
Regarding Claims 5 and 17, Naik discloses wherein the access device is further
caused to: perform a part of computation associated with utilizing the AI/ML model to process the traffic statistics data, wherein the other part of the computation is performed by the computing device (see paragraph [0128]).
Regarding Claims 6 and 18, Naik discloses wherein the at least one statistics
data model comprises at least one of the following: a first statistics data model for MAC layer connection information (see paragraph [0128]); a second statistics data model for IP layer connection information; a third statistics data model of a statistics data list of MAC layer connection for the MAC layer connection information; or a fourth statistics data model of a statistics data list of IP layer connection for the MAC layer connection information.
Regarding Claims 7 and 19, Naik discloses wherein the at least one
configuration data model comprises at least one of the following: a first configuration data model for MAC layer control information; a second configuration data model for IP layer control information (see paragraph [0126]); a third configuration data model of a MAC layer control list for the MAC layer control information; or a fourth configuration data model of an IP layer control list for the MAC layer control information.
Regarding Claims 8 and 20, Naik discloses wherein the first statistics data
model comprises at least one of the following: a label associated with the MAC layer connection; a source MAC address associated with the MAC layer connection; a virtual local area network (VLAN) number associated with the MAC layer connection; a destination MAC address associated with the MAC layer connection; a priority associated with the MAC layer connection (see paragraph [0128]); a setup time associated with the MAC layer connection; a sustain time associated with the MAC layer connection; or a statistics timestamp associated with the MAC layer connection.
Regarding Claims 9 and 21, Naik discloses wherein the second statistics data
model comprises at least one of the following: a label associated with the IP layer connection; an IP version associated with the IP layer connection; a transport protocol associated with the IP layer connection; a source IP address associated with the IP layer connection (see paragraph [0126]); a source port number associated with the IP layer connection; a destination IP address associated with the IP layer connection; a destination port number associated with the IP layer connection; a setup time associated with the IP layer connection; a sustain time associated with the IP layer connection; or a statistics timestamp associated with the IP layer connection.
Regarding Claims 10 and 22, Naik discloses wherein the first configuration data
model comprises at least one of the following: a label associated with MAC layer connection; a VLAN number associated with the MAC layer connection; or a priority associated with the MAC layer connection (see paragraph [0128]).
Regarding Claims 11 and 23, Naik discloses wherein the second configuration
data model comprises at least one of the following: a label associated with the IP layer connection; a VLAN number associated with the IP layer connection; a priority associated with the IP layer connection; or a differentiated service code point (DSCP) associated with the IP layer connection (see paragraph [0126]).
Regarding Claim 14, Naik discloses wherein the computing device is caused to
determine the traffic configuration information by: utilizing the AI/ML model to determine at least one of network topology information, traffic distribution information, traffic allocation information, and traffic pattern information based on the traffic statistics data; and utilizing the AI/ML model to determine the traffic configuration information based on the at least one of the network topology information, the traffic distribution information, the traffic allocation information, and the traffic pattern information (see paragraphs [0124]- [0125]).
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 SHANTELL LAKETA HEIBER whose telephone number is (571)272-0886. The examiner can normally be reached on M-F from 9am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Anthony Addy, can be reached at telephone number (571)272-0886. 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 Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/SHANTELL L HEIBER/Primary Examiner, Art Unit 2645
October 7, 2026
