DETAILED ACTION
Claim(s) 1-3, 5-13, 15-20, 22-47 have been examined and are pending.
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 .
Status of Claims
In the Non-Final Rejection mailed December 31, 2025, the status of the claims was as follows:
Claim(s) 1 and 26 were rejected under 35 U.S.C. 103 as being unpatentable over VAANANEN (USPGPub No. 2007/00585363) in view of VIRDI (US 20060026294 A1). Claim(s) 2 and 27 were rejected under 35 U.S.C. 103 as being unpatentable over VAANANEN (USPGPub No. 2007/0 Claim(s) 3 and 28 were rejected under 35 U.S.C. 103 as being unpatentable over VAANANEN (USPGPub No. 2007/00585363) in view of VIRDI (US 20060026294 A1) in view of LOEB (US 20080130669 A1)0585363) in view of VIRDI (US 20060026294 A1) in view of KUMAR (US 6597919 B1). Claim(s) 5 and 29 were rejected under 35 U.S.C. 103 as being unpatentable over VAANANEN (USPGPub No. 2007/00585363) in view of VIRDI (US 20060026294 A1) in view of NATTKEMPER (US 5953318 A). Claim(s) 6 and 30 were rejected under 35 U.S.C. 103 as being unpatentable over VAANANEN (USPGPub No. 2007/00585363) in view of VIRDI (US 20060026294 A1) in view of Voruganti (US 8213453 B1). Claim(s) 7-10 and 31-34 were rejected under 35 U.S.C. 103 as being unpatentable over VAANANEN (USPGPub No. 2007/00585363) in view of VIRDI (US 20060026294 A1) in view of McConnell (US 6108307 A). Claim(s) 11 and 35 were rejected under 35 U.S.C. 103 as being unpatentable over VAANANEN (USPGPub No. 2007/00585363) in view of VIRDI (US 20060026294 A1). Claim(s) 15 and 38 were rejected under 35 U.S.C. 103 as being unpatentable over VAANANEN (USPGPub No. 2007/00585363) in view of VIRDI (US 20060026294 A1) in view of Hakenberg (US 20020004838 A1). Claim(s) 16-17 and 39-40 were rejected under 35 U.S.C. 103 as being unpatentable over VAANANEN (USPGPub No. 2007/00585363) in view of VIRDI (US 20060026294 A1) in view of McConnell (US 6108307 A). Claim(s) 18, 20, 22, 24, 41, 43, 44, and 46 were rejected under 35 U.S.C. 103 as being unpatentable over VAANANEN (USPGPub No. 2007/00585363) in view of Feyerabend (US 20040246895 A1). Claim(s) 19, 23, 42, and 45 were rejected under 35 U.S.C. 103 as being unpatentable over VAANANEN (USPGPub No. 2007/00585363) in view of Feyerabend (US 20040246895 A1) in view of NATTKEMPER (US 5953318 A). Claim(s) 12-13, 25, 36-37 and 47 were objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. In response to the Non-Final Rejection applicants presented arguments with respect to independent claim(s) 1, 26, 11, 35, 18 and 41. The arguments are addressed below.
Claim(s) 1 and 26
Applicants argue that the prior art of record VAANANEN (USPGPub No. 2007/00585363) in view of VIRDI (US 20060026294 A1) fail to render obvious the subject matter of claim(s) 1 and 26. Specifically Applicants argue that the VAANANEN in view of VIRDI fail to teach and/or suggest “…wherein determining that network congestion is present comprises determining that a number of received packets exceed an output capability of a router…”
In the Non-Final Rejection VAANANEN was found to teach said feature, see where it recites in the Non-Final Rejection,
“wherein the determining that network congestion is present comprises one or more of determining that a number of received packets exceed an output capability of a router (See “[0034]..for example the queue 3 of the aG+E quality class has become congested in the quality class…[0056] In congestion management, the length of the queue or a variable derived from it, such as a low-pass filtered value, is utilized. If the length of the queue and/or its derivate exceeds a threshold value, congestion limitation measures are applied….);”
Applicants argue that VAANANEN fails to teach said feature because,
“Vaananen nowhere describes determining whether the number of received packets exceeds an actual output capability of the router. Tellingly, if the other queues of the transmission link are not being used, the transmission link could still be capable of transmitting packets from a given queue even if the threshold value for that queue has been exceeded. Initiating congestion limitation based on a number of packets in a queue exceeding a preset threshold value as in Vaananen is clearly not equivalent to "determining that a number of received packets exceed an output capability of a router," as recited in claim 1.”
In response to this argument if other queues of the transmission link are not being used, the transmission link could still be capable of transmitting packets from a given queue even if the threshold value for that queue has been exceeded, it is noted that this feature is not claimed. What is claimed is that a number of received packets exceed an output capability of a router. The exceeding an output capability of a router is not necessarily limited to a case where a transmission link is incapable of being used. The Instant Application does not appear to make mention of router being incapable of transmission due to its output capability being exceeded. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e. the transmission link/router being incapable of transmitting packets from a given queue if output capability of router is exceeded) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Furthermore, with respect to detecting an output capability of a router being exceeded the Instant Application states:
“[0076] At decision block 830, the router may determine if network congestion is present. The router may determine it is congested by, for example, determining that the amount of input it is receiving exceeds its available output capability. The router's output capability may be determined per-network link and using any suitable data structure, such as a queue. By determining the amount of input the router has and determining how many packets need to be output, the router may be able to anticipate congestion a short time in the future, e.g., 0-20 milliseconds. If the router determines that it is not congested, then it need not drop any packets and processing may begin again at block 810. However, if the router determines that it is congested, or will soon be congested, it may determine to drop packets to relieve the congestion…”
VAANANEN relies on a data structure such as a queue/traffic flows (see VAANANEN [Fig. 3] which illustrates queues), determining that an amount of input, number of packets in the queues (i.e. such as the arrive packets in [Fig. 3], and determining how many packets need to be output, such as according to a transmission capacity of a link (“[0035] The present invention is intended to eliminate the defects of the state of the art described above and for this purpose create an entirely new type of method and equipment for scheduling transmission link capacity between packet-switched traffic flows. The object of the invention is a method, by means of which a scheduler and congestion management mechanism can be implemented, in such a way that the following properties are achieved: [0036] 1) A specific portion of the capacity of the transmission link can be reserved for traffic representing a specific service level class, and [0037] 2) it is possible to define the weighting coefficient by which each portion of the traffic of the service level class, which exceeds the capacity of the portion of the transmission link reserved for the service level class in question, will compete for the portion of the capacity of the transmission link, which is either not reserved for the use of traffic representing some service level class, or which is reserved but is not being used at the moment in question by traffic entitled to the reservation, and [0038] 3) it is possible to use overbooking in such a way that the reduction in the quality of the service caused by overbooking only affects the service level class, in which overbooking is used (controlled overbooking), and [0039] 4) an increase in the queue length that is detrimental in terms of the traffic-flow control (e.g., using the TCP protocol [6]) can be prevented even in a congestion situation arising from overbooking.”).
Therefore, the argument that VAANANEN (USPGPub No. 2007/00585363) in view of VIRDI (US 20060026294 A1) fails to render obvious claim 1, because the combination fails render obvious the feature wherein the determining that network congestion is present comprises one or more of determining that a number of received packets exceed an output capability of a router is not persuasive.
Claim(s) 11 and 35
Applicants argue that the prior art of record, the combination of VAANANEN (USPGPub No. 2007/00585363) in view of VIRDI (US 20060026294 A1) fail to render obvious claim(s) 11 and 35. More specifically, Applicants refer to claim 11, and argue that VAANANEN fails to teach or suggest,
(1) first grouping information indicating a first threshold associated with dropping of packets of the first group of packets, (2) second grouping information indicating a second threshold associated with dropping of packets of the second group of packets (3) determining, based on determining that network congestion is present, to drop a number of packets of the first group that exceed the first threshold associated with dropping of packets of the first group of packets to ensure that the second threshold associated with dropping of packets of the second group of packets is satisfied, and (4) wherein the determining that network congestion is present comprises determining that a number of received packets exceed an output capability of a router.
Applicants’ arguments are found to be persuasive as neither VAANANEN nor VIRDI was found to teach at least features for determining, based on determining that network congestion is present, to drop a number of packets of the first group that exceed the first threshold associated with dropping of packets of the first group of packets to ensure that the second threshold associated with dropping of packets of the second group of packets is satisfied , as arranged with the remaining elements of claim 11. Therefore, the rejection of Claim(s) 11 under 35 U.S.C. 103 as being unpatentable over VAANANEN (USPGPub No. 2007/00585363) in view of VIRDI (US 20060026294 A1) is withdrawn. Independent claim 35 recite substantially the same features as claim 11, and therefore the rejection of claim(s) 35 under 35 U.S.C. 103 as being unpatentable over VAANANEN (USPGPub No. 2007/00585363) in view of VIRDI (US 20060026294 A1) is withdrawn. The rejection(s) of 12-13, 15-17, and 35-40 under 35 USC 103 are also withdrawn by virtue of dependency on either of claim 11 or claim 35.
Claim(s) 18 and 41
Applicants argue that the prior art of record, the combination of VAANANEN (USPGPub No. 2007/00585363) in view of Feyerabend (US 20040246895 A1) fail to render obvious the subject matter of claim(s) 18 and 41. Specifically Applicants argue that VAANANEN and FEYERABEND fail to render obvious features for (1) determining that a number of the at least one dropped packets of the first group of packets exceed the threshold associated with dropping of packets of the first group of packets; and (2) wherein the determining that network congestion is present comprises determining that a number of received packets exceed an output capability of a router. Applicants’ arguments were found to be persuasive, with respect to the prior art failing to at least teach and/or suggest (1) determining that a number of the at least one dropped packets of the first group of packets exceed the threshold associated with dropping of packets of the first group of packets, Accordingly, the rejection(s) of claim(s) 18 and 41 under 35 USC 103 are withdrawn.
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim(s) 1 and 26 is/are rejected under 35 U.S.C. 103 as being unpatentable over VAANANEN (USPGPub No. 2007/00585363) in view of VIRDI (US 20060026294 A1).
In regards to claim 1, VAANANEN (USPGPub No. 2007/00585363) teaches a method, comprising:
receiving a first group of packets associated (Vaananen [Fig. 1 – Fig. 3], [Par. 21 – Par. 66] teaches receiving a first group of packets (i.e. one of the service level classes such as aG+E, bG+E, and BE and/or one of the subgroup(s) such as a G portion and E portion) and a second group of packets (i.e. another one of the service level classes or subgroups) in queues)
determining that network congestion is present ([Fig. 3] illustrates a determination of network congestion, also see “[0034]..for example the queue 3 of the aG+E quality class has become congested in the quality class…[0056] In congestion management, the length of the queue or a variable derived from it, such as a low-pass filtered value, is utilized. If the length of the queue and/or its derivate exceeds a threshold value, congestion limitation measures are applied….); and
determining, based on determining that network congestion is present, to drop one or more packets of the second group such that a threshold associated with the first group is satisfied ([Par. 0063 – Par. 0065] teaches based on determining that network congestion is present, dropping one or more “E portion” packets such that a threshold associated with the “G portion” is satisfied, no G portion packets are dropped),
wherein the determining that network congestion is present comprises one or more of determining that a number of received packets exceed an output capability of a router (See “[0034]..for example the queue 3 of the aG+E quality class has become congested in the quality class…[0056] In congestion management, the length of the queue or a variable derived from it, such as a low-pass filtered value, is utilized. If the length of the queue and/or its derivate exceeds a threshold value, congestion limitation measures are applied….);
The teachings of VAANANEN (USPGPub No. 2007/00585363) differs from claim 1, in that VAANANEN is silent on the first group of packets being associated with a first video frame and the second group of packets being associated with a second video frame. Despite these differences similar features have been seen other prior art involving congestion management. VIRDI (US 20060026294 A1) [Fig. 5 – Fig. 6] teaches a packet congestion management feature where a first group of packets is associated with a first video frame (B, I, or P) and a second group of packets is associated with a second video frame (another one of B, I, or P frames).
Thus, based upon the teachings of VIRDI it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the congestion management feature of VAANANEN by applying congestion management feature to video frames as similarly seen in the congestion management feature of VIRDI, to thus arrive at claim 1, in order to provide a benefit of congestion management for video packets/frames.
In regards to claim 26, VAANANEN (USPGPub No. 2007/00585363) teaches a method, comprising:
receiving a first group of packets associated (Vaananen [Fig. 1 – Fig. 3], [Par. 21 – Par. 66] teaches receiving a first group of packets (i.e. one of the service level classes such as aG+E, bG+E, and BE and/or one of the subgroup(s) such as a G portion and E portion) and a second group of packets (i.e. another one of the service level classes or subgroups) in queues)
determining that network congestion is present ([Fig. 3] illustrates a determination of network congestion, also see “[0034]..for example the queue 3 of the aG+E quality class has become congested in the quality class…[0056] In congestion management, the length of the queue or a variable derived from it, such as a low-pass filtered value, is utilized. If the length of the queue and/or its derivate exceeds a threshold value, congestion limitation measures are applied….); and
determining, based on determining that network congestion is present, to drop one or more packets of the second group such that a threshold associated with the first group is satisfied ([Par. 0063 – Par. 0065] teaches based on determining that network congestion is present, dropping one or more “E portion” packets such that a threshold associated with the “G portion” is satisfied, no G portion packets are dropped),
wherein the determining that network congestion is present comprises one or more of determining that a throughput associated with a router is exceeded (See “[0034]..for example the queue 3 of the aG+E quality class has become congested in the quality class…[0056] In congestion management, the length of the queue or a variable derived from it, such as a low-pass filtered value, is utilized. If the length of the queue and/or its derivate exceeds a threshold value, congestion limitation measures are applied….);
The teachings of VAANANEN (USPGPub No. 2007/00585363) differs from claim 26, in that VAANANEN is silent on the first group of packets being associated with a first video frame and the second group of packets being associated with a second video frame. Despite these differences similar features have been seen other prior art involving congestion management. VIRDI (US 20060026294 A1) [Fig. 5 – Fig. 6] teaches a packet congestion management feature where a first group of packets is associated with a first video frame (B, I, or P) and a second group of packets is associated with a second video frame (another one of B, I, or P frames).
Thus, based upon the teachings of VIRDI it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the congestion management feature of VAANANEN by applying congestion management feature to video frames as similarly seen in the congestion management feature of VIRDI, to thus arrive at claim 26, in order to provide a benefit of congestion management for video packets/frames.
Claim(s) 2 and 27 is/are rejected under 35 U.S.C. 103 as being unpatentable over VAANANEN (USPGPub No. 2007/00585363) in view of VIRDI (US 20060026294 A1) in view of KUMAR (US 6597919 B1)
In regards to claim(s) 2 and 27, VAANANEN is silent on the method of claim 1, wherein the threshold associated with the first group indicates a maximum number of packets of the first group that can be dropped. Despite these differences similar features have bene seen in other prior art involving congestion management. KUMAR [Col. 4, Line(s) 47– Col. 5, Line(s) 8] teaches a threshold associated with a first group of packets indicates a maximum number of packets of a first group that can be dropped in order to provide a desired quality of service (“(20) In this example, assuming a QoS=2 is included in the request which indicates a desired level of packet drop rate to not exceed 1%. The QoS=2 path is followed to step 320 where the overbooking limit for this QoS is calculated. Assume the site has transport resources for 12 channels and resources are dynamically assigned when traffic is received at the site. The current overbooking level is 110%; that is 110% of 12 channels (or 13 channels) may be assigned. Over the last few minutes, the measured rate of not assigning a resource on demand and thus dropping packets has been 0.1%. Since the system is operating well within the 1% maximum drop rate for QoS=2, the overbooking limit is increased to 120% allowing the acceptance of service requests for 14 channels when only 12 channels exist.”).
Thus based upon the teaching of KUMAR it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the congestion management feature of VAANANEN by adopting use of the threshold feature seen in KUMAR to thus arrive at claim 2, in order to provide a desired quality of service.
Claim(s) 3 and 28 is/are rejected under 35 U.S.C. 103 as being unpatentable over VAANANEN (USPGPub No. 2007/00585363) in view of VIRDI (US 20060026294 A1) in view of LOEB (US 20080130669 A1)
In regards to claim(s) 3 and 28, VAANANEN is silent on the method of claim 1, wherein the threshold associated with the first group indicates a minimum number of packets of the first group that must be delivered. Despite these differences similar features have been seen in other prior art involving congestion management. LOEB teaches a feature where a threshold associated with a first group, CoS, involves a minimum number of packets of the first group that must be delivered, a minimum transmission rate (“[0029] When transmitting outgoing data out a port, such as port 1, switch 12A can allocate bandwidth for each COS queue A-D based on its corresponding priority using any solution, e.g., a weighted time division multiplexing (TDM). In this case, a higher priority queue (e.g., COS queue A) can be allocated a larger portion of the bandwidth, thereby enabling data (e.g., packets) placed on the higher priority queue to be transmitted by switch 12A faster than the data placed on a lower priority queue. Further, switch 12A can enable a maximum/minimum transmission rate for each COS queue A-D for a port to be adjusted. For example, switch 12A may be capable of communicating at 1 Gigabits/second (Gps) out each port 1-4. However, destination node 18A may be simultaneously receiving data from multiple queues for different applications. In this case, destination node 18A can request that switch 12A "reshape" the transmission rates for one or more COS queues A-D to balance the streams for the corresponding applications. For example, destination node 18A may only desire data assigned to COS queue C at a lower communications rate, e.g., 10 Megabits/second (Mps). In this case, switch 12A can "rate shape" COS queue C for port 1 to have its maximum transmission rate set to 10 Mps.”).
Thus, based upon the teaching of LOEB it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the congestion management feature of VAANANEN by adopting use of the threshold feature seen in LOEB to thus arrive at claim 3, in order to provide a desired quality/class of service.
Claim(s) 5 and 29 is/are rejected under 35 U.S.C. 103 as being unpatentable over VAANANEN (USPGPub No. 2007/00585363) in view of VIRDI (US 20060026294 A1) in view of NATTKEMPER (US 5953318 A)
In regards to claim(s) 5 and 29, VAANANEN is silent on the method of claim 1, wherein determining to drop one or more packets of the second group comprises determining to drop all of the packets of the second group. Despite these differences similar features have been seen in other prior art involving congestion management. NATTKEMPER [Col. 11 Line(s) 33 - 55] teaches a feature to determine to drop one or more packets of a second group, low priority, comprises determining to drop all packets of the low priority group (“(64) When the downstream direction is in the L2 congestion mode, then a pool of PPD engines are invoked and the controlling software is required to drive these discard engines to fairly discard between all the active low priority queues in the system. (65) When the downstream direction is in the L3 congestion mode, all cells going to the low priority queue are discarded in all switching units 104.”).
Thus, based upon the teachings of NATTKEMPER it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the congestion management feature of VAANANEN by adopting use of the discarding feature seen in NATTKEMPER to thus arrive at claim 5, in order to provide a prioritized service in light of a congestion condition.
Claim(s) 6 and 30 is/are rejected under 35 U.S.C. 103 as being unpatentable over VAANANEN (USPGPub No. 2007/00585363) in view of VIRDI (US 20060026294 A1) in view of Voruganti (US 8213453 B1)
In regards to claim(s) 6 and 30, VAANANEN is silent on the method of claim 1, wherein determining to drop one or more packets of the second group comprises: determining to drop one or more packets of the second group such that a threshold associated with the second group is satisfied.
Despite these differences similar features have been seen in other prior art involving congestion management. Voruganti (US 8213453 B1) [Col. 5 Line(s) 37 – Col. 6 Line 15] teaches a feature to determine to drop one or more packets of a second group, priority class, such that a threshold associated with the second group is satisfied, maximum acceptable packet drop rate(“(37) In this example, GUI 500 provides a number of fields that the user can use to enter QoS configuration information. "Maximum latency" field 510 and "Maximum Portion Dropped Packets" field 520 may be used to directly enter values that define the maximum acceptable latency and the maximum acceptable packet drop rate for a particular service or priority class of the traffic. These values may be applied to a particular service (e.g., Voice over IP (VoIP) or file transfer protocol (FTP)) or priority class, which may be entered in "service" field 530. In this example, the user has entered a maximum latency of 100 milli-seconds (ms), a maximum drop rate of 10%, and that these two parameters should be applied to VoIP traffic. In other words, the user desires that VoIP traffic have a latency of 100 ms or less and that no more than 10% of the VoIP packets be dropped.”).
Thus, based upon the teachings of Voruganti it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the congestion management feature of VAANANEN by adopting use of the discarding feature seen in Voruganti to thus arrive at claim 6, in order to provide a desired quality/class of service.
Claim(s) 7-10 and 31-34 is/are rejected under 35 U.S.C. 103 as being unpatentable over VAANANEN (USPGPub No. 2007/00585363) in view of VIRDI (US 20060026294 A1) in view of McConnell (US 6108307 A)
In regards to claim(s) 7 and 31, VAANANEN is silent on the method of claim 1, wherein determining to drop one or more packets of the second group comprises: determining that a second threshold associated with the delivery of packets of the second group is not satisfied; and determining, based on determining the second threshold is not satisfied, to drop all of the packets of the second group. Despite these differences similar features have been seen in other prior art involving congestion management. McConnell (US 6108307 A) [Col. 6, Line(s) 50 - 64] teach a feature to determine to drop one or more packets of a second group (i.e. whereby all discard eligible traffic having the DE bit set ) comprises determining that a second threshold associated with delivery of packets of the second group is not satisfied, severe congestion threshold, and determining, based on determining the second threshold is not satisfied, to drop all packets of the second group (“(12) Each of the queues 50, 52, 54, 56 which reflects a predetermined priority level has congestion thresholds applied to it. The congestion thresholds need not be the same for each of the queues. In the preferred embodiment, three congestion thresholds are specified for each queue. The first threshold is the mild congestion threshold (MCT), whereby the explicit congestion notification bits (BECN and FECN) will be set in the Frame Relay header of all dispatched frames. The second threshold is the severe congestion threshold (SCT), whereby all discard eligible traffic having the DE bit set in the Frame Relay header will be discarded from the queue. The third and final congestion threshold is the absolute congestion threshold (ACT), whereby no additional frames will be accepted into a queue while it is absolutely congested.”).
Thus, based upon the teachings of McConnell it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the congestion management feature of VAANANEN by adopting use of the discarding feature seen in McConnell to thus arrive at claim 7, in order to provide a desired quality/class of service in light of a congestion condition.
In regards to claim(s) 8 and 32, VAANANEN is silent on the method of claim 1, wherein the first group of packets is further associated with instructions to be performed if the threshold associated with the first group is satisfied. Despite these differences similar features have been seen in other prior art involving congestion management. McConnell (US 6108307 A) [Col. 6, Line(s) 50 - 64] teach a feature to determine a feature where a first group of packets, packets with DE bit set, is further associated with instructions to be performed if a threshold associated with a first group is satisfied, severe congestion threshold (“(12) Each of the queues 50, 52, 54, 56 which reflects a predetermined priority level has congestion thresholds applied to it. The congestion thresholds need not be the same for each of the queues. In the preferred embodiment, three congestion thresholds are specified for each queue. The first threshold is the mild congestion threshold (MCT), whereby the explicit congestion notification bits (BECN and FECN) will be set in the Frame Relay header of all dispatched frames. The second threshold is the severe congestion threshold (SCT), whereby all discard eligible traffic having the DE bit set in the Frame Relay header will be discarded from the queue. The third and final congestion threshold is the absolute congestion threshold (ACT), whereby no additional frames will be accepted into a queue while it is absolutely congested.”).
Thus, based upon the teachings of McConnell it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the congestion management feature of VAANANEN by adopting use of the discarding feature seen in McConnell to thus arrive at claim 8, in order to provide a desired quality/class of service in light of a congestion condition.
In regards to claim(s) 9 and 33, VAANANEN is silent on the method of claim 8, wherein the instructions to be performed comprises an instruction to drop all of the packets of the first group. Despite these differences similar features have been seen in other prior art involving congestion management. McConnell (US 6108307 A) [Col. 6, Line(s) 50 - 64] teach a feature to determine a feature where a first group of packets, packets with DE bit set, is further associated with instructions to be performed if a threshold associated with a first group is satisfied, severe congestion threshold, the instruction being to drop all DE marked packets (“(12) Each of the queues 50, 52, 54, 56 which reflects a predetermined priority level has congestion thresholds applied to it. The congestion thresholds need not be the same for each of the queues. In the preferred embodiment, three congestion thresholds are specified for each queue. The first threshold is the mild congestion threshold (MCT), whereby the explicit congestion notification bits (BECN and FECN) will be set in the Frame Relay header of all dispatched frames. The second threshold is the severe congestion threshold (SCT), whereby all discard eligible traffic having the DE bit set in the Frame Relay header will be discarded from the queue. The third and final congestion threshold is the absolute congestion threshold (ACT), whereby no additional frames will be accepted into a queue while it is absolutely congested.”).
Thus, based upon the teachings of McConnell it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the congestion management feature of VAANANEN by adopting use of the discarding feature seen in McConnell to thus arrive at claim 9, in order to provide a desired quality/class of service in light of a congestion condition.
In regards to claim(s) 10 and 34, VAANANEN is silent on the method of claim 8, wherein the instructions to be performed comprise an instruction to send a notification to at least one of a second of the first group of packets or a receiver of the first group of packets. Despite these differences similar features have been seen in other prior art involving congestion management. McConnell (US 6108307 A) [Col. 4, Line(s) 21-43] and [Col. 6, Line(s) 50 - 64] teach a feature to determine a feature where a first group of packets, packets with DE bit set, is further associated with instructions to be performed if a threshold associated with a first group is satisfied, severe congestion threshold, the instruction being to a send a notification, backward explicit congestion notification, to a receiver of a first group of packets (“(3) Three bits in the address field 15 are of particular importance for congestion management and control purposes. The Discard Eligibility (DE) bit 38 is set to a value of 1 to indicate a request that a frame should be discarded in preference to other frames in a congestion situation, whenever such frames must be discarded to ensure safe network operation and maintain a committed level of service within the network. The Backward Explicit Congestion Notification (BECN) bit 40 may be set by a congested network to notify the user that congestion avoidance procedures should be initiated for traffic in the opposite direction of the transmitted frame. The BECN bit is set to 1 to indicate to the receiving user device that the frame it transmits may encounter congested resources. This bit may therefore be used with source-controlled transmitter rate adjustment schemes…(12) Each of the queues 50, 52, 54, 56 which reflects a predetermined priority level has congestion thresholds applied to it. The congestion thresholds need not be the same for each of the queues. In the preferred embodiment, three congestion thresholds are specified for each queue. The first threshold is the mild congestion threshold (MCT), whereby the explicit congestion notification bits (BECN and FECN) will be set in the Frame Relay header of all dispatched frames. The second threshold is the severe congestion threshold (SCT), whereby all discard eligible traffic having the DE bit set in the Frame Relay header will be discarded from the queue. The third and final congestion threshold is the absolute congestion threshold (ACT), whereby no additional frames will be accepted into a queue while it is absolutely congested.”).
Thus, based upon the teachings of McConnell it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the congestion management feature of VAANANEN by adopting use of the discarding feature seen in McConnell to thus arrive at claim 10, in order to provide a desired quality/class of service in light of a congestion condition.
Allowable Subject Matter
Claim(s) 11-13, 15-17, 18-20, 22-25, and 35-47 are allowed.
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 TARELL A HAMPTON whose telephone number is (571)270-7162. The examiner can normally be reached 9:00 AM - 5:00 PM.
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, Ayaz Sheikh can be reached at 5712723795. 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.
/TARELL A HAMPTON/Examiner, Art Unit 2476 /AYAZ R SHEIKH/Supervisory Patent Examiner, Art Unit 2476
Prosecution Insights