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/Amendments
Applicant’s arguments filed on 6/15/26 have been considered but are moot because the new ground of rejection shown below.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-6, 12-17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Agerstam (US 20230328547 A1) in view of Ngo (US 20170181015 A1).
For claim 1, Agerstam discloses a method (FIGs. 1-10 and associated text, such the method of FIG. 8 run on networks by FIGs. 1 and 9-10) comprising:
receiving, by a first network device, a traffic flow from a second network device via a wireless network in an operational environment (FIGs. 1-10 and associated text, such as FIG. 8 and “[0126] The process flow begins at block 802 by receiving performance data for the respective wireless networks deployed in the environment. …” and “[0053] The performance objectives 111 provide guidance on how to tune the wireless infrastructure against an overall objective function for all wireless networks 102a-d and associated wireless technologies. In some embodiments, for example, the performance objectives 111 may include traffic flow objectives that prioritize the various traffic flows across all wireless networks 102a-d.”)
analyzing, by the first network device, the traffic flow to identify a network service associated with the traffic flow (FIGs. 1-10 and associated text, such as “[0148] The end-to-end service view for these use cases involves the concept of a service-flow and is associated with a transaction. The transaction details the overall service requirement for the entity consuming the service, as well as the associated services for the resources, workloads, workflows, and business functional and business level requirements.”);
assigning, by the first network device, a first scale value to the traffic flow based on a jitter sensitivity level of the network service (FIGs. 1-10 and associated text, such as “[0077] For example, the quality of service (QoS) metrics contain discrete performance metrics (e.g., signal strength, signal-to-noise ratio, packet loss, jitter, latency, etc.), each of which can be treated as a single feature. Thus, in some embodiments, a decision tree algorithm may be used to train a model based on the QoS metrics (e.g., as described below in connection with FIG. 5).”);
assigning, by the first network device, a second scale value to the traffic flow based on a defined network service policy associated with the operational environment, the defined network service policy indicating a traffic criticality level for the network service, with respect to the operational environment (FIGs. 1-10 and associated text, such as “[0077] For example, the quality of service (QoS) metrics contain discrete performance metrics (e.g., signal strength, signal-to-noise ratio, packet loss, jitter, latency, etc.), each of which can be treated as a single feature. …”);
Agerstam is silent but Ngo, in the same field of endeavor of wireless network communication, discloses:
detecting, by the first network device, a network congestion within the wireless network (“[0037] … congestion information (e.g., number of re-try packets, type of re-try packets, etc.) …”); and
responsive to detecting the network congestion, switching, by the first network device, to a congestion management mode, comprising:
determining, by the first network device, adjustments for one or more network transmission settings (FIGs. 1-10 and associated text, such as “[0038] … The agility agent 200 may receive information such as network traffic, congestion, and/or control signals with the secondary radio 216. And the agility agent 200 may transmit information, such as control signals, with the secondary radio 216. ....”), and
communicating, by the first network device, the adjustments to the second network device (FIGs. 1-10 and associated text, such as “[0038] … And the agility agent 200 may transmit information, such as control signals, with the secondary radio 216. The primary radio 215 is connected to a fast channel switching generator 217 that includes a switch and allows the primary radio 215 to switch rapidly between a radar detector 211 and beacon generator 212. The fast channel switching generator 217 allows the radar detector 211 to switch sufficiently fast to appear to be on multiple channels at a time.” and ”[0060] The present invention uses the same omnidirectional behavior of Wi-Fi that contributes to the interference and congestion problems to help ameliorate those issues … ”). OOSA would have been motived to apply the teaching of Ngo above to the traffic flow based on the first and second scale value by Agerstam to yield a predictable result of reducing congestion.
Therefore, it would have been obvious to OOSA before the effective filing date of the application to combine Agerstam and Ngo for the benefit of reducing congestion ([0060] of Ngo).
Claim 12 is rejected because it is a generic computer system that performs the method of claim 1 and has the same subject matter.
Claim 20 is rejected because it is a non-transitory computer-readable media containing code for performing the method of claim 1 and has the same subject matter.
As to claims 2 and 13, Agerstam in view of Ngo discloses claims 1 and 12, Agerstam further discloses: wherein the first network device comprises an access point (AP) or a wireless controller (WLC) (FIGs. 1-10 and associated text, such as FIG. 3, AP 301).
As to claims 3 and 14, Agerstam in view of Ngo discloses claims 1 and 12, Agerstam further discloses: wherein the second network device comprises a station (STA) associated with the first network device for network connection (FIG. 3, STA 320).
As to claims 4 and 15, Agerstam in view of Ngo discloses claims 1 and 12, Agerstam further discloses: wherein the first scale value of the network service is further assigned based on at least one of (i) a differentiated service code point (DSCP) value (“[0057] Examples of such QoS controls include, … QoS controls at the converged IPv6/IPv4 layer (e.g., through the differentiated services code point (DSCP) field in the IP header, bandwidth allocation, and queueing policies and priorities)”), (ii) a category of traffic (“[0057] Examples of such QoS controls include, … QoS controls at the converged IPv6/IPv4 layer (e.g., through the differentiated services code point (DSCP) field in the IP header, …), (iii) a latency preference ([0035] … latency …), (iv) a reliability preference ( [0033] (ii) general demodulation errors; [0034] (iii) data transmission errors (e.g., bit error rate (BER) before and after applying any forward error correction (FEC) algorithm, block error rate (BLER), packet collisions, packet error rate (PER), checksum errors at the network/transport layers); and [0035] … packet drops, packet loss …), (v) a jitter sensitivity level ([0035] … jitter …), or (v) a queueing policy, defined for the network service (“[0057] …, and queueing policies and priorities)”).
As to claims 5 and 16, Agerstam in view of Ngo discloses claims 1 and 12, further discloses: wherein the one or more network transmission settings comprise at least one of (i) a packet retry value (Ngo: “[0066] … The packet information can include information such as packet envelopes, packet headers, packet type, packet size, retry bits, …”), (ii) an aggressiveness factor for Modulation and Coding Scheme (MCS) selection (suggested by Agerstam: “[0045] … selecting a different modulation and coding scheme (MCS) index to indirectly change the modulation scheme, coding scheme, …“ or “[0069]… modulation and coding scheme (MCS) indices for various wireless technologies (e.g., MCS indices for Wi-Fi, cellular), …”), or (iii) a down-shifting factor for MCS selection (Agerstam: “[0068] … the processing pipeline 300 receives various types of input or performance data 302 from different sources, such as quality of service (QoS) metrics for wireless networks …, modulation and coding scheme (MCS) indices for various wireless technologies (e.g., MCS indices for Wi-Fi, cellular), and performance objectives (e.g., traffic flow objectives)”). The motivation of combining Agerstam and Ngo is the same as stated in the parent claims.
As to claims 6 and 18, Agerstam in view of Ngo discloses claims 1 and 12, Agerstam further discloses:
calculating a priority value for the network service, based on the second scale value of the network service (“[0054] …these priorities may be specified as performance objectives 111, which are considered when generating tuning recommendations across the wireless networks 102a-d.”); and
determining, by the first network device, the adjustments for the one or more network transmission settings for the traffic flow based on the priority value (“[0057] For example, based on the respective priorities across the networks 102a-d, the tuning recommendations 122 may define traffic classes that provide a higher degree of quality of service for certain traffic flows, wireless networks 102a-d, and/or wireless technologies, which may require adjustments to certain settings relating to technology-specific QoS controls. …”).
Claims 7-10 and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Agerstam (US 20230328547 A1) in view of Ngo (US 20170181015 A1), further in view of NAKAHARA (US 20180077650 A1).
As to claims 7 and 18, Agerstam in view of Ngo discloses claims 1 and 12, further discloses:
computing a congestion function based on an amount of data queued by the first and second network devices (Ngo: “[0063] … The cloud intelligence engine 355 determines signatures from the packet information and determines the number of collisions experienced and/or whether large amounts of video packets are being transmitted. Based on this, the cloud intelligence engine 355 directs the Wi-Fi coordinator 303 to change the settings of the access point 301 to improve Wi-Fi performance. Thereafter, the Wi-Fi coordinator continues to transmit packet information to the cloud intelligence engine 355, and the cloud intelligence engine 355 determines if the change in the access point 301 settings improved performance and/or altered the packet information received. …”);
determining a priority class of the network service, using the congestion function, based on the first and second scale values (Agerstam: “[0057] For example, based on the respective priorities across the networks 102a-d, the tuning recommendations 122 may define traffic classes that provide a higher degree of quality of service for certain traffic flows, wireless networks 102a-d, and/or wireless technologies, which may require adjustments to certain settings relating to technology-specific QoS controls.”); and
determining, by the first network device, the adjustments for the one or more network transmission settings for the traffic flow based on the priority class (Agerstam: “[0057] For example, based on the respective priorities across the networks 102a-d, the tuning recommendations 122 may define traffic classes that provide a higher degree of quality of service for certain traffic flows, wireless networks 102a-d, and/or wireless technologies, which may require adjustments to certain settings relating to technology-specific QoS controls.”).
Agerstam in view Ngo is silent but NAKAHARA the congestion a congestion ratio function based on an amount of data queued by the first and second network devices (Abstract “… the unsent data stored in the sending queue of the adjacent node are used to calculate the congestion ratio. …”). OOSA would have been motivated to apply the teaching of NAKAHARA above to the congestion function by Agerstam in view Ngo to yield a predictable result of managing congestion.
Therefore, it would have been obvious to OOSA before the effective filing date of the application to combine NAKAHARA with Agerstam in view Ngo for the benefit of managing congestion (Abstract of NAKAHARA).
As to claim 8, Agerstam in view of Ngo and NAKAHARA discloses claim 7, further discloses: wherein the congestion ratio function is computed based further on at least one of (i) a number of active connections of the first network device (Agerstam: “[0046] … number of spatial streams (e.g., multiple-input multiple-output (MIMO)), …”); (ii) an amount of data waiting at the first network device (Ngo: “[0063] … The cloud intelligence engine 355 determines signatures from the packet information and determines the number of collisions experienced and/or whether large amounts of video packets are being transmitted. …”); (iii) an amount of data waiting at the second network device (Ngo: “[0063] … The cloud intelligence engine 355 determines signatures from the packet information and determines the number of collisions experienced and/or whether large amounts of video packets are being transmitted. …”); or (iv) an amount of retry bits received by the first network device over an interval (Agerstam: “[0066] … The packet information can include information such as packet envelopes, packet headers, packet type, packet size, retry bits, …”).
The motivation of combining Agerstam, Ngo and NAKAHARA is the same as stated in the parent claims.
As to claims 9 and 19, Agerstam in view of Ngo and NAKAHARA discloses claims 7 and 18, Agerstam further discloses: wherein the congestion ratio function is defined to categorize the network service into either a low-priority class or a high-priority class (this is an design choice and therefore is obvious to OOSA according to MEPE 2143(F)).
As to claim 10, Agerstam in view of Ngo and NAKAHARA discloses claim 7, Agerstam further discloses: wherein the congestion ratio function is a linear function of the traffic criticality level and the jitter sensitivity level, adjusted by one or more coefficients (“[0075] … the important features may be extracted from the input data 302 and the remaining unimportant features may be discarded. In some embodiments, unsupervised learning may be used to identify the correlated attributes for feature selection. For example, if two attributes are highly correlated with each other, then they are linearly dependent on each other … [0077] … the quality of service (QoS) metrics contain discrete performance metrics (e.g., signal strength, signal-to-noise ratio, packet loss, jitter, latency, etc.), each of which can be treated as a single feature. Thus, in some embodiments, a decision tree algorithm may be used to train a model based on the QoS metrics (e.g., as described below in connection with FIG. 5). …”).
The motivation of combining Agerstam, Ngo and NAKAHARA is the same as stated in the parent claims.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Agerstam (US 20230328547 A1) in view of Ngo (US 20170181015 A1), further in view of BAEK (US 20220346000 A1).
As to claim 11, Agerstam in view of Ngo claim 1, and is silent but BAEK, in the same field of wireless communication, discloses: wherein detecting a network congestion within the wireless network further comprises detecting that a channel utilization ratio of the wireless network exceeds a defined threshold (“[0313] According to an embodiment, the eNB and/or the UE may measure a channel utilization ratio thereof using a congestion level of a transmission level, and then may participate in the positioning procedure as the candidate AN when the congestion level is equal to or greater than a specific threshold, and may not participate in the positioning procedure as the candidate AN when the congestion level is equal to or less than the specific threshold.”). OOSA would have been motivated to apply the teaching of BAEK above to the congestion function by Agerstam in view Ngo to yield a predictable result of managing congestion.
Therefore, it would have been obvious to OOSA before the effective filing date of the application to combine NAKAHARA with Agerstam in view Ngo for the benefit of managing congestion ([0313] of BAEK).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 JIANYE WU whose telephone number is (571)270-1665. The examiner can normally be reached M-TH 8am-6pm.
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, Yemane Mesfin can be reached at (571) 272-3927. 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.
/JIANYE WU/Primary Examiner, Art Unit 2462
Prosecution Insights