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 .
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.
DETAILED ACTION
This communication is in response to Application No. 18/677,030 filed on 29 May 2024 and arguments presented on 18 June 2026, are hereby acknowledged. Claims 1-11 are pending and subject to examination.
Response to Arguments
On pages 6-8 of the response filed 18 June 2026, Applicant's addresses the 35 U.S.C. § 102/35 U.S.C. § 103 rejection made on the 18 March 2026 Non-Final Rejection. Applicant's arguments, regarding the rejection under 35 U.S.C. § 102/35 U.S.C. § 103, have been fully considered.
Claim Rejections - 35 U.S.C. § 102
On page 6, Applicant argues that Zhang does not disclose at least following highlighted features of independent claim 1 “determining, by the computing device and based on the label, a decreased rate at which to send the at least one first packet to a server device; and sending the at least one first packet to the server device based on the decreased rate” as recited in Independent claim 1.
Applicant's arguments based on premises that Zhang does not disclose that the proxy device determines "a decreased rate at which to send the at least one first packet to a server device" or sends "the at least one first packet to the server device based on the decreased rate." To the extent that Zhang discloses a "decreased rate," such a decreased rate refers to the rate at which the proxy device transmits data to the user device-not to the server device. While Zhang does describe that the proxy device can control a transmit rate "associated with" the server device, this transmit rate "associated with" the server device is the server's transmit rate (i.e., the rate at which the server device transmits information). In other words, the transmit rate "associated with" the server device is the rate at which packets are sent from the server device-not the rate at which packets are sent to the server device. Accordingly, Zhang does not disclose "determining, by the computing device and based on the label, a decreased rate at which to send the at least one first packet to a server device," and "sending the at least one first packet to the server device based on the decreased rate," as claimed.
Examiner respectfully disagrees and finds this argument unpersuasive. The courts have explicitly stated that the prior art need not be solving the same problem as the applicant. SeeKSR Int'l Co. V. Teleflex, Inc., 550 U.S. 398 (2007). For example, one may arrive at identical claimed invention by solving a completely different problem. See in re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed.Cir. 1986).
Specifically, the examiner cited prior art ZHANG discloses "determining, by the computing device and based on the label, a decreased rate at which to send the at least one first packet to a server device," and "sending the at least one first packet to the server device based on the decreased rate," as claimed in independent claim 1.
ZHANG discloses "determining, by the computing device and based on the label, a decreased rate at which to send the at least one first packet to a server device” as claimed in independent claim 1.
ZHANG describes a user device, a proxy device or cloud computing device and server and a proxy device or cloud computing device may provide the traffic to server device 240 (e.g., via network). The proxy server or cloud computing device receive from a user device a flow which includes a packet. user device 205 may set one or more flags (e.g., control bits) in a TCP or IP header (e.g., a congestion window reduced (CWR) flag, an ECN-echo (ECE) flag, an ECN capable (ECT) flag, a congestion encountered (CE) flag, or the like). Additionally, or alternatively, proxy device 230 may determine the condition information based on the one or more flags in the TCP or IP headers (ZHANG: [paragraph 0010, 0051]). ZHANG further discloses the proxy server or cloud computing device may perform an action by applying standard TCP parameter values (e.g., congestion window values, receive window values, etc.) to flows which may not accurately correspond to underlying network conditions, thereby resulting in unnecessary congestion mitigation actions and flows which may include a sequence of packets. proxy device or cloud computing device may separately control a rate of traffic transmission between proxy device 230 230 and server device 240 (ZHANG: [paragraph 0013-0015, 0026, 0043]). ZHANG discloses proxy device 230 or cloud computing device may perform the action based on adjusting a transmit rate associated with the first flow. For example, proxy device 230 or cloud computing device may perform the action in association with and determining a decrease transmit rate of traffic. The proxy device 230 or cloud computing device may perform the action based on adjusting a transmit rate associated with the first flow and instruct server device 240 to adjust a transmit rate based on the condition information (ZHANG: [paragraph 0051, 0076]). ZHANG discloses determining by the proxy device or the cloud computing device may adjust or decrease the transmission rate at which to send the first flow associated with the packet to a server device according to the user device is experiencing network congestion information based on the one or more flags (e.g. label) in the header data (ZHANG: [paragraph 0013-0015, 0051, 0063, 0076, 0083]). Thus, ZHANG still teaches "determining, by the computing device and based on the label, a decreased rate at which to send the at least one first packet to a server device” as claimed.
ZHANG further discloses "sending the at least one first packet to the server device based on the decreased rate," as claimed in independent claim 1.
ZHANG discloses The proxy device 230 or cloud computing device may perform the action based on adjusting a transmit rate associated with the first flow and instruct (e.g. sending) server device 240 to adjust a transmit rate based on the condition information (ZHANG: [paragraph 0051, 0076]). ZHANG discloses The proxy device 230 or cloud computing device may perform the action based on adjusting a transmit rate associated with the first flow and The proxy device 230 or cloud computing device transmitting the first flow associated with the packet to the server device based on decrease the transmission rate and increasing the efficiency of a connection and/or reducing network congestion (ZHANG: [paragraph 0063, 0076, 0083, 0087]). Thus, ZHANG still teaches "sending the at least one first packet to the server device based on the decreased rate," as claimed. Therefore. ZHANG still discloses “determining, by the computing device and based on the label, a decreased rate at which to send the at least one first packet to a server device; and sending the at least one first packet to the server device based on the decreased rate” as recited by Independent claim 1.Therefore, Applicant’s arguments are unpersuasive. Therefore, the rejection of claim 1 is hereby maintained.
Dependent claims 2-11
Applicant’s argues these claims conditionally based upon arguments presented for their parent claim(s). Applicant’s arguments are unpersuasive and therefore, the rejections of these claims 2-11 are hereby maintained.
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.
Claims 1-3, 6 and 9-11 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by ZHANG et al. (US 2018/0091999 A1).
Regarding claim 1, ZHANG discloses a method comprising: receiving, by a computing device and from a user device, at least one first packet comprising first header data ([paragraph 0025-0027] describes user device, proxy device such as a cloud computing device and a server device [paragraph 0043, 0051] describes receiving by proxy device such as a cloud computing device, a first flow associated with a packet comprising a header data from a user device);
determining, by the computing device, that the first header data comprises a label indicating that the user device is experiencing network congestion ([paragraph 0013-0014, 0051, 0074] describes user device may set one or more flags (e.g., label) in a header data such as a congestion encountered (CE) flag and determining by the proxy device such as the cloud computing device, that the user device is experiencing network congestion information based on the one or more flags (e.g. label) in the header data);
determining, by the computing device and based on the label, a decreased rate at which to send the at least one first packet to a server device ZHANG describes a user device, a proxy device or cloud computing device and server ([paragraph 0010, 0051] a proxy device or cloud computing device may provide the traffic to server device 240 (e.g., via network). The proxy server or cloud computing device receive from a user device a flow which includes a packet. user device 205 may set one or more flags (e.g., control bits) in a TCP or IP header (e.g., a congestion window reduced (CWR) flag. Additionally, or alternatively, proxy device 230 may determine the condition information based on the one or more flags in the TCP or IP headers [paragraph 0013-0015, 0026, 0043] discloses the proxy server or cloud computing device may perform an action by applying standard TCP parameter values (e.g., congestion window values, receive window values, etc.) to flows which may not accurately correspond to underlying network conditions, thereby resulting in unnecessary congestion mitigation actions and flows which may include a sequence of packets. proxy device or cloud computing device may separately control a rate of traffic transmission between proxy device 230 230 and server device 240 [paragraph 0051, 0076] discloses proxy device 230 or cloud computing device may perform the action based on adjusting a transmit rate associated with the first flow. For example, proxy device 230 or cloud computing device may perform the action in association with and determining a decrease transmit rate of traffic. The proxy device 230 or cloud computing device may perform the action based on adjusting a transmit rate associated with the first flow and instruct server device 240 to adjust a transmit rate based on the condition information [paragraph 0013-0015, 0063, 0076, 0087] describes determining by the proxy device such as the cloud computing device may adjust or decrease the transmission rate at which to send the first flow associated with the packet to a server device according to the user device is experiencing network congestion information based on the one or more flags (e.g. label) in the header data);
and sending the at least one first packet to the server device based on the decreased rate ([paragraph 0051, 0076] describes the proxy device 230 or cloud computing device may perform the action based on adjusting a transmit rate associated with the first flow and instruct (e.g. sending) server device 240 to adjust a transmit rate based on the condition information [paragraph 0063, 0076, 0083, 0087] discloses The proxy device 230 or cloud computing device may perform the action based on adjusting a transmit rate associated with the first flow and The proxy device 230 or cloud computing device transmitting the first flow associated with the packet to the server device based on decrease the transmission rate and increasing the efficiency of a connection and/or reducing network congestion).
Regarding claim 2, ZHANG discloses the method , further comprising determining a protocol associated with the user device sending the at least one first packet to the computing device, wherein determining the decreased rate at which to send the at least one first packet to the server device is further based on the protocol ([paragraph 0016, 0043, 0063, 0076] describes determining protocol such as application layer protocols (e.g., HTTP, SCTP, etc.) and transport layer protocols (e.g., TCP, UDP, QUIC, etc.) associated with the user device determining by the proxy device such as the cloud computing device may adjust or decrease the transmission rate at which to send the first flow associated with the packet to a server device based on the protocol).
Regarding claim 3, ZHANG discloses the method, wherein the protocol comprises at least one of a transport protocol or an application protocol([paragraph 0016, 0043, 0063, 0076] describes protocol such as application layer protocols (e.g., HTTP, SCTP, etc.) and transport layer protocols (e.g., TCP, UDP, QUIC, etc.).
Regarding claim 6, ZHANG discloses the method, further comprising: receiving, from the server device, at least one second packet sent to the user device; and sending the at least one second packet to the user device based on the decreased rate ([paragraph 0008-0009, 0043, 0076] describes receiving packet of second flow from the server device to the user device and server device adjust or decrease the transmission rate and sending the packet of second flow).
Regarding claim 9, ZHANG discloses the method, wherein determining the decreased rate at which to send the at least one first packet to the server device ([paragraph 0063, 0076, 0083, 0087] describes transmitting the first flow associated with the packet to the server device based on decrease the transmission rate and increasing the efficiency of a connection and/or reducing network congestion) comprises:
determining at least one congestion control algorithm; and determining the decreased rate based on the at least one congestion control algorithm ([paragraph 0008, 0076, 0087] describes a congestion detection algorithm for flow control mechanism (e.g. a congestion control algorithm) to regulate transmission throughput (e.g., to prevent a link between a server device and a client device from becoming overloaded and determining decrease the transmission rate and increasing the efficiency of a connection and/or reducing network congestion based on a congestion detection algorithm for flow control mechanism (e.g. a congestion control algorithm) to regulate transmission throughput).
Regarding claim 10, ZHANG discloses the method, wherein the label is inserted into the first header data by an application executing on the user device, and wherein the server device is associated with the application ([paragraph 0027-0029, 0051] describes user device may set flag (e.g. label) into header data by an application that are accessible to user device and server device may include a server device (e.g., a host server, a web server, an application server, etc.).
Regarding claim 11, ZHANG discloses the method, wherein determining the decreased rate at which to send the at least one first packet to the server device is based on at least one of: a network address associated with the user device satisfying at least one condition; an autonomous system number (ASN) satisfying at least one condition; the protocol satisfying at least one condition; a time or date satisfying at least one condition; or a billing code or product code associated with the user device satisfying at least one condition ([paragraph 0063, 0076, 0083, 0087] describes transmitting the first flow associated with the packet to the server device based on decrease the transmission rate and increasing the efficiency of a connection and/or reducing network congestion [paragraph 0054, 0057, 0068] describes correlate the condition information associated with user device 205 and a device identifier associated with user device 205 (e.g., a mobile directory number (MDN), an international mobile subscriber identity (IMSI), etc., may request the condition information (e.g., when user device requests the resource and/or at another time), may provide the condition information based on a time frame (e.g., at an interval), determine a parameter value based on a time frame (e.g., a time of day, a day of the week, a month, a season, etc.).
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 4-5 are rejected under 35 U.S.C. 103 as being unpatentable over ZHANG et al. (US 2018/0091999 A1); in view of Ma et al. (US 2016/0219088 A1).
Regarding claim 4, ZHANG fails to teach the method, receiving, from the server device, at least one second packet sent to the user device, wherein the at least one second packet comprises second header data; determining that the second header data does not comprise the label; and inserting the label into the second header data associated with the at least one second packet.
However, Ma teaches the method, receiving, from the server device, at least one second packet sent to the user device, wherein the at least one second packet comprises second header data ([paragraph 0048-0049] describes a user equipment, WTRU or computing device and a node (e.g. server) [paragraph 0121, 0142-0143, 0197-0200] describes inner packet header data and outer packet header data (e.g. second header data) and receiving second packet includes outer packet header data (e.g. second header data) sent to user equipment);
determining that the second header data does not comprise the label; and inserting the label into the second header data associated with the at least one second packet ([paragraph 0128-0131, 0272-0273, 0290-0292] describes determining that outer packet data (e.g. second header data) does not include label and inserting label into the outer packet header data (e.g. second header data) associated with the second packet).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the teachings of ZHANG to include receiving, from the server device, at least one second packet sent to the user device, wherein the at least one second packet comprises second header data; determining that the second header data does not comprise the label; and inserting the label into the second header data associated with the at least one second packet as taught by Ma. One ordinary skill in the art would be motivated to utilize the teachings of ZHANG in the Ma system in order to update the lost packet indicator for a second packet in the first real-time video traffic flow based on the dropped packet ([paragraph 0003] in Ma).
Regarding claim 5, ZHANG fails to teach the method, further comprising: receiving, by the computing device and from the user device, at least one second packet comprising second header data; determining that the second header data comprises a different label indicating that the user device is experiencing a lack of network congestion; and determining, by the computing device and based on the different label, an increased rate at which to send the at least one second packet to the server device.
However, Ma teaches the method, further receiving, by the computing device and from the user device, at least one second packet comprising second header data ([paragraph 0048-0049] describes a user equipment, WTRU or computing device and a node (e.g. server) [paragraph 0064, 0121, 0142-0143] describes inner packet header data and outer packet header data (e.g. second header data) and receiving by WTRU or computing device, second packet includes outer packet header data (e.g. second header data) sent from user equipment);
determining that the second header data comprises a different label indicating that the user device is experiencing a lack of network congestion; and determining, by the computing device and based on the different label, an increased rate at which to send the at least one second packet to the server device ([paragraph 0135-0137, 0224-0225, 0282, 0288] describes determining that outer packet header data (e.g. second header data) is marked with different label that user equipment is experiencing lack of congestion and determining by the WTRU or computing device to increase bit rate at which to send second packet to node (e.g. server) based on different label).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the teachings of ZHANG to include receiving, by the computing device and from the user device, at least one second packet comprising second header data; determining that the second header data comprises a different label indicating that the user device is experiencing a lack of network congestion; and determining, by the computing device and based on the different label, an increased rate at which to send the at least one second packet to the server device as taught by Ma. One ordinary skill in the art would be motivated to utilize the teachings of ZHANG in the Ma system in order to update the lost packet indicator for a second packet in the first real-time video traffic flow based on the dropped packet ([paragraph 0003] in Ma).
Claims 7-8 are rejected under 35 U.S.C. 103 as being unpatentable over ZHANG et al. (US 2018/0091999 A1); in view of Revels et al. (US 2011/0069616 A1).
Regarding claim 7, ZHANG fails to teach the method, wherein the first header data comprises a field associated with a congestion control protocol, wherein the label is comprised in the field.
However, Revels teaches the method, wherein the first header data comprises a field associated with a congestion control protocol, wherein the label is comprised in the field ([paragraph 0005-0007, 0019-0020, 0029] describes header of data packet showing a two bit congestion notification field associated with protocol used to communicate congestion control signal (e.g. a congestion control protocol)).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the teachings of ZHANG to include wherein the first header data comprises a field associated with a congestion control protocol, wherein the label is comprised in the field as taught by Revels. One ordinary skill in the art would be motivated to utilize the teachings of ZHANG in the Revels system in order to manage of data congestion in a data network ([paragraph 0001] in Revels).
Regarding claim 8, the combination of ZHANG and Revels teaches the method, further comprising determining that the server device does not support the congestion control protocol (Revels: [paragraph 0009, 0044, 0057-0058] describes determining that server does not support protocol used to communicate congestion control signal (e.g. a congestion control protocol) and Explicit Congestion Notification (ECN)).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the teachings of ZHANG to include determining that the server device does not support the congestion control protocol as taught by Revels. One ordinary skill in the art would be motivated to utilize the teachings of ZHANG in the Revels system in order to manage of data congestion in a data network ([paragraph 0001] in Revels).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
- Jian et al., US 2023/0300671 A1, Methods, systems, and devices for wireless communication are described.
- Ramanujan et al., US 2010/0039937 A1, Method relates to an implementation of a reliable transport protocol that provides receiver-based congestion control within a computing system.
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 MEHULKUMAR J SHAH whose telephone number is (571)272-1072. The examiner can normally be reached Mon-Fri, 6:05 am-3:55 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, TONIA 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.
/M.J.S/Examiner, Art Unit 2459 /TONIA L DOLLINGER/Supervisory Patent Examiner, Art Unit 2459
Prosecution Insights