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 .
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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, 12-13, 15 and 18-19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Agrawal et al. (US 2020/0266955 A1), hereinafter Agrawal.
Regarding claim 1, Agrawal discloses: A communication device comprising: an interface configured to receive packets; and at least one processing core configured to ([0010] UE having a memory, a transceiver, and one or more processors operatively coupled with the memory and the transceiver, the one or more processors configured to perform the steps): based on first network information satisfying a first condition, identify transmission control protocol (TCP) session information and acknowledgment (ACK) numbers of a plurality of first ACK packets that are read from the interface during an aggregation period ([0006] A number of network protocols may cooperate to handle the complexity of network communications. For example, TCP may provide applications with mechanisms for transferring data across a network. To provide these services, TCP may operate on packets known as segments. Generally, a TCP segment travels across a network encapsulated by a larger packet such as an Internet Protocol (IP) packet. The payload of a TCP segment may carry a portion of the data sent across the network by an application. A receiving device may restore the original stream of data by reassembling the received TCP segments. To accomplish reassembly and ACK of received data segments back to the sending device, TCP associates a sequence number with each portion (e.g., packet) of the data. The ACKs may include information indicating to the sending device the successful receptions and/or decoding of the corresponding data segments, or the failed receptions and/or decoding (e.g., failure due to lost/missing data segments, corrupted/incomplete data segments) by the receiving device. When waiting for lost/missing data segments, the receiving device may wait for the expiration of a predetermined period of time before sending the ACK indicating lost/missing segments. [0007] In a communication network, a receiving device, such as a base station (BS) or a user equipment (UE), may transmit one or more aggregated TCP ACKs to a sending device, such as another BS or another UE, in order to reduce the overall data transmitted. Coalescing/aggregating ACKs may include receiving N TCP packets and transmitting less than N ACKs. However, certain files may not be suitable for TCP ACK aggregation due to the size of each of the files, transmission rates, or other factors. Therefore, improvements in TCP ACK aggregation may be desired. [0010] Other aspects of the present disclosure include a UE having a memory, a transceiver, and one or more processors operatively coupled with the memory and the transceiver, the one or more processors configured to perform the steps of receiving at least one transport protocol TP packet, computing a current data rate or an end time of a low throughput phase, determining if TP is in the low throughput phase by comparing the current data rate to a threshold data rate or comparing a current time to the end time of the low throughput phase, aggregating the at least one received TP packet or an ACK relating to the at least one received TP packet in response to determining that the TP is not in the low throughput phase, and transmitting the ACK to a sending device; transmit a second ACK packet having a greatest ACK number among a plurality of second ACK packets on an uplink, the plurality of second ACK packets having same TCP session information among the plurality of first ACK packets, and discard remaining second ACK packets among the plurality of second ACK packets ([0082] As illustrated in the diagram 600, in some implementations, a sending device 610, such as the UE 110 or the BS 105, may send one or more packets to a receiving device 620, such as a different UE 110 or BS 105. In some implementations, the sending device 610 may send (632) packet 1 to the receiving device 620. In response to receiving packet 1, the receiving device 620 may generate (634) ACK 1. The sending device 610 may send (636) packet 2 to the receiving device 620. In response to receiving packet 2, the receiving device 620 may generate (638) ACK 2. In certain examples, an ACK may not be generated for every received packet. For example, ACK 2 may be generated, whereas ACK 1 may not be generated. This may be possible because TCP ACKs may be cumulative. The ACKs may cumulatively acknowledge reception of all packets up to the indicated sequence number. Next, the sending device 610 may send (640) packet 3 to the receiving device 620. In response to receiving packet 3, the receiving device 620 may generate (642) ACK 3. After generating ACKs 1-3, the receiving device 620 may aggregate (644) some of the ACKs. In one non-limiting example, only ACK 3 is transmitted (648) to the sending device 610 to acknowledge the reception of packets 1-3, while ACKs 1 and 2 are not transmitted (646) to the sending device 610. ACKs 1 and 2 may be discarded without being sent to the sending device 610).
Regarding claim 2, a communication links 120 between the BS 105 and the UEs 110 includes a downlink, see 0037. Thus, Agrawal teaches the condition associated with a downlink.
Regarding claim 3, the UE 110-fig.2, via the transceiver 202-fig.2 and processor 212 can transmit one or more aggregated TCP ACKs to a sending device, such as another BS or another UE, see 0007. Thus, the aggregation period can be determined from the transceiver’s reception of the ACK packets.
Regarding claim 13, Agrawal discloses: An electronic device comprising:
a main processor configured to generate a group of packets; and a communication processor configured to ([0010] UE having a memory, a transceiver, and one or more processors operatively coupled with the memory and the transceiver, the one or more processors configured to perform the steps), based on first network information satisfying a first condition, transmit a first ACK packet having a greatest ACK number among a plurality of first ACK packets on an uplink ([0006] A number of network protocols may cooperate to handle the complexity of network communications. For example, TCP may provide applications with mechanisms for transferring data across a network. To provide these services, TCP may operate on packets known as segments. Generally, a TCP segment travels across a network encapsulated by a larger packet such as an Internet Protocol (IP) packet. The payload of a TCP segment may carry a portion of the data sent across the network by an application. A receiving device may restore the original stream of data by reassembling the received TCP segments. To accomplish reassembly and ACK of received data segments back to the sending device, TCP associates a sequence number with each portion (e.g., packet) of the data. The ACKs may include information indicating to the sending device the successful receptions and/or decoding of the corresponding data segments, or the failed receptions and/or decoding (e.g., failure due to lost/missing data segments, corrupted/incomplete data segments) by the receiving device. When waiting for lost/missing data segments, the receiving device may wait for the expiration of a predetermined period of time before sending the ACK indicating lost/missing segments. [0007] In a communication network, a receiving device, such as a base station (BS) or a user equipment (UE), may transmit one or more aggregated TCP ACKs to a sending device, such as another BS or another UE, in order to reduce the overall data transmitted. Coalescing/aggregating ACKs may include receiving N TCP packets and transmitting less than N ACKs. However, certain files may not be suitable for TCP ACK aggregation due to the size of each of the files, transmission rates, or other factors. Therefore, improvements in TCP ACK aggregation may be desired. [0010] Other aspects of the present disclosure include a UE having a memory, a transceiver, and one or more processors operatively coupled with the memory and the transceiver, the one or more processors configured to perform the steps of receiving at least one transport protocol TP packet, computing a current data rate or an end time of a low throughput phase, determining if TP is in the low throughput phase by comparing the current data rate to a threshold data rate or comparing a current time to the end time of the low throughput phase, aggregating the at least one received TP packet or an ACK relating to the at least one received TP packet in response to determining that the TP is not in the low throughput phase, and transmitting the ACK to a sending device), and not transmit another first ACK packet having an ACK number less than the greatest ACK number among the plurality of first ACK packets, wherein the plurality of first ACK packets have same first TCP session information among the group of packets received from the main processor during the aggregation period ([0082] As illustrated in the diagram 600, in some implementations, a sending device 610, such as the UE 110 or the BS 105, may send one or more packets to a receiving device 620, such as a different UE 110 or BS 105. In some implementations, the sending device 610 may send (632) packet 1 to the receiving device 620. In response to receiving packet 1, the receiving device 620 may generate (634) ACK 1. The sending device 610 may send (636) packet 2 to the receiving device 620. In response to receiving packet 2, the receiving device 620 may generate (638) ACK 2. In certain examples, an ACK may not be generated for every received packet. For example, ACK 2 may be generated, whereas ACK 1 may not be generated. This may be possible because TCP ACKs may be cumulative. The ACKs may cumulatively acknowledge reception of all packets up to the indicated sequence number. Next, the sending device 610 may send (640) packet 3 to the receiving device 620. In response to receiving packet 3, the receiving device 620 may generate (642) ACK 3. After generating ACKs 1-3, the receiving device 620 may aggregate (644) some of the ACKs. In one non-limiting example, only ACK 3 is transmitted (648) to the sending device 610 to acknowledge the reception of packets 1-3, while ACKs 1 and 2 are not transmitted (646) to the sending device 610. ACKs 1 and 2 may be discarded without being sent to the sending device 610).
Regarding claim 14, a communication links 120 between the BS 105 and the UEs 110 includes a downlink, see 0037. Thus, Agrawal teaches the condition associated with a downlink.
Regarding claim 18, Agrawal discloses: A method of transmitting an acknowledgment (ACK) packet by a communication device, the method comprising: obtaining first network information; based on the first network information satisfying a predetermined condition, enabling an aggregation mode ([0006] A number of network protocols may cooperate to handle the complexity of network communications. For example, TCP may provide applications with mechanisms for transferring data across a network. To provide these services, TCP may operate on packets known as segments. Generally, a TCP segment travels across a network encapsulated by a larger packet such as an Internet Protocol (IP) packet. The payload of a TCP segment may carry a portion of the data sent across the network by an application. A receiving device may restore the original stream of data by reassembling the received TCP segments. To accomplish reassembly and ACK of received data segments back to the sending device, TCP associates a sequence number with each portion (e.g., packet) of the data. The ACKs may include information indicating to the sending device the successful receptions and/or decoding of the corresponding data segments, or the failed receptions and/or decoding (e.g., failure due to lost/missing data segments, corrupted/incomplete data segments) by the receiving device. When waiting for lost/missing data segments, the receiving device may wait for the expiration of a predetermined period of time before sending the ACK indicating lost/missing segments. [0007] In a communication network, a receiving device, such as a base station (BS) or a user equipment (UE), may transmit one or more aggregated TCP ACKs to a sending device, such as another BS or another UE, in order to reduce the overall data transmitted. Coalescing/aggregating ACKs may include receiving N TCP packets and transmitting less than N ACKs. However, certain files may not be suitable for TCP ACK aggregation due to the size of each of the files, transmission rates, or other factors. Therefore, improvements in TCP ACK aggregation may be desired. [0010] Other aspects of the present disclosure include a UE having a memory, a transceiver, and one or more processors operatively coupled with the memory and the transceiver, the one or more processors configured to perform the steps of receiving at least one transport protocol TP packet, computing a current data rate or an end time of a low throughput phase, determining if TP is in the low throughput phase by comparing the current data rate to a threshold data rate or comparing a current time to the end time of the low throughput phase, aggregating the at least one received TP packet or an ACK relating to the at least one received TP packet in response to determining that the TP is not in the low throughput phase, and transmitting the ACK to a sending device; transmitting a ACK packet having a greatest ACK number among a plurality of ACK packets having same TCP session information on an uplink during an aggregation period of the aggregation mode; and discarding another ACK packet having an ACK number less than the greatest ACK number among the plurality of ACK packets ([0082] As illustrated in the diagram 600, in some implementations, a sending device 610, such as the UE 110 or the BS 105, may send one or more packets to a receiving device 620, such as a different UE 110 or BS 105. In some implementations, the sending device 610 may send (632) packet 1 to the receiving device 620. In response to receiving packet 1, the receiving device 620 may generate (634) ACK 1. The sending device 610 may send (636) packet 2 to the receiving device 620. In response to receiving packet 2, the receiving device 620 may generate (638) ACK 2. In certain examples, an ACK may not be generated for every received packet. For example, ACK 2 may be generated, whereas ACK 1 may not be generated. This may be possible because TCP ACKs may be cumulative. The ACKs may cumulatively acknowledge reception of all packets up to the indicated sequence number. Next, the sending device 610 may send (640) packet 3 to the receiving device 620. In response to receiving packet 3, the receiving device 620 may generate (642) ACK 3. After generating ACKs 1-3, the receiving device 620 may aggregate (644) some of the ACKs. In one non-limiting example, only ACK 3 is transmitted (648) to the sending device 610 to acknowledge the reception of packets 1-3, while ACKs 1 and 2 are not transmitted (646) to the sending device 610. ACKs 1 and 2 may be discarded without being sent to the sending device 610).
Regarding claim 19, a communication links 120 between the BS 105 and the UEs 110 includes a downlink, see 0037. Thus, Agrawal teaches the condition associated with a downlink.
Claim Rejections - 35 USC § 103
4. 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 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.
5. The following is a quotation of pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
6. 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.
7. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
8. Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Agrawal, in view of Hayes et al. (US 2013/0133045 A1), hereinafter referred to as Hayes.
Agrawal discloses all claimed limitations, except the TCP session information comprises an internet protocol address and a TCP port.
Hayes from the same field of endeavor as that of Agrawal discloses a TCP-SYN request is a request to establish a TCP session with the resource indicated by the destination IP address and destination TCP port number, see 0154.
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention to employ the TCP session with the destination IP address and destination TCP port number taught by Hayes into the system of Agrawal. The suggestion/motivation for doing so would have been to enable a network to take network request and direct it to one of a group of resources that can satisfy the request.
Allowable subject matter
9. Claims 4-10, 14, 16-17 and 20 are rejected based on its dependency, but would be allowable if claims 1 and 20 rewritten or amended to include all of the limitations of the base claim and any intervening claims.
Conclusion
10. The prior art of record and not relied upon is considered pertinent to applicant's disclosure. Ohta (US 11677669 B2); Lee (US 20260067222 A1); Goel (US 11652751 B2) are cited, and considered pertinent to the instant specification.
11. Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUC C HO whose telephone number is (571)272-3147. The examiner can normally be reached on M-F 8am-4pm.
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, Gary Mui can be reached on 571-270-1420 (Gary.mui@uspto.gov). The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/DUC C HO/Primary Examiner, Art Unit 2465