DETAILED ACTION
This office action is a response to the application 18/530,948 filed on December 6th, 2023.
Claim Status
This office action is based upon claims received on 08/27/2026, which replace all prior or other submitted versions of the claims.
Claims 1 – 17 are pending.
Claims 1 – 17 are rejected.
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 .
Response to Arguments/Remarks
Claim Rejections - 35 USC § 112: Claims 1 – 6 and 12 – 17 were rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being incomplete for omitting essential elements or steps, such omission amounting to a gap between the steps. The independent claims have been amended to address the omission. The claim rejection under 35 USC § 112 is hereby withdrawn.
Claim Objection: Claims 6 and 17 were objected to because of informalities. The appropriate corrections have been made in claims 6 and 17. The claim objection is hereby withdrawn.
Applicant's arguments, see pages 3 – 19 of the Remarks, filed 08/27/2026, with respect to the rejections of independent claims 1, 7, and 12, and dependent claims 2 – 6, 8 – 11, and 13 – 17, under applied prior art references of record in the office action dated 05/27/2026, particularly as regards the amended limitations, have been fully considered and are persuasive. However, upon further consideration, a new ground(s) of rejection is made in view of Speight et al. [US 20090201813 A1]. Therefore, the rejection has been revised as set forth below according to the amended claims. See office action below.
It should be noted that the scope of the previous claim 1 has been changed with the current amendment. Therefore, this current amendment changes the scope of the limitations as recited in amended claim 1, and it necessitates a new ground(s) of rejection.
All remaining arguments presented by Applicant not specifically addressed herein and directed to various dependent claims are found unpersuasive for the same reasons as stated herein, with regard to independent claims. The rejection has been revised and set forth below according to the amended claims.
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.
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.
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.
Claims 1, 2, 7, 12, and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Jung et al. [US 20170135023 A1] hereinafter Jung, and further in view of Speight et al. [US 20090201813 A1] hereinafter Speight, and Kim et al. [US 20050094670 A1] hereinafter Kim.
Regarding claim 1, Jung teaches a processing method in a packet data convergence protocol (PDCP) layer of a terminal (Jung: Fig. 15, ¶ 213; in view of a terminal including TCP layer 145 and PDCP layer 137), comprising:
receiving a connection request transmission control protocol (TCP) packet from a TCP client of the terminal (Jung: Fig. 15, ¶ 214-215; wherein a TCP layer 145 in a terminal 130 generates a TCP session through a TCP 3-way handshake with a server 150. That is, the server 150 transmits a TCP synchronization (TCP SYN) message to the TCP layer 145 in the terminal at operation 1501, and the TCP layer 145 in the terminal 130 transmits a response message in response to the TCP SYN message received from the server 150 while transmitting the TCP SYN message to the server 150 at operation 1503. Therefore, as shown in Fig. 15, whenever the TCP layer 145 (i.e., the TCP client) transmits to the server or receives from the server, the message is sent through the PDCP layer 137 (i.e., the PDCP layer) of the terminal. Thus, when the TCP layer 145 sends the response message in response to the TCP SYN (i.e., the connection request TCP packet) to the server, the PDCP of the terminal will receive the TCP packet before sending it to the server);
transmitting the connection request TCP packet to a base station (Jung: Fig. 15, ¶ 214-215; wherein the TCP layer 145 in the terminal 130 transmits a response message in response to the TCP SYN message received from the server 150 while transmitting the TCP SYN message to the server 150 at operation 1503. Therefore, when the TCP layer 145 sends the response message in response to the TCP SYN (i.e., the connection request TCP packet) to the server, the PDCP of the terminal will receive the TCP packet before sending it to the server);
receiving a connection permission TCP packet from a TCP server through the base station (Jung: Fig. 15, ¶ 214-215; wherein the server 150 transmits, to the terminal 130, a response message in response to the TCP SYN message received from the terminal 130 at operation 1505. Therefore, when the server sends the response TCP ACK message in response to the TCP SYN (i.e., the connection request TCP packet) to the terminal, the PDCP of the terminal will receive the TCP packet before sending it to the TCP client of the terminal);
delivering the connection permission TCP packet to the TCP client (Jung: Fig. 15, ¶ 214-215; wherein the PDCP of the terminal will receive the TCP packet before sending it to the TCP client of the terminal, and the PDCP layer of the terminal sends it to the TCP layer of the terminal); and
receiving, from the TCP client, a connection establishment TCP packet in response to the connection permission TCP packet (Jung: Fig. 15, ¶ 214-215; wherein the server 150 transmits, to the terminal 130, a response message in response to the TCP SYN message received from the terminal 130 at operation 1505. Therefore, when the server sends the response TCP ACK message in response to the TCP SYN (i.e., the connection request TCP packet) to the terminal, the PDCP of the terminal will receive the TCP packet before sending it to the TCP client of the terminal and the TCP client of the terminal will obviously send a connection establishment message back to the PDCP of the terminal as part of the TCP 3-way handshake).
Jung does not explicitly teach creating an initial PDCP TCP context based on the received connection request TCP packet, wherein the initial PDCP TCP context includes information requesting a PDCP layer of the base station to create a context for TCP processing and indicates that the PDCP layer of the terminal and the PDCP layer of the base station each perform at least part of a TCP procedure in advance; transmitting the initial PDCP TCP context to the base station; receiving a response to the initial PDCP TCP context from the base station; and discarding, without transmitting to the base station, the received connection establishment TCP packet based on the response indicating acceptance of the request for the PDCP layer of the base station to create a context for TCP processing, the request being included in the initial PDCP TCP context.
Referring to the invention of Speight, Speight teaches creating a PDCP TCP context based on the received connection request TCP packet, wherein the PDCP TCP context includes information requesting a PDCP layer of the base station to create a context for TCP processing (Speight: Fig. 5, ¶ 65 – 69, ¶ 81; wherein the synchronising TCP proxy in both the UE 510 and the RNC 315 are configured to allow the known 3-way handshake (`SYN` 542, `SYN ACK` 544 and `ACK` 546) to transparently pass therethrough, for the end-to-end communication between the PC 505 and, say, a web server 520. Thus, the information contained within these `synchronising` TCP messages is then used to synchronise the `ACK` and `SEQ` fields in the TCP communication, so that the TCP proxies in the UE 510 and the RNC 515 are able to generate TCP ACKs (and NACKs) that appear to be from the end-point of the entire TCP connection (e.g. they appear to be end-to-end)…wherein both receive and transmit side synchronising TCP proxy functionality is provided at both the UE and in the RAN. In accordance with one embodiment of the invention, the TCP protocol accelerator logic is arranged to reside in PDCP. Therefore, since the functionality is a TCP-proxy synchronization functionality and the TCP accelerator is in the PDCP, the PDCP TCP context that is created will be based on the received connection request and will include information requesting the PDCP layer of the base station to create the context for TCP processing) and indicates that the PDCP layer of the terminal and the PDCP layer of the base station each perform at least part of a TCP procedure in advance (Speight: Fig. 5, ¶ 65 – 71, ¶ 81; wherein the synchronising TCP proxy in both the UE 510 and the RNC 315 are configured to allow the known 3-way handshake (`SYN` 542, `SYN ACK` 544 and `ACK` 546) to transparently pass therethrough, for the end-to-end communication between the PC 505 and, say, a web server 520. Thus, the information contained within these `synchronising` TCP messages is then used to synchronise the `ACK` and `SEQ` fields in the TCP communication, so that the TCP proxies in the UE 510 and the RNC 515 are able to generate TCP ACKs (and NACKs) that appear to be from the end-point of the entire TCP connection (e.g. they appear to be end-to-end)… When the 3-way handshake is passed through the proxies, the proxies are then able to ensure that any subsequent TCP ACKs that they generate use the appropriate SEQ number, which was negotiated in the 3-way handshake……As soon as the network side proxy allows data segment 546 through the `synchronising proxy` it sends a TCP ACK 552 back to the server… the proxy generates what are typically known as ‘early ACKs’. Therefore, since the TCP accelerator is in the PDCP of at both the UE and the RAN, and the proxy generates early ACKs, thus, the PDCP layer of the terminal and the PDCP layer of the base station each perform part of the TCP procedure in advance); and
discarding, without transmitting to the base station, the received connection establishment TCP packet based on the response indicating acceptance of the request for the PDCP layer of the base station to create a context for TCP processing, the request being included in the PDCP TCP context (Speight: Fig. 5, ¶ 65 – 69, ¶ 72, ¶ 111; wherein the TCP ACK generated by the PC 550 is examined at the proxy at the UE end and since it is determined to contain no data, i.e. it is only a TCP ACK, it is terminated and not sent over the air interface (as the proxy at the network end has already in step 552, ACKed the data segment 546)... after the segment with SEQ2000 is seen at the network side proxy 556, a TCP ACK is generated 572 that acknowledges the correct reception of both the segment with SEQ1000 and the segment with SEQ2000. The network side proxy 556 allows these segments to be sent to lower layers in the radio access network and they are subsequently sent through the proxy at the UE 555 to PC 505. An ACK is generated by the PC 570. However, this ACK is discarded at the proxy at the UE 555, as the segments have already been acknowledged by the proxy generated ACK 572 Therefore, when the ACK is generated at the UE side, it is then discarded without transmitting it to the base station).
Thus, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the PDCP context creation and transmission teachings of Speight into the TCP procedure teachings of Jung in order to achieve effective utilization of TCP packets, reliable data delivery, and to provide efficient security, and integrity, all of which are critical for maintaining TCP’s performance and stability.
Jung in view of Speight does not explicitly teach that the PDCP TCP context is an initial PDCP TCP context, wherein the initial PDCP TCP context includes information requesting a PDCP layer of the base station to create a context for TCP processing; transmitting the initial PDCP TCP context to the base station; and receiving a response to the initial PDCP TCP context from the base station.
Referring to the invention of Kim, Kim teaches creating an initial PDCP TCP context based on the TCP connection request (Kim: Fig. 8, ¶ Fig. 10, ¶ 119 – 127, ¶ 140-143; wherein the UE RRC (i.e., in response to the context request triggering condition (CRTC) of the UE PDCP in step 810 of Fig. 8) creates … a PDCP context request message to the RNC RRC. Therefore, the UE sends a PDCP context request, an RNC PDCP determines context information, and an RNC returns a PDCP context response), wherein the initial PDCP TCP context includes information requesting a PDCP layer of the base station to create a context for TCP processing (Kim: Fig. 8, ¶ Fig. 10, ¶ 119 – 127; wherein the UE RRC creates and transfers a PDCP context request message to the RNC RRC... The RNC RRC identifies a PDCP using the MBMS and RB IDs and transfers a CPDPD-CONTEXT-REQ to the identified PDCP entity… and the RNC PDCP determines the context information based on the received context request); transmitting the initial PDCP TCP context to the base station (Kim: Fig. 8, Fig. 10, ¶ 119, ¶ 124, ¶ 140-143; wherein the UE RRC creates and transmits a PDCP context request message to the RNC RRC, and at step 825, the RNC RRC identifies a PDCP using the MBMS and RB IDs included in the received PDCP context request message, and transfers a CPDCP context request message (CPDCP-CONTEXT-REQ) including the CRTC code to the identified PDCP entity); receiving a response to the initial PDCP TCP context from the base station (Kim: Fig. 8, Fig. 10, ¶ 126-127, ¶ 140-143; wherein after transmitting the PDCP context request message, the UE RRC determines, at step 1015, whether a PDCP context response message is received. If a PDCP context response message is received, the UE RRC moves to step 1020, otherwise it returns to step 1015 to wait until a PDCP context response message is received… At step 830, in response to the CPDCP context request message (CPDCP-CONTEXT-REQ), the RNC PDCP transfers a CPDCP context response message (CPDCP-CONTEXT-RES) including the context information (CONTEXT INFO) to the RNC RRC. At step 835, the RNC RRC transfers a PDCP context response message (PDCP-CONTEXT-RES) to the UE RRC through an RRC message).
Thus, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the PDCP-based TCP accelerator of Jung and Speight to employ the PDCP context request/response procedure of Kim when establishing the TCP-processing state between the terminal-side PDCP entity and the network-side PDCP entity. Using Kim’s established PDCP context request/response procedure to request, establish, and confirm the TCP-processing state required by Speight would merely provide a known signaling mechanism for establishing the state already required by Speight’s synchronized TCP proxies. The resulting system will predictably permit the terminal PDCP entity and network PDCP entity to establish corresponding TCP-processing contexts before performing the subsequent TCP acceleration operations.
Regarding claim 2, Jung in view of Speight and Kim teaches the processing method according to claim 1, further comprising: obtaining information on a size of a reception buffer of the TCP server included in the connection permission TCP packet (Jung: Fig. 15, ¶ 86, ¶ 219-220; wherein the X2-UP protocol provides information related to a current-desired buffer size per bearer, and information related to a current-minimum desired buffer size per terminal. Therefore, the terminal obtains information on a size of a reception buffer of the TCP server from the X2-UP protocol regarding the current-minimum desired buffer size per terminal).
Regarding claim 7, Jung teaches a processing method in a packet data convergence protocol (PDCP) of a base station (Jung: Fig. 15, ¶ 218; in view of a base station including MeNB 110, SeNB 120, and server 150), comprising:
receiving a connection request Transmission Control Protocol (TCP) packet from a terminal (Jung: Fig. 15, ¶ 214-215; wherein a TCP layer 145 in a terminal 130 generates a TCP session through a TCP 3-way handshake with a server 150. That is, the server 150 transmits a TCP synchronization (TCP SYN) message to the TCP layer 145 in the terminal at operation 1501, and the TCP layer 145 in the terminal 130 transmits a response message in response to the TCP SYN message received from the server 150 while transmitting the TCP SYN message to the server 150 at operation 1503. Therefore, as shown in Fig. 15, whenever the TCP layer 145 (i.e., the TCP client) transmits to the server or receives from the server, the message is sent through the PDCP layer 137 (i.e., the PDCP layer) of the terminal. Thus, when the TCP layer 145 sends the response message in response to the TCP SYN (i.e., the connection request TCP packet) to the server, the PDCP of the terminal will receive the TCP packet before sending it to the server);
transmitting the connection request TCP packet to a TCP server (Jung: Fig. 15, ¶ 214-215; wherein the TCP layer 145 in the terminal 130 transmits a response message in response to the TCP SYN message received from the server 150 while transmitting the TCP SYN message to the server 150 at operation 1503. Therefore, when the TCP layer 145 sends the response message in response to the TCP SYN (i.e., the connection request TCP packet) to the server, the PDCP of the terminal will receive the TCP packet before sending it to the server);
in response to receiving a connection permission TCP packet from the TCP server, transmitting the connection permission TCP packet to the terminal (Jung: Fig. 15, ¶ 214-215; wherein the server 150 transmits, to the terminal 130, a response message in response to the TCP SYN message received from the terminal 130 at operation 1505. Therefore, when the server sends the response TCP ACK message in response to the TCP SYN (i.e., the connection request TCP packet) to the terminal, the PDCP of the terminal will receive the TCP packet before sending it to the TCP client of the terminal).
Jung does not explicitly teach receiving an initial PDCP TCP context from the terminal, wherein the initial PDCP TCP context includes information requesting the PDCP layer of the base station to create a context for TCP processing and indicates that the PDCP layer of the terminal and the PDCP layer of the base station each perform at least part of a TCP procedure in advance; creating the PDCP TCP context; in response to receiving the connection permission TCP packet, generating a connection establishment TCP packet to be transmitted to the TCP server; transmitting, to the TCP server, the connection establishment TCP packet without receiving the connection establishment TCP packet from the PDCP layer of the terminal; and transmitting, to the PDCP layer of the terminal, a response to the initial PDCP TCP context, the response indicating acceptance of the information requesting the PDCP layer of the base station to create a context for TCP processing, the information being included in the initial PDCP TCP context.
Referring to the invention of Speight, Speight teaches receiving a PDCP TCP context from the terminal, wherein the PDCP TCP context includes information requesting the PDCP layer of the base station to create a context for TCP processing (Speight: Fig. 5, ¶ 65 – 69, ¶ 81; wherein the synchronising TCP proxy in both the UE 510 and the RNC 315 are configured to allow the known 3-way handshake (`SYN` 542, `SYN ACK` 544 and `ACK` 546) to transparently pass therethrough, for the end-to-end communication between the PC 505 and, say, a web server 520. Thus, the information contained within these `synchronising` TCP messages is then used to synchronise the `ACK` and `SEQ` fields in the TCP communication, so that the TCP proxies in the UE 510 and the RNC 515 are able to generate TCP ACKs (and NACKs) that appear to be from the end-point of the entire TCP connection (e.g. they appear to be end-to-end)…wherein both receive and transmit side synchronising TCP proxy functionality is provided at both the UE and in the RAN. In accordance with one embodiment of the invention, the TCP protocol accelerator logic is arranged to reside in PDCP. Therefore, since the functionality is a TCP-proxy synchronization functionality and the TCP accelerator is in the PDCP, the PDCP TCP context that is created will be based on the received connection request and will include information requesting the PDCP layer of the base station to create the context for TCP processing) and indicates that the PDCP layer of the terminal and the PDCP layer of the base station each perform at least part of a TCP procedure in advance (Speight: Fig. 5, ¶ 65 – 71, ¶ 81; wherein the synchronising TCP proxy in both the UE 510 and the RNC 315 are configured to allow the known 3-way handshake (`SYN` 542, `SYN ACK` 544 and `ACK` 546) to transparently pass therethrough, for the end-to-end communication between the PC 505 and, say, a web server 520. Thus, the information contained within these `synchronising` TCP messages is then used to synchronise the `ACK` and `SEQ` fields in the TCP communication, so that the TCP proxies in the UE 510 and the RNC 515 are able to generate TCP ACKs (and NACKs) that appear to be from the end-point of the entire TCP connection (e.g. they appear to be end-to-end)… When the 3-way handshake is passed through the proxies, the proxies are then able to ensure that any subsequent TCP ACKs that they generate use the appropriate SEQ number, which was negotiated in the 3-way handshake……As soon as the network side proxy allows data segment 546 through the `synchronising proxy` it sends a TCP ACK 552 back to the server… the proxy generates what are typically known as ‘early ACKs’. Therefore, since the TCP accelerator is in the PDCP of at both the UE and the RAN, and the proxy generates early ACKs, thus, the PDCP layer of the terminal and the PDCP layer of the base station each perform part of the TCP procedure in advance);
transmitting, to the PDCP layer of the terminal, a response to the initial PDCP TCP context, the response indicating acceptance of the information requesting the PDCP layer of the base station to create a context for TCP processing, the information being included in the PDCP TCP context (Speight: Fig. 5, ¶ 65 – 71, ¶ 81; wherein the synchronising TCP proxy in both the UE 510 and the RNC 315 are configured to allow the known 3-way handshake (`SYN` 542, `SYN ACK` 544 and `ACK` 546) to transparently pass therethrough, for the end-to-end communication between the PC 505 and, say, a web server 520. Therefore, the base station transmits an ACK in response to the PDCP TCP context); in response to receiving the connection permission TCP packet, generating a connection establishment TCP packet to be transmitted to the TCP server (Speight: Fig. 5, ¶ 65 – 69, ¶ 72, ¶ 111; wherein the TCP ACK generated by the PC 550 is examined at the proxy at the UE end and since it is determined to contain no data, i.e. it is only a TCP ACK, it is terminated and not sent over the air interface (as the proxy at the network end has already in step 552, ACKed the data segment 546. Therefore, when the base station receives the connection permission TCP packet, it generates a connection establishment and sends data segment 546 and the Proxy ACK 552 is sent to the server); and
transmitting, to the TCP server, the connection establishment TCP packet without receiving the connection establishment TCP packet from the PDCP layer of the terminal (Speight: Fig. 5, ¶ 65 – 69, ¶ 72, ¶ 111; wherein the TCP ACK generated by the PC 550 is examined at the proxy at the UE end and since it is determined to contain no data, i.e. it is only a TCP ACK, it is terminated and not sent over the air interface (as the proxy at the network end has already in step 552, ACKed the data segment 546). Therefore, when the ACK is generated at the RNC (ACK 552) it is sent to the Web server, and when the ACK is generated at the UE side, it is then discarded without transmitting it to the base station, so the base station will not receive the connection establishment TCP packet form the PDCP layer of the terminal).
Thus, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the PDCP context creation and transmission teachings of Speight into the TCP procedure teachings of Jung in order to achieve effective utilization of TCP packets, reliable data delivery, and to provide efficient security, and integrity, all of which are critical for maintaining TCP’s performance and stability.
Jung in view of Speight does not explicitly teach that the PDCP TCP context is an initial PDCP TCP context; and creating the PDCP TCP context.
Referring to the invention of Kim, Kim teaches receiving an initial PDCP TCP context from the terminal (Kim: Fig. 8, Fig. 10, ¶ 126-127, ¶ 140-143; wherein the UE RRC (i.e., in response to the context request triggering condition (CRTC) of the UE PDCP in step 810 of Fig. 8) creates … a PDCP context request message to the RNC RRC);
creating the PDCP TCP context (Kim: Fig. 8, Fig. 10, ¶ 126-127, ¶ 140-143; wherein after transmitting the PDCP context request message, the UE RRC determines, at step 1015, whether a PDCP context response message is received. If a PDCP context response message is received, the UE RRC moves to step 1020, otherwise it returns to step 1015 to wait until a PDCP context response message is received… At step 830, in response to the CPDCP context request message (CPDCP-CONTEXT-REQ), the RNC PDCP transfers a CPDCP context response message (CPDCP-CONTEXT-RES) including the context information (CONTEXT INFO) to the RNC RRC. At step 835, the RNC RRC transfers a PDCP context response message (PDCP-CONTEXT-RES) to the UE RRC through an RRC message)).
Thus, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the PDCP-based TCP accelerator of Jung and Speight to employ the PDCP context request/response procedure of Kim when establishing the TCP-processing state between the terminal-side PDCP entity and the network-side PDCP entity. Using Kim’s established PDCP context request/response procedure to request, establish, and confirm the TCP-processing state required by Speight would merely provide a known signaling mechanism for establishing the state already required by Speight’s synchronized TCP proxies. The resulting system will predictably permit the terminal PDCP entity and network PDCP entity to establish corresponding TCP-processing contexts before performing the subsequent TCP acceleration operations.
Regarding claim 12, Jung teaches a terminal comprising at least one processor (Jung: Fig. 18, ¶ 251; In view of the terminal 130 may be implemented with one processor), wherein the at least one processor causes the terminal to perform:
receiving a connection request transmission control protocol (TCP) packet from a TCP client of the terminal (Jung: Fig. 15, ¶ 214-215; wherein a TCP layer 145 in a terminal 130 generates a TCP session through a TCP 3-way handshake with a server 150. That is, the server 150 transmits a TCP synchronization (TCP SYN) message to the TCP layer 145 in the terminal at operation 1501, and the TCP layer 145 in the terminal 130 transmits a response message in response to the TCP SYN message received from the server 150 while transmitting the TCP SYN message to the server 150 at operation 1503. Therefore, as shown in Fig. 15, whenever the TCP layer 145 (i.e., the TCP client) transmits to the server or receives from the server, the message is sent through the PDCP layer 137 (i.e., the PDCP layer) of the terminal. Thus, when the TCP layer 145 sends the response message in response to the TCP SYN (i.e., the connection request TCP packet) to the server, the PDCP of the terminal will receive the TCP packet before sending it to the server);
transmitting the connection request TCP packet to a base station (Jung: Fig. 15, ¶ 214-215; wherein the TCP layer 145 in the terminal 130 transmits a response message in response to the TCP SYN message received from the server 150 while transmitting the TCP SYN message to the server 150 at operation 1503. Therefore, when the TCP layer 145 sends the response message in response to the TCP SYN (i.e., the connection request TCP packet) to the server, the PDCP of the terminal will receive the TCP packet before sending it to the server);
receiving a connection permission TCP packet from a TCP server through the base station (Jung: Fig. 15, ¶ 214-215; wherein the server 150 transmits, to the terminal 130, a response message in response to the TCP SYN message received from the terminal 130 at operation 1505. Therefore, when the server sends the response TCP ACK message in response to the TCP SYN (i.e., the connection request TCP packet) to the terminal, the PDCP of the terminal will receive the TCP packet before sending it to the TCP client of the terminal);
delivering the connection permission TCP packet to the TCP client (Jung: Fig. 15, ¶ 214-215; wherein the PDCP of the terminal will receive the TCP packet before sending it to the TCP client of the terminal, and the PDCP layer of the terminal sends it to the TCP layer of the terminal); and
receiving, from the TCP client, a connection establishment TCP packet in response to the connection permission TCP packet (Jung: Fig. 15, ¶ 214-215; wherein the server 150 transmits, to the terminal 130, a response message in response to the TCP SYN message received from the terminal 130 at operation 1505. Therefore, when the server sends the response TCP ACK message in response to the TCP SYN (i.e., the connection request TCP packet) to the terminal, the PDCP of the terminal will receive the TCP packet before sending it to the TCP client of the terminal and the TCP client of the terminal will obviously send a connection establishment message back to the PDCP of the terminal as part of the TCP 3-way handshake).
Jung does not explicitly teach creating an initial PDCP TCP context based on the received connection request TCP packet, wherein the initial PDCP TCP context includes information requesting a PDCP layer of the base station to create a context for TCP processing and indicates that the PDCP layer of the terminal and the PDCP layer of the base station each perform at least part of a TCP procedure in advance; transmitting the initial PDCP TCP context to the base station; receiving a response to the initial PDCP TCP context from the base station; and discarding, without transmitting to the base station, the received connection establishment TCP packet based on the response indicating acceptance of the request for the PDCP layer of the base station to create a context for TCP processing, the request being included in the initial PDCP TCP context.
Referring to the invention of Speight, Speight teaches creating a PDCP TCP context based on the received connection request TCP packet, wherein the PDCP TCP context includes information requesting a PDCP layer of the base station to create a context for TCP processing (Speight: Fig. 5, ¶ 65 – 69, ¶ 81; wherein the synchronising TCP proxy in both the UE 510 and the RNC 315 are configured to allow the known 3-way handshake (`SYN` 542, `SYN ACK` 544 and `ACK` 546) to transparently pass therethrough, for the end-to-end communication between the PC 505 and, say, a web server 520. Thus, the information contained within these `synchronising` TCP messages is then used to synchronise the `ACK` and `SEQ` fields in the TCP communication, so that the TCP proxies in the UE 510 and the RNC 515 are able to generate TCP ACKs (and NACKs) that appear to be from the end-point of the entire TCP connection (e.g. they appear to be end-to-end)…wherein both receive and transmit side synchronising TCP proxy functionality is provided at both the UE and in the RAN. In accordance with one embodiment of the invention, the TCP protocol accelerator logic is arranged to reside in PDCP. Therefore, since the functionality is a TCP-proxy synchronization functionality and the TCP accelerator is in the PDCP, the PDCP TCP context that is created will be based on the received connection request and will include information requesting the PDCP layer of the base station to create the context for TCP processing) and indicates that the PDCP layer of the terminal and the PDCP layer of the base station each perform at least part of a TCP procedure in advance (Speight: Fig. 5, ¶ 65 – 71, ¶ 81; wherein the synchronising TCP proxy in both the UE 510 and the RNC 315 are configured to allow the known 3-way handshake (`SYN` 542, `SYN ACK` 544 and `ACK` 546) to transparently pass therethrough, for the end-to-end communication between the PC 505 and, say, a web server 520. Thus, the information contained within these `synchronising` TCP messages is then used to synchronise the `ACK` and `SEQ` fields in the TCP communication, so that the TCP proxies in the UE 510 and the RNC 515 are able to generate TCP ACKs (and NACKs) that appear to be from the end-point of the entire TCP connection (e.g. they appear to be end-to-end)… When the 3-way handshake is passed through the proxies, the proxies are then able to ensure that any subsequent TCP ACKs that they generate use the appropriate SEQ number, which was negotiated in the 3-way handshake……As soon as the network side proxy allows data segment 546 through the `synchronising proxy` it sends a TCP ACK 552 back to the server… the proxy generates what are typically known as ‘early ACKs’. Therefore, since the TCP accelerator is in the PDCP of at both the UE and the RAN, and the proxy generates early ACKs, thus, the PDCP layer of the terminal and the PDCP layer of the base station each perform part of the TCP procedure in advance); and
discarding, without transmitting to the base station, the received connection establishment TCP packet based on the response indicating acceptance of the request for the PDCP layer of the base station to create a context for TCP processing, the request being included in the PDCP TCP context (Speight: Fig. 5, ¶ 65 – 69, ¶ 72, ¶ 111; wherein the TCP ACK generated by the PC 550 is examined at the proxy at the UE end and since it is determined to contain no data, i.e. it is only a TCP ACK, it is terminated and not sent over the air interface (as the proxy at the network end has already in step 552, ACKed the data segment 546)... after the segment with SEQ2000 is seen at the network side proxy 556, a TCP ACK is generated 572 that acknowledges the correct reception of both the segment with SEQ1000 and the segment with SEQ2000. The network side proxy 556 allows these segments to be sent to lower layers in the radio access network and they are subsequently sent through the proxy at the UE 555 to PC 505. An ACK is generated by the PC 570. However, this ACK is discarded at the proxy at the UE 555, as the segments have already been acknowledged by the proxy generated ACK 572 Therefore, when the ACK is generated at the UE side, it is then discarded without transmitting it to the base station).
Thus, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the PDCP context creation and transmission teachings of Speight into the TCP procedure teachings of Jung in order to achieve effective utilization of TCP packets, reliable data delivery, and to provide efficient security, and integrity, all of which are critical for maintaining TCP’s performance and stability.
Jung in view of Speight does not explicitly teach that the PDCP TCP context is an initial PDCP TCP context, wherein the initial PDCP TCP context includes information requesting a PDCP layer of the base station to create a context for TCP processing; transmitting the initial PDCP TCP context to the base station; and receiving a response to the initial PDCP TCP context from the base station.
Referring to the invention of Kim, Kim teaches creating an initial PDCP TCP context based on the TCP connection request (Kim: Fig. 8, ¶ Fig. 10, ¶ 119 – 127, ¶ 140-143; wherein the UE RRC (i.e., in response to the context request triggering condition (CRTC) of the UE PDCP in step 810 of Fig. 8) creates … a PDCP context request message to the RNC RRC. Therefore, the UE sends a PDCP context request, an RNC PDCP determines context information, and an RNC returns a PDCP context response), wherein the initial PDCP TCP context includes information requesting a PDCP layer of the base station to create a context for TCP processing (Kim: Fig. 8, ¶ Fig. 10, ¶ 119 – 127; wherein the UE RRC creates and transfers a PDCP context request message to the RNC RRC... The RNC RRC identifies a PDCP using the MBMS and RB IDs and transfers a CPDPD-CONTEXT-REQ to the identified PDCP entity… and the RNC PDCP determines the context information based on the received context request);
transmitting the initial PDCP TCP context to the base station (Kim: Fig. 8, Fig. 10, ¶ 119, ¶ 124, ¶ 140-143; wherein the UE RRC creates and transmits a PDCP context request message to the RNC RRC, and at step 825, the RNC RRC identifies a PDCP using the MBMS and RB IDs included in the received PDCP context request message, and transfers a CPDCP context request message (CPDCP-CONTEXT-REQ) including the CRTC code to the identified PDCP entity);
receiving a response to the initial PDCP TCP context from the base station (Kim: Fig. 8, Fig. 10, ¶ 126-127, ¶ 140-143; wherein after transmitting the PDCP context request message, the UE RRC determines, at step 1015, whether a PDCP context response message is received. If a PDCP context response message is received, the UE RRC moves to step 1020, otherwise it returns to step 1015 to wait until a PDCP context response message is received… At step 830, in response to the CPDCP context request message (CPDCP-CONTEXT-REQ), the RNC PDCP transfers a CPDCP context response message (CPDCP-CONTEXT-RES) including the context information (CONTEXT INFO) to the RNC RRC. At step 835, the RNC RRC transfers a PDCP context response message (PDCP-CONTEXT-RES) to the UE RRC through an RRC message).
Thus, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the PDCP-based TCP accelerator of Jung and Speight to employ the PDCP context request/response procedure of Kim when establishing the TCP-processing state between the terminal-side PDCP entity and the network-side PDCP entity. Using Kim’s established PDCP context request/response procedure to request, establish, and confirm the TCP-processing state required by Speight would merely provide a known signaling mechanism for establishing the state already required by Speight’s synchronized TCP proxies. The resulting system will predictably permit the terminal PDCP entity and network PDCP entity to establish corresponding TCP-processing contexts before performing the subsequent TCP acceleration operations.
Regarding claim 13, Jung in view of Speight and Kim teaches the terminal according to claim 12, wherein the at least one processor further causes the terminal to perform:
obtaining information on a size of a reception buffer of the TCP server included in the connection permission TCP packet (Jung: Fig. 15, ¶ 86, ¶ 219-220; wherein the X2-UP protocol provides information related to a current-desired buffer size per bearer, and information related to a current-minimum desired buffer size per terminal. Therefore, the terminal obtains information on a size of a reception buffer of the TCP server from the X2-UP protocol regarding the current-minimum desired buffer size per terminal).
Claims 3, 4, 14, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Jung et al., Speight et al., and Kim et al., as applied to claims 1, 7, and 12 above, and further in view of Kandasamy et al. [US 20200137628 A1] hereinafter Kandasamy.
Regarding claim 3, Jung in view of Speight and Kim teaches the processing method according to claim 1, further comprising.
Jung in view of Speight and Kim do not explicitly disclose the further steps comprising receiving, from the TCP client, data TCP packet(s) including data to be transmitted to the TCP server; obtaining information on a size of the data included in the data TCP packet(s); transmitting the data TCP packet(s) to the base station; generating an acknowledgment TCP packet corresponding to the data TCP packet(s) transmitted to the base station; and transmitting the acknowledgment TCP packet to the TCP client.
Referring to the invention of Kandasamy, Kandasamy teaches receiving, from the TCP client, data TCP packet(s) including data to be transmitted to the TCP server (Kandasamy: Fig. 5, ¶ 136; wherein the source 301 (i.e., TCP client) sends a TCP packet D1 (i.e., the data TCP packet including data) over the source TCP connection at step 504. The TCP packet D1 sent from the source 301 arrives to the source proxy 303 (i.e., the PDCP layer) over the source TCP connection…, the first single data packet that comprises the data section comprised in the TCP packet D1 and sent from the source proxy 303 to the destination proxy 305 (i.e., the server PDCP layer, and eventually to the server in step 507));
obtaining information on a size of the data included in the data TCP packet(s) (Kandasamy, ¶ 105; wherein the source proxy 303 and/or the destination proxy 305 may be configured to use TCP receive window buffer size to limit the amount of data to be sent over the wireless link 304);
transmitting the data TCP packet(s) to the base station (Kandasamy: Fig. 5, ¶ 138; wherein the destination proxy 305 (i.e., the PDCP layer of the server) … sends the reconstructed TCP packet D1 at step 507 to the destination 307 (i.e., the server). The source 301 (i.e., the TCP client) communicates with the destination 307 (i.e., the server) through the source proxy 303 (i.e., the PDCP layer of the terminal) and the destination proxy 307 (i.e., the PDCP layer of the server));
generating an acknowledgment TCP packet corresponding to the data TCP packet(s) transmitted to the base station (Kandasamy: Fig. 5, ¶ 136; wherein the source proxy 303 generates the ACK D1 at step 504 as shown in Fig. 5); and
transmitting the acknowledgment TCP packet to the TCP client (Kandasamy: Fig. 5, ¶ 136; wherein the source proxy 303 generates the ACK D1 at step 504, and transmits the ACK D1 to the source 301 as shown in Fig. 5).
Thus, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the data exchange procedure of Kandasamy into the combined inventions of Jung, Speight and Kim in order to provide simplified transmission protocols that enable a support of TCP traffics over wireless networks, enable exchange of TCP data between nodes/entities connected via constrained networks limited in terms of power/data rates/bandwidth, and to provide simple communication protocols combining a simple compression mode protocol performed on TCP data and header compression/decompression mechanism applied to IP datagrams enabling a reduction of the amount of data transmitted over wireless networks (Kandasamy: ¶ 59 – 61).
Regarding claim 4, Jung in view of Speight, Kim, and Kandasamy teaches the processing method according to claim 3, wherein the acknowledgment TCP packet is generated based on at least one of capability information of the terminal, information on a size of a reception buffer of the TCP server, or the information on the size of the data included in the data TCP packet(s) (Kandasamy, ¶ 105; wherein the source proxy 303 and/or the destination proxy 305 may be configured to use TCP receive window buffer size to limit the amount of data to be sent over the wireless link 304. Therefore, when the receive window buffer size is used to limit the amount of data to be sent, a person having ordinary skill in the art will understand that the acknowledgment will be based on the size of the data included in the data TCP packet).
Regarding claim 14, Jung in view of Speight and Kim teaches the terminal according to claim 12, wherein the at least one processor further causes the terminal to perform.
Jung in view of Speight and Kim do not explicitly disclose the further steps comprising receiving, from the TCP client, data TCP packet(s) including data to be transmitted to the TCP server; obtaining information on a size of the data included in the data TCP packet(s); transmitting the data TCP packet(s) to the base station; generating an acknowledgment TCP packet corresponding to the data TCP packet(s) transmitted to the base station; and transmitting the acknowledgment TCP packet to the TCP client.
Referring to the invention of Kandasamy, Kandasamy teaches receiving, from the TCP client, data TCP packet(s) including data to be transmitted to the TCP server (Kandasamy: Fig. 5, ¶ 136; wherein the source 301 (i.e., TCP client) sends a TCP packet D1 (i.e., the data TCP packet including data) over the source TCP connection at step 504. The TCP packet D1 sent from the source 301 arrives to the source proxy 303 (i.e., the PDCP layer) over the source TCP connection…, the first single data packet that comprises the data section comprised in the TCP packet D1 and sent from the source proxy 303 to the destination proxy 305 (i.e., the server PDCP layer, and eventually to the server in step 507));
obtaining information on a size of the data included in the data TCP packet(s) (Kandasamy, ¶ 105; wherein the source proxy 303 and/or the destination proxy 305 may be configured to use TCP receive window buffer size to limit the amount of data to be sent over the wireless link 304);
transmitting the data TCP packet(s) to the base station (Kandasamy: Fig. 5, ¶ 138; wherein the destination proxy 305 (i.e., the PDCP layer of the server) … sends the reconstructed TCP packet D1 at step 507 to the destination 307 (i.e., the server). The source 301 (i.e., the TCP client) communicates with the destination 307 (i.e., the server) through the source proxy 303 (i.e., the PDCP layer of the terminal) and the destination proxy 307 (i.e., the PDCP layer of the server));
generating an acknowledgment TCP packet corresponding to the data TCP packet(s) transmitted to the base station (Kandasamy: Fig. 5, ¶ 136; wherein the source proxy 303 generates the ACK D1 at step 504 as shown in Fig. 5); and
transmitting the acknowledgment TCP packet to the TCP client (Kandasamy: Fig. 5, ¶ 136; wherein the source proxy 303 generates the ACK D1 at step 504, and transmits the ACK D1 to the source 301 as shown in Fig. 5).
Thus, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the data exchange procedure of Kandasamy into the combined inventions of Jung, Speight and Kim in order to provide simplified transmission protocols that enable a support of TCP traffics over wireless networks, enable exchange of TCP data between nodes/entities connected via constrained networks limited in terms of power/data rates/bandwidth, and to provide simple communication protocols combining a simple compression mode protocol performed on TCP data and header compression/decompression mechanism applied to IP datagrams enabling a reduction of the amount of data transmitted over wireless networks (Kandasamy: ¶ 59 – 61).
Regarding claim 15, Jung in view of Speight, Kim, and Kandasamy teaches the terminal according to claim 14, wherein the acknowledgment TCP packet is generated based on at least one of capability information of the terminal, information on a size of a reception buffer of the TCP server, or the information on the size of the data included in the data TCP packet(s) (Kandasamy, ¶ 105; wherein the source proxy 303 and/or the destination proxy 305 may be configured to use TCP receive window buffer size to limit the amount of data to be sent over the wireless link 304. Therefore, when the receive window buffer size is used to limit the amount of data to be sent, a person having ordinary skill in the art will understand that the acknowledgment will be based on the size of the data included in the data TCP packet).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Jung et al., Speight et al., and Kim et al., as applied to claims 1, 7, and 12 above, and further in view of Kandasamy et al. [US 20200137628 A1] hereinafter Kandasamy, and Sivakumar et al. [US 20070223379 A1] hereinafter Sivakumar.
Regarding claim 8, Jung in view of Speight and Kim teaches the processing method according to claim 7, further comprising.
Jung in view of Speight and Kim do not explicitly disclose receiving, from the terminal, data TCP packet(s) including data to be transmitted to the TCP server; transmitting the received data TCP packet(s) to the TCP server; and in response to receiving an acknowledgment TCP packet for the data TCP packet(s) from the TCP server, discarding the acknowledgment TCP packet.
Referring to the invention of Kandasamy, Kandasamy teaches receiving, from the terminal, data TCP packet(s) including data to be transmitted to the TCP server (Kandasamy: Fig. 5, ¶ 136; wherein the source 301 (i.e., TCP client) sends a TCP packet D1 (i.e., the data TCP packet including data) over the source TCP connection at step 504. The TCP packet D1 sent from the source 301 arrives to the source proxy 303 (i.e., the PDCP layer) over the source TCP connection…, the first single data packet that comprises the data section comprised in the TCP packet D1 and sent from the source proxy 303 to the destination proxy 305 (i.e., the server PDCP layer, and eventually to the server in step 507));
transmitting the received data TCP packet(s) to the TCP server (Kandasamy: Fig. 5, ¶ 138; wherein the destination proxy 305 (i.e., the PDCP layer of the server) … sends the reconstructed TCP packet D1 at step 507 to the destination 307 (i.e., the server). The source 301 (i.e., the TCP client) communicates with the destination 307 (i.e., the server) through the source proxy 303 (i.e., the PDCP layer of the terminal) and the destination proxy 307 (i.e., the PDCP layer of the server)).
Thus, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the data exchange procedure of Kandasamy into the combined inventions of Jung, Speight, and Kim in order to provide simplified transmission protocols that enable a support of TCP traffics over wireless networks, enable exchange of TCP data between nodes/entities connected via constrained networks limited in terms of power/data rates/bandwidth, and to provide simple communication protocols combining a simple compression mode protocol performed on TCP data and header compression/decompression mechanism applied to IP datagrams enabling a reduction of the amount of data transmitted over wireless networks (Kandasamy: ¶ 59 – 61).
Jung in view of Speight, Kim, and Kandasamy do not explicitly disclose in response to receiving an acknowledgment TCP packet for the data TCP packet(s) from the TCP server, discarding the acknowledgment TCP packet.
Referring to the invention of Sivakumar, Sivakumar teaches in response to receiving an acknowledgment TCP packet for the data TCP packet(s) from the TCP server, discarding the acknowledgment TCP packet (Sivakumar: Fig. 4, ¶ 41 – 42; wherein after receiving the TCP packet from the state manager 340, the connection terminator 350 classifies (450) the TCP packet. If the TCP packet is an ACK, the connection terminator 350 performs appropriate housekeeping as indicated by receipt of the acknowledgement, and discards or consumes the ACK. Therefore, a component of the server can dismiss the TCP ACK packet upon receiving it).
Thus, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the ACK packet discarding teachings of Sivakumar into the combined inventions of Jung, Speight, Kim, and Kandasamy in order to reduce network overhead and to avoid duplicating ACKs.
Claims 5, 6, 9, 10, 11, 16, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Jung et al., Speight et al., and Kim et al., as applied to claims 1, 7, and 12 above, and further in view of Ulupinar et al. [US 20100260126 A1] hereinafter Ulupinar, and Yasuda et al. [US 20180376535 A1] hereinafter Yasuda.
Regarding claim 5, Jung in view of Speight and Kim teaches the processing method according to claim 1, further comprising:
in response to receiving a TCP packet, transmitting, to the base station, a first PDCP message including PDCP TCP context deletion preparation request information; and receiving, from the base station, a second PDCP message including information indicating that a PDCP TCP context of the base station is ready to be deleted (Kim: Fig. 12, ¶ 149, ¶ 154; in view of, at step 1220, the RNC PDCP transmits the context information parameter to the RNC RRC through a CPDCP context response message, and then terminates the procedure. When the protocol is a PDCP protocol, a person having ordinary skill in the art would find it obvious that the messages transmitted between the devices will be PDCP messages since they are within the PDCP protocol. The transmission of a plurality of messages is also obvious to one of ordinary skill in the art as each device may receive and respond to the message it receives).
Assuming arguendo that Kim only discloses the PDCP context termination on the server side while the claim limitations describe a transfer of messages from the PDCP of the UE to the base station, referring to the invention of Ulupinar, Ulupinar teaches that transport protocols related to base stations or terminals can terminate at the base station side of the connection (Ulupinar: ¶ 46 – 48, ¶ 57 – 58: wherein transport protocols related to relay eNB 108 or UE 110 communications can terminate at the donor eNB 102,… PDCP context generating component 304 can create a PDCP context for UE 110… and the PDCP layer is terminated at donor eNB 102).
Thus, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the transport protocols being terminated at a different location teachings of Ulupinar into the combined teachings of Jung, Speight, and Kim, in order to achieve reduced client-side processing load and to achieve faster connection release.
Jung in view of Speight, Kim, and Ulupinar does not explicitly teach receiving a connection termination TCP packet from the TCP client; transmitting the connection termination TCP packet to the base station.
Referring to the invention of Yasuda, Yasuda teaches receiving a connection termination TCP packet from the TCP client (Yasuda: Fig. 2, ¶ Fig. 7, ¶ 137 – 141; wherein a packet relating to termination of a TCP connection is transmitted and received between the application program 115-1 and the application program 115-5 through the delivery node 101-1);
transmitting the connection termination TCP packet to the base station (Yasuda: Fig. 2, ¶ Fig. 7, ¶ 137 – 141; wherein a packet relating to termination of a TCP connection is transmitted and received between the application program 115-1 (i.e., The TCP client of the UE) and the application program 115-5 (i.e., the TCP server of the base station) through the delivery node 101-1).
Thus, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the TCP connection termination teachings of Yasuda into the TCP connection teachings of the combined invention of Jung, Speight, Kim and Ulupinar in order to avoid unnecessary waste of resources and to limit the overhead.
In view of the combined teachings of Jung, Speight, Kim, Ulupinar, and Yasuda, a person of ordinary skill in the art will find that incorporating their combined teachings will obviously satisfy and meet the claim limitations as a whole.
Regarding claim 6, Jung in view of Speight, Kim, Ulupinar, and Yasuda teaches the processing method according to claim 5, further comprising:
in response to receiving an acknowledgment TCP packet for TCP connection termination from the TCP client, transmitting the acknowledgment TCP packet to the base station (Yasuda: Fig. 7, ¶ 140 – 141; wherein upon receiving the acknowledgement packet and the connection termination request packet from the application program 115-5, the application program 111-1 transmits an acknowledgement packet in response to the received connection termination request packet to the application program 115-5. This acknowledgement packet is sent to the application program 111-5 by the same procedure as the procedure at steps S160 to S165 (steps S172 to S177));
in response to transmitting the acknowledgment TCP packet for TCP connection termination, transmitting, to the base station, a third PDCP TCP message requesting deletion of the PDCP TCP context; and deleting the PDCP TCP context (Kim: Fig. 12, ¶ 149, ¶ 154; in view of, at step 1220, the RNC PDCP transmits the context information parameter to the RNC RRC through a CPDCP context response message, and then terminates the procedure).
Regarding claim 9, Jung in view of Speight and Kim teaches the processing method according to claim 7, further comprising:
receiving a first PDCP message including PDCP TCP context deletion preparation request information from the terminal; and in response to the first PDCP message, transmitting, to the terminal, a second PDCP message including information indicating that the PDCP TCP context is ready to be deleted (Kim: Fig. 12, ¶ 149, ¶ 154; in view of, at step 1220, the RNC PDCP transmits the context information parameter to the RNC RRC through a CPDCP context response message, and then terminates the procedure. When the protocol is a PDCP protocol, a person having ordinary skill in the art would find it obvious that the messages transmitted between the devices will be PDCP messages since they are within the PDCP protocol. The transmission of a plurality of messages is also obvious to one of ordinary skill in the art as each device may receive and respond to the message it receives).
Assuming arguendo that Kim only discloses the PDCP context termination on the server side while the claim limitations describe a transfer of messages from the PDCP of the UE to the base station, referring to the invention of Ulupinar, Ulupinar teaches that transport protocols related to base stations or terminals can terminate at the base station side of the connection (Ulupinar: ¶ 46 – 48, ¶ 57 – 58: wherein transport protocols related to relay eNB 108 or UE 110 communications can terminate at the donor eNB 102,… PDCP context generating component 304 can create a PDCP context for UE 110… and the PDCP layer is terminated at donor eNB 102).
Thus, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the transport protocols being terminated at a different location teachings of Ulupinar into the combined teachings of Jung, Kim, and Kiji in order to achieve reduced client-side processing load and to achieve faster connection release.
Jung in view of Speight, Kim, and Ulupinar does not explicitly teach receiving a connection termination TCP packet from the terminal; transmitting the connection termination TCP packet to the TCP server.
Referring to the invention of Yasuda, Yasuda teaches receiving a connection termination TCP packet from the terminal (Yasuda: Fig. 2, ¶ Fig. 7, ¶ 137 – 141; wherein a packet relating to termination of a TCP connection is transmitted and received between the application program 115-1 and the application program 115-5 through the delivery node 101-1);
transmitting the connection termination TCP packet to the TCP server (Yasuda: Fig. 2, ¶ Fig. 7, ¶ 137 – 141; wherein a packet relating to termination of a TCP connection is transmitted and received between the application program 115-1 (i.e., The TCP client of the UE) and the application program 115-5 (i.e., the TCP server of the base station) through the delivery node 101-1).
Thus, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the TCP connection termination teachings of Yasuda into the TCP connection teachings of the combined invention of Jung, Speight, Kim, and Ulupinar in order to avoid unnecessary waste of resources and to limit the overhead.
In view of the combined teachings of Jung, Speight, Kim, Ulupinar, and Yasuda, a person of ordinary skill in the art will find that incorporating their combined teachings will obviously satisfy and meet the claim limitations as a whole.
Regarding claim 10, Jung in view of Speight, Kim, Ulupinar, and Yasuda teaches the processing method according to claim 9, further comprising:
receiving an acknowledgment TCP packet for TCP connection termination from the TCP server; and transmitting the acknowledgment TCP packet to the terminal (Yasuda: Fig. 7, ¶ 140 – 141; wherein upon receiving the acknowledgement packet and the connection termination request packet from the application program 115-5, the application program 111-1 transmits an acknowledgement packet in response to the received connection termination request packet to the application program 115-5. This acknowledgement packet is sent to the application program 111-5 by the same procedure as the procedure at steps S160 to S165 (steps S172 to S177)).
Regarding claim 11, Jung in view of Speight, Kim, Ulupinar, and Yasuda teaches the processing method according to claim 10, further comprising:
receiving the acknowledgment TCP packet for the TCP connection termination from the terminal; transmitting the acknowledgment TCP packet to the TCP server (Yasuda: Fig. 7, ¶ 140 – 141; wherein upon receiving the acknowledgement packet and the connection termination request packet from the application program 115-5, the application program 111-1 transmits an acknowledgement packet in response to the received connection termination request packet to the application program 115-5. This acknowledgement packet is sent to the application program 111-5 by the same procedure as the procedure at steps S160 to S165 (steps S172 to S177));
receiving, from the terminal, a third PDCP TCP message requesting deletion of the PDCP TCP context; and in response to the third PDCP message, deleting the PDCP TCP context (Kim: Fig. 12, ¶ 149, ¶ 154; in view of, at step 1220, the RNC PDCP transmits the context information parameter to the RNC RRC through a CPDCP context response message, and then terminates the procedure).
Regarding claim 16, Jung in view of Speight and Kim teaches the terminal according to claim 12, wherein the at least one processor further causes the terminal to perform:
in response to receiving a TCP packet, transmitting, to the base station, a first PDCP message including PDCP TCP context deletion preparation request information; and receiving, from the base station, a second PDCP message including information indicating that a PDCP TCP context of the base station is ready to be deleted (Kim: Fig. 12, ¶ 149, ¶ 154; in view of, at step 1220, the RNC PDCP transmits the context information parameter to the RNC RRC through a CPDCP context response message, and then terminates the procedure. When the protocol is a PDCP protocol, a person having ordinary skill in the art would find it obvious that the messages transmitted between the devices will be PDCP messages since they are within the PDCP protocol. The transmission of a plurality of messages is also obvious to one of ordinary skill in the art as each device may receive and respond to the message it receives).
Assuming arguendo that Kim only discloses the PDCP context termination on the server side while the claim limitations describe a transfer of messages from the PDCP of the UE to the base station, referring to the invention of Ulupinar, Ulupinar teaches that transport protocols related to base stations or terminals can terminate at the base station side of the connection (Ulupinar: ¶ 46 – 48, ¶ 57 – 58: wherein transport protocols related to relay eNB 108 or UE 110 communications can terminate at the donor eNB 102,… PDCP context generating component 304 can create a PDCP context for UE 110… and the PDCP layer is terminated at donor eNB 102).
Thus, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the transport protocols being terminated at a different location teachings of Ulupinar into the combined teachings of Jung, Speight, and Kim in order to achieve reduced client-side processing load and to achieve faster connection release.
Jung in view of Speight, Kim, and Ulupinar does not explicitly teach receiving a connection termination TCP packet from the TCP client; transmitting the connection termination TCP packet to the base station.
Referring to the invention of Yasuda, Yasuda teaches receiving a connection termination TCP packet from the TCP client (Yasuda: Fig. 2, ¶ Fig. 7, ¶ 137 – 141; wherein a packet relating to termination of a TCP connection is transmitted and received between the application program 115-1 and the application program 115-5 through the delivery node 101-1);
transmitting the connection termination TCP packet to the base station (Yasuda: Fig. 2, ¶ Fig. 7, ¶ 137 – 141; wherein a packet relating to termination of a TCP connection is transmitted and received between the application program 115-1 (i.e., The TCP client of the UE) and the application program 115-5 (i.e., the TCP server of the base station) through the delivery node 101-1).
Thus, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to incorporate the TCP connection termination teachings of Yasuda into the TCP connection teachings of the combined invention of Jung, Kim, Kiji and Ulupinar in order to avoid unnecessary waste of resources and to limit the overhead.
In view of the combined teachings of Jung, Speight, Kim, Ulupinar, and Yasuda, a person of ordinary skill in the art will find that incorporating their combined teachings will obviously satisfy and meet the claim limitations as a whole.
Regarding claim 17, Jung in view of Speight, Kim, Ulupinar, and Yasuda teaches the terminal according to claim 16, wherein the at least one processor further causes the terminal to perform:
in response to receiving an acknowledgment TCP packet for TCP connection termination from the TCP client, transmitting the acknowledgment TCP packet to the base station (Yasuda: Fig. 7, ¶ 140 – 141; wherein upon receiving the acknowledgement packet and the connection termination request packet from the application program 115-5, the application program 111-1 transmits an acknowledgement packet in response to the received connection termination request packet to the application program 115-5. This acknowledgement packet is sent to the application program 111-5 by the same procedure as the procedure at steps S160 to S165 (steps S172 to S177));
in response to transmitting the acknowledgment TCP packet for TCP connection termination, transmitting, to the base station, a third PDCP TCP message requesting deletion of the PDCP TCP context; and deleting the PDCP TCP context (Kim: Fig. 12, ¶ 149, ¶ 154; in view of, at step 1220, the RNC PDCP transmits the context information parameter to the RNC RRC through a CPDCP context response message, and then terminates the procedure).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Chaskar et al. [US 20050185664 A1] - Method And Apparatus Providing A Protocol To Enable A Wireless TCP Session Using A Split TCP Connection: Chaskar discloses sending a split TCP connection request from the MS to a PEP located in the network, where the split TCP request includes information for identifying a network address of the MS and a network address of the end point destination.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 HIDAYAT DABIRI whose telephone number is (703)756-4541. The examiner can normally be reached M-F 8:00 am - 4:00 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Edan Orgad can be reached on 571-272-7884. 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.
/HD/Examiner, Art Unit 2414
/EDAN ORGAD/Supervisory Patent Examiner, Art Unit 2414
Prosecution Insights