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 .
This communication is in response to Remarks and Amendments filed on 17 December, 2025.
Claims 1-20 are pending.
Claims 1, 8, 10, 15 and 19-20 have been amended.
Response to Arguments
35 USC § 102
Examiner finds Applicant’s arguments with regard to the amended claims persuasive and a new ground of rejection is presented herewith.
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Chatterjee et al (US 2012/0257499), in view of Peterson et al (US 2017/0163537).
Regarding claim 1, Chatterjee teaches a method, comprising:
identifying, by a first device, a congestion event at one or more network components (Chatterjee fig.4 element 402);
identifying, by the first device and based on identifying the congestion event, a second device with a load that satisfies a load threshold (Chatterjee fig.4 elements 400-404);
and limiting, by the first device and based on a policy obtained from a policy and control function, the load of the second device (Chatterjee fig.4 element 408; [0078] provides “For example, PCRF 104 may generate a PCC rule to reduce the QoS for the subscribers identified in the congestion notification message”).
Chatterjee teaches the above including identifying a congestion event (Chatterjee fig.4 element 402), but Chatterjee does not explicitly wherein it is based on a processor usage level, and limiting load based on a stepped-limiting mechanism utilizing the processor usage level. However, in a similar field of endeavor, Peterson teaches wherein it is based on a processor usage level (Peterson [0029]), and limiting load based on a stepped-limiting mechanism utilizing the processor usage level (Peterson [0029] provides “The policy algorithm utilized by SLB 104 may optionally be updated or supplemented with other metrics, which are periodically communicated via member SCs 106.sub.A to 106.sub.N; such metrics may include a CPU utilization rate or percentage, or the like. In some embodiments, the CPU utilization rate of each member SC 106.sub.A to 106.sub.N may be used as a factor for determining whether a SC will be included in a distribution pool. For example, a threshold value of CPU utilization rate may be set, and when a given member SC 106.sub.A to 106.sub.N reports a rate that exceeds the threshold value; it will be excluded from the list of candidates eligible to receive new session traffic. In one non-limiting exemplary embodiment, where a member SC 106.sub.A to 106.sub.N reports a CPU utilization rate of 90% or more, it will be excluded from the list of cluster members eligible to receive new sessions. That is, SCs exceeding a predetermined threshold CPU utilization rate will have a distribution rate of zero (0). The threshold CPU utilization rate may be set to any suitable value, such as 80%, 85%, 90%, 95%, or any other suitable threshold value, as desired”; [0038] provides “Configuring SLB 104 with a load balancer traffic policy enables traffic shaping via allocating sessions according to heterogeneous SC capabilities…”).
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the concept taught by Peterson for distributing traffic in a network. The teachings of Peterson, when implemented in the Chatterjee system, will allow one of ordinary skill in the art to efficiently shape traffic by applying policies (Peterson [0038]). Therefore, the examiner concludes it would have been obvious to one of ordinary skill in the art before the effective filing date of applicant’s invention to arrive at the above-claimed invention.
Regarding claim 2, the method of claim 1, wherein the load threshold is implemented based on identifying the congestion event (Chatterjee fig.4 element 402).
Regarding claim 3, the method of claim 1, further comprising: causing a network component to obtain the policy (Chatterjee [0078] provides “In step 408, the policy server communicates the PCC rule to a policy and charging enforcement function. For example, PCRF 104 may communicate the PCC rule to a PDN gateway, a DPI, a gateway GPRS support node, or other node capable of enforcing the policy for the identified subscribers”, wherein the network node capable of enforcing policy obtains said policy as a communication from PCRF).
Regarding claim 4, the method of claim 1, wherein identifying the congestion event is based on determining whether traffic data satisfies a congestion threshold (Chatterjee fig.4 elements 4000-402).
Regarding claim 5, the method of claim 1, wherein limiting the load of the second device comprises: causing a network component to drop packets for the second device (Chatterjee [0078] provides “For example, PCRF 104 may generate a PCC rule to reduce the QoS for the subscribers identified in the congestion notification message”, wherein a reduction in QoS can include dropped packets).
Regarding claim 6, the method of claim 1, wherein limiting the load of the second device comprises: limiting a throughput associated with the second device (Chatterjee [0078] provides “For example, PCRF 104 may generate a PCC rule to reduce the QoS for the subscribers identified in the congestion notification message”, wherein a reduction in QoS can include throughput throttling).
Regarding claim 7, the method of claim 1, further comprising: determining a status associated with the second device (Chatterjee [0077] provides “In step 404, in response to determining that the predetermined threshold associated with a cell has been crossed, the monitoring module generates a cell congestion notification message that includes the identity of one or more subscribers that are contributing to the congestion. For example, PIC 100 may generate the above described congestion notification message including parameters that identify the subscriber(s) contributing the congestion and parameters that identify the cell”, wherein the status associated with the second device can be broadly construed as that of a contributor to congestion); and wherein limiting the load of the second device is based on the status of the second device (Chatterjee [0078] provides “In step 408, the policy server generates a policy and charging control (PCC) rule that modifies the policy of the one or more identified subscribers. For example, PCRF 104 may generate a PCC rule to reduce the QoS for the subscribers identified in the congestion notification message”).
Regarding claim 8, Chatterjee teaches a first device, comprising:
one or more processors configured to:
identify a congestion event based on processing unit usage at one or more network components (Chatterjee fig.4 element 402);
identify, based on identifying the congestion event, a second device with a load that satisfies a load threshold (Chatterjee fig.4 elements 400-404);
and perform a corrective action, based on a policy obtained from a policy and control function, associated with the load of the second device based on using a stepped-limiting mechanism associated with the processing unit usage (Chatterjee fig.4 element 408; [0078] provides “For example, PCRF 104 may generate a PCC rule to reduce the QoS for the subscribers identified in the congestion notification message”).
Regarding claim 9, the first device of claim 8, wherein the policy includes one or more of: an area capacity policy, a mobility policy, a density policy, or a guaranteed minimum data policy (Chatterjee [0078] provides for QoS).
Regarding claim 10, the first device of claim 8, wherein the one or more processors are further configured to: provide, to a network component, information associated with the congestion event (Chatterjee fig. 4 element 404); and instruct the network component to obtain the policy (Chatterjee fig.4 elements 404-408, wherein sending a cell congestion notification can be reasonably interpreted as an instruction to address the congestion event; Chatterjee [0024] provides “The function of the PCRF or policy server is to act on the cell congestion data provided by PIC and apply appropriate policies to mitigate the congestion”).
Regarding claim 11, the first device of claim 8, wherein the one or more processors, are further configured to: identify a plurality of user devices impacted by the congestion event (Chatterjee [0016] provides “The solution identifies subscribers who are consuming unusually high proportions of the bandwidth and lowers their quality of service. This enables the rest of the subscribers to get access to the additional amount of bandwidth that got freed up, thereby, improving their quality of experience”, wherein “the rest of the subscribers” provides for impacted subscribers).
Regarding claim 12, the first device of claim 8, wherein the one or more processors, to perform the corrective action, are configured to: cause a serving gateway to notify a core network device that the second device is overloading a network component (Chatterjee fig.4 element 404; [0078] provides “In step 408, the policy server communicates the PCC rule to a policy and charging enforcement function. For example, PCRF 104 may communicate the PCC rule to a PDN gateway, a DPI, a gateway GPRS support node, or other node capable of enforcing the policy for the identified subscribers”).
Regarding claim 13, the first device of claim 8, wherein the one or more processors, to perform the corrective action, are configured to: notify a core network device to limit throughput for the second device (Chatterjee fig.4 element 408; [0078] provides “For example, PCRF 104 may generate a PCC rule to reduce the QoS for the subscribers identified in the congestion notification message”, wherein a reduction in QoS can include limiting throughput).
Regarding claim 14, the first device of claim 8, wherein the one or more processors, to perform the corrective action, are configured to: apply a quality of service parameter for the second device (Chatterjee fig.4 element 408; [0078] provides “For example, PCRF 104 may generate a PCC rule to reduce the QoS for the subscribers identified in the congestion notification message”).
Regarding claim 15, this claim contains limitations found within those of claim 1, and the same rationale of rejection applies, where applicable.
Regarding claim 16, the non-transitory computer-readable medium of claim 15, wherein the one or more instructions, that cause the first device to perform the corrective action, cause the first device to: enforce an aggregate maximum bit rate for the second device (Chatterjee [0078] provides “In step 408, the policy server generates a policy and charging control (PCC) rule that modifies the policy of the one or more identified subscribers. For example, PCRF 104 may generate a PCC rule to reduce the QoS for the subscribers identified in the congestion notification message”).
Regarding claim 17, the non-transitory computer-readable medium of claim 15, wherein the one or more instructions, that cause the first device to perform the corrective action, cause the first device to: enforce a maximum bit rate for the second device (Chatterjee [0078] provides “In step 408, the policy server generates a policy and charging control (PCC) rule that modifies the policy of the one or more identified subscribers. For example, PCRF 104 may generate a PCC rule to reduce the QoS for the subscribers identified in the congestion notification message”).
Regarding claim 18, the non-transitory computer-readable medium of claim 15, wherein the one or more instructions, that cause the first device to perform the corrective action, cause the first device to: limit an aggregate of data usage for all quality of service flows for the second device (Chatterjee [0078] provides “In step 408, the policy server generates a policy and charging control (PCC) rule that modifies the policy of the one or more identified subscribers. For example, PCRF 104 may generate a PCC rule to reduce the QoS for the subscribers identified in the congestion notification message”).
Regarding claim 19, the non-transitory computer-readable medium of claim 15, wherein the one or more instructions further cause the first device to: instruct a network component to obtain a particular policy for addressing high consumption devices (Chatterjee [0077] provides “For example, PIC 100 may generate the above described congestion notification message including parameters that identify the subscriber(s) contributing the congestion and parameters that identify the cell”; [0078] provides “In step 406, a policy server receives the congestion notification message. For example, PCRF 104 may receive the congestion notification message from PIC 100. In step 408, the policy server generates a policy and charging control (PCC) rule that modifies the policy of the one or more identified subscribers”).
Regarding claim 20, the non-transitory computer-readable medium of claim 15, wherein the one or more instructions further cause the first device to: obtain the policy from a network component, wherein the policy indicates a limiting behavior for high consumption devices (Chatterjee [0078] provides “In step 408, the policy server generates a policy and charging control (PCC) rule that modifies the policy of the one or more identified subscribers. For example, PCRF 104 may generate a PCC rule to reduce the QoS for the subscribers identified in the congestion notification message”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: Lissack US 2015/0149611
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 ISHRAT RASHID whose telephone number is (571)272-5372. The examiner can normally be reached 10AM-6PM EST M-F.
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, Tonia L Dollinger can be reached at 571-272-4170. 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.
/I.R/Examiner, Art Unit 2459 /TONIA L DOLLINGER/Supervisory Patent Examiner, Art Unit 2459