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. Claims 1-20 are presented for examination.
Election/Restrictions
Applicant’s election of Species I (claims 1-11) with traverse in the reply filed on 30 December 2025 is acknowledged. Claims 12-20 are withdrawn from further consideration pursuant to 37 CFR 1.142(b) as being drawn to a nonelected invention, there being no allowable generic or linking claim. Election was made with traverse in the reply filed on 30 December 2025.
Response to Arguments
Applicant argues at page 2 of the remarks, as filed on 30 December 2025, that Applicant submits that the Restriction Requirement is improper and traverses the requirement. The Restriction Requirement is improper because it does not meet the burden required to establish restriction by species. Section 809.02(a) of the MPEP explains that, "[w]here restriction between species is appropriate" the Office must "(A) Identify generic claims or indicate that no generic claims are present" and "(B) Clearly identify each (or in aggravated cases at least exemplary ones) of the disclosed species, to which claims are to be restricted." (Emphasis added). Here, the Office has made no attempt to identify generic claims. Nor does the Office indicate that no generic claims are present. The Office's failure to identify generic claims or indicate their absence is a procedural deficiency. Applicant submits that at least alleged Species I and alleged Species II are not mutually exclusive and should therefore be considered a single species even if the Office maintains that Species III is properly restricted.
The examiner respectfully disagrees and finds these arguments unpersuasive.
I. Species I – Claims 1-11 (Examples 1-11 in paragraphs 0013-0015 addressing first header data comprises a label indicating that the user device is experiencing network congestion)
II. Species II – Claims 12-16 (Examples 12-16 in paragraphs 0042-0044 addressing first packet to the server device based on the decreased rate)
III. Species III- Claims 17-20 (Examples 17-20 in paragraphs 0053-0055 directed to one first packet to the server device based on the increased rate)
The species are independent or distinct because the claims to the different species recite the mutually exclusive characteristics of such species. For instance, the “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” limitations of claims 1-11 are mutually exclusive characteristics of that species. The “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” limitation of claims 12-16 is a mutually exclusive characteristic of that species. The “wherein determining the increased rate at which to send the at least one first packet to the server device is further based on the protocol” limitation of claims 17-20 is a mutually exclusive characteristic of that species. In addition, these species are not obvious variants of each other. Therefore, The examiner is maintaining restriction requirement. As Applicant’s election of Species I (claims 1-11) with traverse so for the examination purpose examiner will consider claims 1-11 for examination.
.
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 ([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 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).
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:
- Zhao et al., US 2015/0188830 A1, Systems and methods for managing congestion in a network are disclosed.
- Goldenberg et al., US 2017/0041239 A1, A method for Congestion detection logic is coupled to identify a flow of the received packets that is causing congestion in the network is provided.
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