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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 25 June, 2026 has been entered.
Claims 1-20 are pending.
Claims 1, 8, and 15 have been amended.
Response to Arguments
35 USC § 103
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), in view of Gormley (US 8,543,685), further in view of Scifres et al (US 6,912,574).
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 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.
Chatterjee-Peterson teaches the above but Chatterjee-Peterson does not explicitly teach a stepped-limiting mechanism wherein the stepped-limiting mechanism defines a plurality of processor usage thresholds each associated with a different throughput limit for the second device, and wherein performing the corrective action comprises selecting a throughput limit, from among different throughput limits, based on which of the plurality of processor usage thresholds the processor usage level satisfies. However, in a similar field of endeavor, Gormley teaches a stepped-limiting mechanism (Gormley col.4 lines 13-19 provides “These rate-limiting schemes can facilitate gradual slowdown in throughput for moderate-usage client devices, such that a user on the borderline of being considered a heavy user or a light user may have lesser rate-limiting applied than the rate-limiting that would be applied for a heavy user. The rate-limiting schemes can also facilitate a dynamically configurable rate of slow-down or speed-up”).
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 of stepped-limiting as taught by Gormley for managing throughput restrictions for client devices. The teachings of Gormley, when implemented in the Chatterjee-Peterson system, will allow one of ordinary skill in the art to provide an improved data communications systems that can selectively apply more efficient rate-limiting schemes that offer a better overall user experience for the collective users of a shared data communications link. 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.
Chatterjee-Peterson-Gormley teaches a stepped-limiting mechanism but Chatterjee-Peterson-Gormley does not explicitly teach defining a plurality of processor usage thresholds each associated with a different throughput limit for the second device, and wherein performing the corrective action comprises selecting a throughput limit, from among different throughput limits, based on which of the plurality of processor usage thresholds the processor usage level satisfies. However, in a similar field of endeavor, Scifres teaches defining a plurality of processor usage thresholds each associated with a different throughput limit for the second device, and wherein performing the corrective action comprises selecting a throughput limit, from among different throughput limits, based on which of the plurality of processor usage thresholds the processor usage level satisfies (Scifres col.6 lines 52-60 provides “In the preferred embodiment of the allocation flow system 10, the processing agent 22 can be a single computer processor in communication with the restriction agents 18, and the restriction agents 18 can be implemented in a router, a bridge or a switching device which may be generally described as the portal 16 between the usage devices 12 and the computer network 74. It is also possible for the restriction agents 18 to be integrated into the computer processor itself”; Scifres claim 43 provides “A method for allocating a flow capacity to a set of usage devices accessing a service network, comprising: (a) defining a set of flow restrictions, wherein said set of defined flow restrictions comprises a range of flow rates less than a maximum flow rate; (b) defining a set of volume limits corresponding with the set of usage devices and corresponding with a time period in which the set of usage devices access the service network; (c) associating said set of volume limits with said range of flow rates in said set of flow restrictions for each usage device in the set of usage devices; (d) transferring a set of flows through a set of restriction agents between the set of usage devices and the service network; (e) monitoring said set of flows in a control network, wherein each of said usage devices in the service network has a unique identity in said control network; (f) selecting a set of flow restrictions from said set of defined flow restrictions, said selected set of flow restrictions being determined by a processor according to said volume limits and according to said monitored set of flows, wherein said selecting step comprises: (i) computing a flow volume for each of the usage devices during said time period according to said monitored flows, (ii) comparing said flow volume with said set of volume limits as applied to each of the usage devices, (iii) identifying a subset of the usage devices having said flow volume exceeding said corresponding set of applied volume limits, (iv) shifting a set of volume quotas for the set of usage devices according to a set of exception policies for the set of usage devices, and (v) selecting said set of flow restrictions from said set of defined flow restrictions for each of the usage devices according to said association between said set of volume limits and said range of flow rates”).
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 Scifres for managing flow restrictions for usage devices. The teachings of Scifres, when implemented in the Chatterjee-Peterson-Gormley system, will allow one of ordinary skill in the art to limits users in an efficient manner and using a less complex system when the users have reached a usage limit. 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: Gormley US 8,713,196.
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 /SCHQUITA D GOODWIN/ Primary Examiner, Art Unit 2459
Prosecution Insights