Response to an Amendment
This office action is a response to a communication made on 01/06/2026.
Claims 1-18 are canceled.
Claims 19-38 are pending for this application.
Response to Arguments
Applicant: Applicant's arguments, see remarks on page 7-9, filed 01/06/2026, applicant argues that, “Harkous fails to disclose adaptively controlling a maximum queue-size and a minimum queue-size of the virtual queue system as a function of a measured traffic rate of the incoming traffic flow, a current congestion level of the virtual queue system, an estimated traffic rate of the outgoing traffic flow, and a queue-size of the real queue system” recited in claim 19.
Examiner: Applicant's arguments filed 01/06/2026 have been fully considered but they are not persuasive. Examiner respectfully disagrees.
Harkous teaches adaptively controlling a maximum queue-size and a minimum queue-size of the virtual queue system as a function of a measured traffic rate of the incoming traffic flow, a current congestion level of the virtual queue system, an estimated traffic rate of the outgoing traffic flow, and a queue-size of the real queue system because page-2861, left col, II. 41-43, teaches queue using either data plane primitives or control plane commands to dynamically modify (i.e. adaptive controlling) the schedule status of queues, page -2863, section B. Implementation, II. 3-6, teaches apply rate limiting and queue management per slice (i.e. a maximum queue-size and a minimum queue-size of the virtual queue system as a function of a measured traffic rate), according to the type and version of the transport protocol used and application requirements, page-2864, left column, II. 5-12, teaches this delay, along with the average packet size and the rate limit (i.e. a maximum throughput) given in the SLA, is used to derive the burst limit. If the size of the vQueue, augmented by the transmission delay of the packet (T_DELAY), exceeds the burst size (C_DELAY) then the packet is dropped, else the vQueue size is incremented by the transmission delay of the packet (lines 25-29). In any case, the delay register is updated accordingly (line 30), page-2865, II. 30-39 -page 2866, II. 1, teaches all Traffic is sent to the same physical queue at the switch’s egress port where the size is set high enough (e.g., 200,000 packets) to ensure that congestion control is only performed by the queue management algorithm at the virtual queues. We measure the throughput and delay over time for the virtual queue per slice and the physical queue. Measurements are taken after 50 seconds from the start of the experiment, to capture only the steady-state and span over an interval of 250 seconds. We capture the packets at the outgoing switch-to-client interface, page-2869, Section B. Guaranteed performance targets usings vQueues: teaches we can calculate the maximum real queuing delay (worst case scenario) for each slice. The maximum busy period tsi for every slice s with priority i can be estimated based on its burst limit bs i (in bytes), and the residual capacity ri of the bottleneck for priority i as following: tsi = bs i/ ri, page -2870, section C. Packet processing latency: teaches we examine the impact of different actions taken by each P4 implementation on packet processing latency, by configuring the two traffic management implementations at rates equal to 2.3 Gbps and 5 Gbps to be smaller (Mark Action) and greater (No-Mark Action) than the 2.4 Gbps generated traffic rate. We made sure that no packets are dropped by the traffic management mechanisms as this will disrupt the packet latency measurements. This was achieved by arbitrarily increasing the dropping burst size, and by minimizing the difference between the limited rate in the Mark-Action case, i.e., 2.3 Gbps, and the sent rate, i.e., 2.4 Gbps, to make sure that drop burst threshold is never reached (no packet is dropped).
Applicant: Applicant's arguments, see remarks on page 9-10, filed 01/06/2026, applicant argues that, “Harkous fails to disclose the congestion is represented by a lower congestion threshold value and an upper congestion threshold value, and wherein the maximum queue-size is adaptively controlled to limit the virtual delay to not exceed the upper congestion threshold value” recited in claim 21.
Examiner: Applicant's arguments filed 01/06/2026 have been fully considered but they are not persuasive. Examiner respectfully disagrees.
Harkous teaches wherein the maximum queue-size is a function of previous values of the maximum queue-size that are larger than a lower limit maximum queue-size threshold value, and wherein the function only considers previous values of the maximum queue-size within a time window because page-2861, left col, II. 41-43, teaches queue using either data plane primitives or control plane commands to dynamically modify (i.e. adaptive controlling) the schedule status of queues, page -2863, section B. Implementation, II. 3-6, teaches apply rate limiting and queue management per slice (i.e. a maximum queue-size and a minimum queue-size of the virtual queue system as a function of a measured traffic rate), according to the type and version of the transport protocol used and application requirements, page-2863, right column, II. 10-12, teaches using (i) the slice_ts register that stores the global timestamp of the previous packet for the slice at the control block (lines 7-13), page-2864, left column, II. 5-12, teaches this delay, along with the average packet size and the rate limit (maximum throughput) given in the SLA, is used to derive the burst limit. If the size of the vQueue, augmented by the transmission delay of the packet (T_DELAY), exceeds the burst size (C_DELAY) then the packet is dropped, else the vQueue size is incremented by the transmission delay of the packet (lines 25-29). In any case, the delay register is updated accordingly (line 30), page-2867, left column, II. 14-20, teaches the DCTCP flows (slice DC) are being controlled at the target rate and around the 5ms marking threshold (Table II). As packets are marked and not discarded, the DCTCP flows average virtual queue delay can exceed the 5ms marking threshold. The extra 15ms virtual queue size is required to minimize packet drops, which sporadically still happens when this threshold is exceeded, page -2870, section C. Packet processing latency: teaches we examine the impact of different actions taken by each P4 implementation on packet processing latency, by configuring the two traffic management implementations at rates equal to 2.3 Gbps and 5 Gbps to be smaller (Mark Action) and greater (No-Mark Action) than the 2.4 Gbps generated traffic rate. We made sure that no packets are dropped by the traffic management mechanisms as this will disrupt the packet latency measurements. This was achieved by arbitrarily increasing the dropping burst size, and by minimizing the difference between the limited rate in the Mark-Action case, i.e., 2.3 Gbps, and the sent rate, i.e., 2.4 Gbps, to make sure that drop burst threshold is never reached (no packet is dropped).
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 19, 21, 25, 27-32, 34 and 37-38 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by HARKOUS, HASANIN, et al. ,"Virtual Queues for P4: A Poor Man's Programmable Traffic Manager’, IEEE Transactionson Network and Service Management, Volume 18, Number 3, September 2021, 2860-2872, hereinafter “Harcous”. Harcous cited in applicant IDS filed 05/17/2024.
With respect to claim 19, Harcous discloses a method for controlling queue-size of a virtual queue system for an incoming traffic flow of packets (page-2862, section A. Design, line 24-26, and II. 29-33, teaches the VLAN tag of incoming traffic can be used as DP_SID similar to [32]… 2) Virtual Queue Based Traffic Management: A vQueue (virtual Queue) is a mechanism used to model the length),
wherein the incoming traffic flow of packets is by a scheduler scheduled for user equipment as an outgoing traffic flow (Page-2861, section: II related work, II. 18-22, teaches scheduler that can implement variants of priority scheduling and ideal fair queuing at line rate using a Push-In-First-Out (PIFO) priority queue. PIFO allows packets to be enqueued into an arbitrary location in the queue (thus enabling programmable packet scheduling, See Fig. 4, teaches client device as user equipment device),
wherein the virtual queue system is configured to represent a real queue system of the scheduler by estimating a virtual delay for the packets (page-2862, section A. Design, II. 29-33, teaches 2) Virtual Queue Based Traffic Management: A vQueue (virtual Queue) is a mechanism used to model the length, or as in our case the sojourn latency, of the queue, as if the packets arriving at the real queue were served by a link with a capacity lower than the actual capacity of the link, page-2865, section: Experiments, measurements & Evaluation metrics, II. 12-13, teaches measure the throughput and delay over time for the virtual queue per slice and the physical queue), the virtual delay being estimated by measuring the incoming traffic flow and estimating the outgoing traffic flow (page-2863, section: B. Implementation, Listing 1, line 19, Update delay, the delay register holding the slice’s virtual queue size (line 19)) ,
wherein the method is performed by a network node (page 2860, right column, II. 11-12 teaches network devices as network node), and wherein the method comprises:
adaptively controlling a maximum queue-size and a minimum queue-size of the virtual queue system as a function of a measured traffic rate of the incoming traffic flow, a current congestion level of the virtual queue system, an estimated traffic rate of the outgoing traffic flow, and a queue-size of the real queue system (page-2861, left col, II. 41-43, teaches queue using either data plane primitives or control plane commands to dynamically modify (i.e. adaptive controlling) the schedule status of queues, page -2863, section B. Implementation, II. 3-6, teaches apply rate limiting and queue management per slice (i.e. a maximum queue-size and a minimum queue-size of the virtual queue system as a function of a measured traffic rate), according to the type and version of the transport protocol used and application requirements, page-2864, left column, II. 5-12, teaches this delay, along with the average packet size and the rate limit (i.e. a maximum throughput) given in the SLA, is used to derive the burst limit. If the size of the vQueue, augmented by the transmission delay of the packet (T_DELAY), exceeds the burst size (C_DELAY) then the packet is dropped, else the vQueue size is incremented by the transmission delay of the packet (lines 25-29). In any case, the delay register is updated accordingly (line 30), page-2865, II. 30-39 -page 2866, II. 1, teaches all Traffic is sent to the same physical queue at the switch’s egress port where the size is set high enough (e.g., 200,000 packets) to ensure that congestion control is only performed by the queue management algorithm at the virtual queues. We measure the throughput and delay over time for the virtual queue per slice and the physical queue. Measurements are taken after 50 seconds from the start of the experiment, to capture only the steady-state and span over an interval of 250 seconds. We capture the packets at the outgoing switch-to-client interface, page-2869, Section B. Guaranteed performance targets usings vQueues: teaches we can calculate the maximum real queuing delay (worst case scenario) for each slice. The maximum busy period tsi for every slice s with priority i can be estimated based on its burst limit bs i (in bytes), and the residual capacity ri of the bottleneck for priority i as following: tsi = bs i/ ri, page -2870, section C. Packet processing latency: teaches we examine the impact of different actions taken by each P4 implementation on packet processing latency, by configuring the two traffic management implementations at rates equal to 2.3 Gbps and 5 Gbps to be smaller (Mark Action) and greater (No-Mark Action) than the 2.4 Gbps generated traffic rate. We made sure that no packets are dropped by the traffic management mechanisms as this will disrupt the packet latency measurements. This was achieved by arbitrarily increasing the dropping burst size, and by minimizing the difference between the limited rate in the Mark-Action case, i.e., 2.3 Gbps, and the sent rate, i.e., 2.4 Gbps, to make sure that drop burst threshold is never reached (no packet is dropped).).
For claim 32, it is an apparatus claim corresponding to the method of claim 1. Therefore claim 32 is rejected under the same ground as claim 1.
For claim 38, it is a non-transitory computer readable storage medium claim corresponding to the method of claim 1. Therefore claim 38 is rejected under the same ground as claim 1.
With respect to claims 21 and 34, Harcous discloses the method according to claim 19, wherein the congestion is represented by a lower congestion threshold value and an upper congestion threshold value, and wherein the maximum queue-size is adaptively controlled to limit the virtual delay to not exceed the upper congestion threshold value (Harcous, page-2861, left col, II. 41-43, teaches queue using either data plane primitives or control plane commands to dynamically modify (i.e. adaptive controlling) the schedule status of queues, page-2864, left column, II. 13-20, teaches Assuming the use of TCP congestion control systems, if the TCP version at flow level supports Explicit Congestion Notification (ECN) functionality and the drop burst limit (C_DELAY) has not been reached, the packet is ECN-marked when the virtual queue delay exceeds the marking burst limit M_DELAY limit, indicating congestion (lines 32-34). For more complex schemes, each AQM can be a separate action, page-2867, left column, II. 14-20, teaches the DCTCP flows (slice DC) are being controlled at the target rate and around the 5ms marking threshold (Table II). As packets are marked and not discarded, the DCTCP flows average virtual queue delay can exceed the 5ms marking threshold. The extra 15ms virtual queue size is required to minimize packet drops, which sporadically still happens when this threshold is exceeded, page -2870, section C. Packet processing latency: teaches we examine the impact of different actions taken by each P4 implementation on packet processing latency, by configuring the two traffic management implementations at rates equal to 2.3 Gbps and 5 Gbps to be smaller (Mark Action) and greater (No-Mark Action) than the 2.4 Gbps generated traffic rate. We made sure that no packets are dropped by the traffic management mechanisms as this will disrupt the packet latency measurements. This was achieved by arbitrarily increasing the dropping burst size, and by minimizing the difference between the limited rate in the Mark-Action case, i.e., 2.3 Gbps, and the sent rate, i.e., 2.4 Gbps, to make sure that drop burst threshold is never reached (no packet is dropped).
With respect to claims 25 and 37, Harcous discloses the method according to claim 19, wherein the maximum queue-size is a function of previous values of the maximum queue-size that are larger than a lower limit maximum queue-size threshold value, and wherein the function only considers previous values of the maximum queue-size within a time window (Harcous, page-2863, right column, II. 10-12, teaches using (i) the slice_ts register that stores the global timestamp of the previous packet for the slice at the control block (lines 7-13), page-2864, left column, II. 5-12, teaches this delay, along with the average packet size and the rate limit (maximum throughput) given in the SLA, is used to derive the burst limit. If the size of the vQueue, augmented by the transmission delay of the packet (T_DELAY), exceeds the burst size (C_DELAY) then the packet is dropped, else the vQueue size is incremented by the transmission delay of the packet (lines 25-29). In any case, the delay register is updated accordingly (line 30).
With respect to claim 27, Harcous discloses the method according to claim 19, wherein, whenever any of the packets is marked as congested, the maximum queue-size is equal to a current queue-size of the virtual queue system (Harcous, page-2863, right column, II. 6-10, teaches the vQueue per slice is described in Listing 1. For the sake of brevity, we assume equal-sized packets and use a packet transmission time parameter to define the rate. The algorithm can easily be updated to use byte transmission time instead, taking packet size into account, page-2868, left column, II. 8-12, teaches the DCTCP flows (slice DC) in Fig. 9(d)a are fluctuating around the 5ms marking threshold, similar to BMv2. In this case, however, DCTCP traffic fills the virtual queue, since congestion control (via marking) takes a few RTT to respond and reduce the rate to the target value).
With respect to claim 28, Harcous discloses the method according to claim 19, wherein the real queue system has a queue-size, and wherein the minimum queue-size is equal to the queue-size of the real queue system or to a configured parameter (Haecous, page-2863, right column, II. 6-10, teaches the vQueue per slice is described in Listing 1. For the sake of brevity, we assume equal-sized packets and use a packet transmission time parameter to define the rate. The algorithm can easily be updated to use byte transmission time instead, taking packet size into account, page-2868, section: 3) Experiment 3-BMv2 Performance Isolation With Over-utilized link, II. 12-14, teaches As the real rate limit is lower than the sum of the virtual rate limiters, the real queue delays need to be also controlled).
With respect to claim 29, Harcous discloses the method according to claim 19, wherein the real queue system has a queue-delay, and wherein the minimum queue-size is equal to a product of the queue-delay of the real queue system and the estimated traffic rate of the outgoing traffic flow (Haecous, page-2863, right column, II. 6-10, teaches the vQueue per slice is described in Listing 1. For the sake of brevity, we assume equal-sized packets and use a packet transmission time parameter to define the rate. The algorithm can easily be updated to use byte transmission time instead, taking packet size into account, page-2868, right column, II. 4-8, teaches we observe that the QoS requirements of the two high priority slices are supported, while we observe a decrease in throughput and an increase in the packets’ real queue delay for the low priority one (Peering Slice) which however remains within the pre-defined bound (30 ms)).
With respect to claim 30, Harcous discloses the method according to claim 29, wherein the product of the queue-delay of the real queue system and the estimated traffic rate of the outgoing traffic flow is scaled with a scaling factor #1 (Harcous, page-2863, right column, II. 6-10, teaches the vQueue per slice is described in Listing 1. For the sake of brevity, we assume equal-sized packets and use a packet transmission time parameter to define the rate. The algorithm can easily be updated to use byte transmission time instead, taking packet size into account, Page-2865, right column, II. 6-12, teaches to match the throughput capabilities of the forwarding devices, which are relatively restricted especially in the case of the BMv2 reference software switch,1 we have down-scaled the aggregated slices’ rate limit (approximately threefold decrease for the BMv2 switch and the SmartNIC whose line rates are 1Gbps and 10Gbps respectively, page-2868, right column, II. 4-8, teaches we observe that the QoS requirements of the two high priority slices are supported, while we observe a decrease in throughput and an increase in the packets’ real queue delay for the low priority one (Peering Slice) which however remains within the pre-defined bound (30 ms)) .
With respect to claim 31, Harcous discloses the method according to claim 19, wherein the minimum queue-size is a function of previous values of the minimum queue-size that are larger than a lower limit minimum queue-size threshold value, and wherein the function only considers previous values of the minimum queue-size within a time window (Harcous, page-2863, right column, II. 10-12, teaches using (i) the slice_ts register that stores the global timestamp of the previous packet for the slice at the control block (lines 7-13), page-2863, left column, teaches in Fig. 3, delay-sensitive traffic from Slice 1 can be prioritized to traffic from Slice 2 and Slice 3 and forwarded with minimum delay. The need to apply different priorities or the opportunity to share priorities will depend on how slice rate limits relate to the worst case real bandwidth limit available left and latency caused by other higher and equal priority slices).
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.
Claim(s) 20, 26 and 33 is/are rejected under 35 U.S.C. 103 as being unpatentable over Harcous in view of BRISCOE, BOB, "The Native AQM for L4S Traffic", Technical Report, arXiv: 190407079v1, 15 Apr 2019, 1-9, hereinafter “Briscoe”. Briscoe cited in applicant IDS filed 05/17/2024.
With respect to claims 20 and 33, Harcous discloses the method according to claim 19, however Harcous remain silent on wherein the incoming traffic flow is a low-latency, low-loss, scalable throughput (L4S) traffic flow.
Briscoe discloses wherein the incoming traffic flow is a low-latency, low-loss, scalable throughput (L4S) traffic flow (page-1, Section: introduction, II. 2-4, teaches provide a Low Latency, Low Loss and Scalable throughput (L4S) service that would be usable for all Internet traffic, see page-3, section: 2.2).
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Harcous’s incoming traffic with low-latency, low-loss, scalable throughput (L4S) traffic flow of Briscoe, in order to improve responsiveness for these applications, allow endpoints to reduce send rate before loss occurs, keeping the link nearly loss free and throughput scales efficiently as available bandwidth increases (Briscoe).
With respect to claim 26, HarCous in view of Briscoe discloses the method according to claim 20, wherein the estimated traffic rate of the outgoing traffic flow is a function of at least one of: power headroom reports, channel quality information reports, radio conditions of the user equipment to which the L4S traffic flow is to be scheduled, number user equipment to which the L4S traffic flow is to be scheduled, or total share of resources available to be scheduled for the user equipment to which the L4S traffic flow is to be scheduled (Harcous, Section: introduction, teaches rate control and Active Queue Management (AQM) to reduce network congestion and/or scheduling to provide Quality of Service (QoS), Briscoe, page-3, Section 2.2. VQ as the Native L4S AQM, left column, teaches the total link capacity with the same congestion window for each ow (Classic and L4S). Equivalently, one can consider that the coupled marking causes the L4S ows not to utilize nC (nL+nC) of the capacity, while the level of L4S marking behaves as if the nL L4S ows are using fraction nL (nL +nC) of the total link capacity…the flow rate of an L4S congestion control is RTT-independent, which is one of the TCP Prague requirements, and has been shown to).
Claim(s) 22-24 and 35-36 is/are rejected under 35 U.S.C. 103 as being unpatentable over Harcous in view of Anand et al. (US 2014/0105218 A1), hereinafter “Anand”.
With respect to claims 22 and 35, Harcous discloses the method according to claim 21, however Harcous remain silent on wherein the maximum queue-size is a product of the upper congestion threshold value and the estimated traffic rate of the outgoing traffic flow.
Anand discloses wherein the maximum queue-size is a product of the upper congestion threshold value and the estimated traffic rate of the outgoing traffic flow (¶0043, teaches quantized values are utilized to determine maximum queue threshold (i.e. maximum queue size) and minimum queue threshold for a given queue or for each queue… A queue maximum threshold value can be a maximum occupancy allowed for that queue at the given queue bandwidth utilization level for a particular queue profile and at the certain level of used up buffer resource, ¶0050, teaches The raw bandwidth utilization can be calculated by determining the amount of data that passed through a queue since the last calculation, ¶0060, teaches the packets are queued onto the output ports, from where they are scheduled out at a rate of one packet per cycle).
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Harcous’s the average packet size and the rate limit (maximum throughput) with wherein the maximum queue-size is a product of the upper congestion threshold value and the estimated traffic rate of the outgoing traffic flow of Anand, in order to ensure latency based dynamic buffer sizing (Anand).
With respect to claims 23 and 36, Harcous in view of Anand discloses the method according to claim 22, wherein the product of the upper congestion threshold value and the estimated traffic rate of the outgoing traffic flow is low-pass filtered (Anand, ¶0043, teaches quantized values are utilized to determine maximum queue threshold (i.e. maximum queue size) and minimum queue threshold for a given queue or for each queue… A queue maximum threshold value can be a maximum occupancy allowed for that queue at the given queue bandwidth utilization level for a particular queue profile and at the certain level of used up buffer resource, ¶0050, teaches the raw bandwidth utilization can be calculated by determining the amount of data that passed through a queue since the last calculation. the noise in this sampling can be removed by passing the results through a low pass filter. In a further embodiment, a moving average is calculated from the results of the low pass filter. ¶0060, teaches the packets are queued onto the output ports, from where they are scheduled out at a rate of one packet per cycle).
With respect to claims 24 and 36, Harcous in view of Anand discloses the method according to claim 22, wherein the product of the upper congestion threshold value and the estimated traffic rate of the outgoing traffic flow is scaled with a scaling factor >1 (Anand, ¶0021, teaches the time scale of the occurrence of data traffic congestion is very small and the response to these situations has to be very fast, ¶0040, teaches If the value of N gets to high, it will react to congestion very slowly. Value of N can be chosen to influence this relationship. ¶0043, teaches quantized values are utilized to determine maximum queue threshold (i.e. maximum queue size) and minimum queue threshold for a given queue or for each queue… A queue maximum threshold value can be a maximum occupancy allowed for that queue at the given queue bandwidth utilization level for a particular queue profile and at the certain level of used up buffer resource).
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 GOLAM MAHMUD whose telephone number is (571)270-0385. The examiner can normally be reached Mon-Fri 8.00-5.00pm.
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, Umar Cheema can be reached at 5712703037. 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.
/G.M/Examiner, Art Unit 2458
/UMAR CHEEMA/Supervisory Patent Examiner, Art Unit 2458
Prosecution Insights