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 02/22/2024, 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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 12/06/2023 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION. —The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1 – 6 and 12 – 17 are 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. See MPEP § 2172.01. The omitted elements or steps are:
“The client 501 may transmit a ‘connection establishment TCP packet’ to the server 502 in response to the connection permission TCP packet (S504)” as shown in paragraph 97 of the disclosure.
Regarding Claims 1 and 12, claims 1 and 12 recites the limitation “in response to receiving a connection establishment TCP packet from the TCP client, discarding the received connection establishment TCP packet” in Lines 13 – 14 respectively. The step of transmitting a connection establishment TCP packet to the server in response to the connection permission TCP packet is omitted in the claim limitations. This omission creates a gap in the elements and steps of the method or process, thereby making the claim limitations unclear. There is no step prior to the expression on line 13 that implies the receiving of a connection establishment, or an apparatus that indicates the receiving of a connection establishment. None of the steps leading up to the expression on line 13 relate to receiving a connection establishment. Rather, they relate to other steps such as receiving a connection request TCP packet and transmitting that connection request TCP packet to the base station. Another step relates to receiving a connection permission TCP packet from the TCP server through the base station, and delivering the connection permission TCP packet to the TCP client.
In order for there to be a step of receiving a connection establishment TCP packet from the TCP client, there has to be a step that shows or discloses that a connection establishment is processed or generated or created at the TCP client device. This step is missing in the claim limitations thereby omitting an essential element and creating a gap between the steps of the claim limitations. See MPEP § 2172.01. For the purpose of examination, the examiner will interpret the claims as best understood.
Claims 2 – 6, and 13 – 17 are also rejected since they depend upon rejected base claims 1 and 12 respectively. For the purpose of examination, the examiner will interpret these claims as best understood as well.
Claim Objections
Claim 6 and 17 are objected to because of the following informalities:
Claims 6 and 17 recite the claim limitation “transmitting, the base station” in line 6 and line 7 respectively. This limitation seems to be missing a preposition and it renders the claim limitation unclear. A preposition is required for definiteness of the claim.
Appropriate correction is required.
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 Kim et al. [US 20050094670 A1] hereinafter Kim, and Kiji et al. [JP 2009038731 A] (see machine translation attached) hereinafter Kiji.
Regarding claim 1, as best understood, Jung teaches a processing method in a packet data convergence protocol (PDCP) 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);
Jung does not explicitly teach creating an initial PDCP TCP context to 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 in response to receiving a connection establishment TCP packet from the TCP client, discarding the received connection establishment TCP packet.
Referring to the invention of Kim, Kim teaches creating an initial PDCP TCP context (Kim: Fig. 8, ¶ Fig. 10, ¶ 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); transmitting the initial PDCP TCP context to the base station (Kim: Fig. 8, ¶ Fig. 10, ¶ 140-143; wherein the UE RRC creates and transmits a PDCP context request message to the RNC RRC); receiving a response to the initial PDCP TCP context from the base station (Kim: Fig. 8, ¶ Fig. 10, ¶ 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).
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 Kim into the TCP procedure teachings of Jung in order to achieve effective utilization of TCP packets, reliable data delivery, and to provide efficient security, integrity, and header compression, all of which are critical for maintaining TCP’s performance and stability.
Although Kim does not explicitly state that the creation of the initial PDCP context is to perform at least part of a TCP procedure in advance, a person having ordinary skill in the art will find it obvious that when a PDCP context is created in a configuration for TCP procedure, the PDCP context will be for the purpose of performing at least part of the TCP procedure. Therefore, when the invention of Kim is incorporated into the invention of Jung, the limitation “creating an initial PDCP TCP context to perform at least part of a TCP procedure in advance” will obviously be met.
Jung in view of Kim does not explicitly disclose in response to receiving a connection establishment TCP packet from the TCP client, discarding the received connection establishment TCP packet.
Referring to the invention of Kiji, Kiji teaches in response to receiving a connection establishment TCP packet from the TCP client, discarding the received connection establishment TCP packet (Kiji: Fig. 4, Page 10, Para 9; wherein in step 314, the first packet reception processing unit 250 establishes a TCP connection with the network terminal that has transmitted the TCP connection establishment packet (port number = 443) to the second network interface 208. Instructs the terminal to send and receive a TCP connection establishment packet, and discards the packet. Therefore Kiji teaches that after a TCP connection is established between two network devices (one of which is a terminal), the TCP connection establishment packet is discarded).
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 establishment packet discarding teachings of Kiji into the TCP procedure teachings of Jung in view of Kim, in order to reduce overhead, free resources, speed up reconnections, and simplify network management.
Regarding claim 2, as best understood, Jung in view of Kim and Kiji 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, as best understood, 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 message requesting creation of a PDCP TCP context from the terminal; 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; and transmitting the connection establishment TCP packet to the TCP server, wherein the PDCP TCP context is a context for performing at least part of a TCP procedure in advance.
Referring to the invention of Kim, Kim teaches receiving an initial PDCP TCP context message requesting creation of a PDCP TCP context from the terminal (Kim: Fig. 8, ¶ Fig. 10, ¶ 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, ¶ 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); and
wherein the PDCP TCP context is a context for performing at least part of a TCP procedure in advance (Kim: Fig. 8, ¶ Fig. 10, ¶ 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).
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 Kim into the TCP procedure teachings of Jung in order to achieve effective utilization of TCP packets, reliable data delivery, and to provide efficient security, integrity, and header compression, all of which are critical for maintaining TCP’s performance and stability.
Although Kim does not explicitly state that the creation of the initial PDCP context is to perform at least part of a TCP procedure in advance, a person having ordinary skill in the art will find it obvious that when a PDCP context is created in a configuration for TCP procedure, the PDCP context will be for the purpose of performing at least part of the TCP procedure. Therefore, when the invention of Kim is incorporated into the invention of Jung, the limitation “creating an initial PDCP TCP context to perform at least part of a TCP procedure in advance” will obviously be met.
Jung in view of Kim does not explicitly disclose in response to receiving the connection permission TCP packet, generating a connection establishment TCP packet to be transmitted to the TCP server; and transmitting the connection establishment TCP packet to the TCP server.
Referring to the invention of Kiji, Kiji teaches in response to receiving the connection permission TCP packet, generating a connection establishment TCP packet to be transmitted to the TCP server; and transmitting the connection establishment TCP packet to the TCP server (Kiji: Fig. 4, Page 10, Para 9; wherein in step 314, the first packet reception processing unit 250 establishes a TCP connection with the network terminal that has transmitted the TCP connection establishment packet (port number = 443) to the second network interface 208. Instructs the terminal to send and receive a TCP connection establishment packet).
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 establishment packet discarding teachings of Kiji into the TCP procedure teachings of Jung in view of Kim, in order to reduce overhead, free resources, speed up reconnections, and simplify network management.
Regarding claim 12, as best understood, 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);
Jung does not explicitly teach creating an initial PDCP TCP context to 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 in response to receiving a connection establishment TCP packet from the TCP client, discarding the received connection establishment TCP packet.
Referring to the invention of Kim, Kim teaches creating an initial PDCP TCP context (Kim: Fig. 8, ¶ Fig. 10, ¶ 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); transmitting the initial PDCP TCP context to the base station (Kim: Fig. 8, ¶ Fig. 10, ¶ 140-143; wherein the UE RRC creates and transmits a PDCP context request message to the RNC RRC); receiving a response to the initial PDCP TCP context from the base station (Kim: Fig. 8, ¶ Fig. 10, ¶ 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).
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 Kim into the TCP procedure teachings of Jung in order to achieve effective utilization of TCP packets, reliable data delivery, and to provide efficient security, integrity, and header compression, all of which are critical for maintaining TCP’s performance and stability.
Although Kim does not explicitly state that the creation of the initial PDCP context is to perform at least part of a TCP procedure in advance, a person having ordinary skill in the art will find it obvious that when a PDCP context is created in a configuration for TCP procedure, the PDCP context will be for the purpose of performing at least part of the TCP procedure. Therefore, when the invention of Kim is incorporated into the invention of Jung, the limitation “creating an initial PDCP TCP context to perform at least part of a TCP procedure in advance” will obviously be met.
Jung in view of Kim does not explicitly disclose in response to receiving a connection establishment TCP packet from the TCP client, discarding the received connection establishment TCP packet.
Referring to the invention of Kiji, Kiji teaches in response to receiving a connection establishment TCP packet from the TCP client, discarding the received connection establishment TCP packet (Kiji: Fig. 4, Page 10, Para 9; wherein in step 314, the first packet reception processing unit 250 establishes a TCP connection with the network terminal that has transmitted the TCP connection establishment packet (port number = 443) to the second network interface 208. Instructs the terminal to send and receive a TCP connection establishment packet, and discards the packet. Therefore Kiji teaches that after a TCP connection is established between two network devices (one of which is a terminal), the TCP connection establishment packet is discarded).
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 establishment packet discarding teachings of Kiji into the TCP procedure teachings of Jung in view of Kim, in order to reduce overhead, free resources, speed up reconnections, and simplify network management.
Regarding claim 13, as best understood, Jung in view of Kim and Kiji 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., Kim et al., and Kiji 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, as best understood, Jung in view of Kim and Kiji teaches the processing method according to claim 1, further comprising.
Jung in view of Kim and Kiji 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, Kim and Kiji 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, as best understood, Jung in view of Kim, Kiji, 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, as best understood, Jung in view of Kim and Kiji teaches the terminal according to claim 12, wherein the at least one processor further causes the terminal to perform.
Jung in view of Kim and Kiji 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, Kim and Kiji 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, as best understood, Jung in view of Kim, Kiji, 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., Kim et al., and Kiji 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, as best understood, Jung in view of Kim and Kiji teaches the processing method according to claim 7, further comprising.
Jung in view of Kim and Kiji 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, Kim and Kiji 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 Kim, Kiji, 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, Kim, Kiji, 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., Kim et al., and Kiji 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, as best understood, Jung in view of Kim and Kiji 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, Kim, and Kiji in order to achieve reduced client-side processing load and to achieve faster connection release.
Jung in view of Kim, Kiji, 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, Kim, Kiji, 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, as best understood, Jung in view of Kim, Kiji, 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, 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, as best understood, Jung in view of Kim and Kiji 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 Kim, Kiji, 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, 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, Kim, Kiji, 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, as best understood, Jung in view of Kim, Kiji, 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, as best understood, Jung in view of Kim and Kiji 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, as best understood, Jung in view of Kim and Kiji 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, Kim, and Kiji in order to achieve reduced client-side processing load and to achieve faster connection release.
Jung in view of Kim, Kiji, 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, Kim, Kiji, 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, as best understood, Jung in view of Kim, Kiji, 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, 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.
Jo et al. [US 20240414246 A1] - Method And Apparatus For Performing Transmissions Based On Uplink Data Compression By User Equipment In Wireless Communication System: Jo discloses performing a transmission of a first PDCP SDU compressed based on a first UDC context, wherein the first UDC context is updated based on the first PDCP SDU.
Chiang et al. [US 20210068011 A1] - Base Station and Adjustment Method for Data Transmission: Chiang teaches about PDCP layer providing a reception buffer to store PDCP service data units (SDU) or other types of data , the reception buffer being provided with a predetermined or variable buffer size.
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