Continued Examination under 37 CFR 1.114
A request for continued examination (RCE) under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 10/30/2025 has been entered.
DETAILED ACTION
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 Amendment
This Action is in response to RCE with amendments filed on 10/30/2025.
Independent claims 1, 17, 23, and 25-26 have been amended. Claim 27 is newly added.
Claims 1-27 are presented for examination, and remain pending in this application.
Response to Arguments Regarding Claim Rejections - 35 USC § 103
Applicant’s arguments, see pages 8-11 of REMARKS, filed 10/30/2025, with respect to the rejection(s) of claims under 35 USC § 103, and specifically regarding cited reference to RYU et al. (hereinafter, RYU, WO 2014005077 A1) against amended independent claims, have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Takamichi (US 20060198376 A1).
Claim Objections
Claim 25 is objected to because of the following informalities:
Claim 25 recites “being included in the PDU being included in the PDU unit” in line 5. Examiner suggest amending the claim for clarity and to remove redundant recitations.
Appropriate correction is required.
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, 17, 23, and 25-26 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Independent claims are amended to recite (for e.g. see claimed concept of representative claim 1):
receiving, by the remote node, a Protocol Data Unit (PDU) from the ECU and differentiating, responsive to a flag in a header of the PDU, between (i)mailbox data that is both required to be received in order and to be intolerable of a data loss being included in the PDU and (ii) streaming data that is tolerable of the data loss being included in the PDU;
As highlighted in bold text above, the claims are drafted in a way that reads “data loss being included in the PDU”. This makes the claimed limitation unclear as to what is meant by data loss being included in the PDU. Therefore the claims are rejected as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, regards as the invention.
For examination purpose, the examiner interprets that the claims are meant to read as follows:
receiving, by the remote node, a Protocol Data Unit (PDU) from the ECU and differentiating, responsive to a flag in a header of the PDU, between (i)mailbox data being included in the PDU, wherein the mailbox data is both required to be received in order and to be intolerable of a data loss and (ii) streaming data being included in the PDU, wherein the streaming data is tolerable of the data loss;
Support for such interpretation can be found at least in paragraph [0084], as originally filed:
[0084] At block 1210, the method 1200 includes … differentiating between mailbox data and streaming data being included in the PDU responsive to a flag in a header of the PDU. The mailbox data is required to be received in order and to be intolerable of a data loss. The streaming data is tolerable of the data loss.
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 27 is rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends.
New claim 27 depends on independent claim 1, and recites “wherein mailbox data is both required to be received in order by the remote node and to be intolerable of a data loss”.
However, independent claim 1, as currently amended already recites “receiving, by the remote node, a Protocol Data Unit (PDU) from the ECU and differentiating, responsive to a flag in a header of the PDU, between (i) mailbox data that is both required to be received in order and to be intolerable of a data loss being included in the PDU and (ii) streaming data that is tolerable of the data loss being included in the PDU”. Therefore, dependent claim 27 fails to further limit the subject matter of the claim upon which it depends.
Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence in the application indicating obviousness or nonobviousness.
Claim(s) 1-2, 4, 6-10, 12, 15, 17-18, 20, 23 and 25-27 is/are rejected under 35 U.S.C. 103 as being unpatentable over Newman et al. (hereinafter, Newman, US 20140254351 A1) in view of Takamichi (US 20060198376 A1) in view of Kondrat et al. (hereinafter, Kondrat, US 7706255 B1).
Regarding claim 1, Newman discloses a computer-implemented method for managing data between an Electronic Control Unit (ECU) and a remote node of a system (see [0006]), the method comprising:
receiving, by the remote node, a Protocol Data Unit (PDU) from the ECU (see [0006]; a series of protocol data units (PDUs) are transmitted from a first device via at least a first path of a network to a second device), the mailbox data that is both required to be received in order and to be intolerable of a data loss being included in the PDU (see [0028]; the destination device must make sure the PDUs are delivered to upper layers in a proper order; lost PDUs may be omitted as long as the number of lost PDUs does not exceed the loss tolerance; also see [0055]; Sequence numbering ensures that the frames received are guaranteed to be in the order they have been sent, and no frames are lost);
comparing, by the remote node, a sequence number of the PDU found in a sequence number field of the PDU (see [0054]-[0055]; a sequence number field in the Ethernet frame; Logical Link Control (LLC) type 2 header may be added to include the sequence numbers for a particular MAC layer PDU stream) to an expected sequence number of the PDU (see [0033]-[0034]; first device 110 and the second device 130 maintain a register of sequence numbers associated with the packet stream... the sequence numbers provide an identification that the second device 130 may use to indicate which PDUs are received correctly or which are lost or corrupted), the sequence number of the PDU being:
incremented by one for each transmitted frame (see [0074]; receiver has received all sequence numbers from 0 to 4000 except for 3991, 3990, 3985, 3984), and
equal to zero only responsive to an unexpected reset of the remote node ([0038]; a signal from the first device 110 may indicate to the receiver to perform certain actions, such as... reset the sequence numbering window; examiner articulates that sequence number of the PDU would be reset to zero, as starting sequence number of the PDU is 0 based on teaching from [0074]); and
sending, by the remote node, a message to the ECU indicating a mismatch, responsive to the sequence number of the PDU mismatching the expected sequence number (see [0033]; first device 110 and the second device 130 maintain a register of sequence numbers associated with the packet stream... the sequence numbers provide an identification that the second device 130 may use to indicate which PDUs are received correctly or which are lost or corrupted. For example, the second device 130 may send a selective acknowledgement (SACK) message to the first device 110, the SACK message identifying the lost or corrupted PDUs; also see [0037]; a SACK message (or NACK message) from the receiver to the sender may be associated with identifying lost PDUs; also see [0046]-[0047] and [0057]).
Although, and as set forth above, Newman discloses receiving, by the remote node, a Protocol Data Unit (PDU) from the ECU (see [0006]), and also discloses a sequence number field in the PDU (see [0033]), Newman does not explicitly disclose differentiating, responsive to a flag in a header of the PDU, between (i) mailbox data and (ii) streaming data that is tolerable of the data loss being included in the PDU. Newman also does not explicitly disclose the sequence number of the PDU being configured to roll over from a particular maximum value to one.
However, in an analogous art, Takamichi discloses receiving, by the remote node, a Protocol Data Unit (PDU) from the ECU (see [0029]; the present invention is a communication device for an IP network, provided in the IP network using a wireless link as an access means, which receives a radio signal from a user side radio terminal) and differentiating, responsive to a flag in a header of the PDU (see [0011]; In the header area of an IP datagram, in the case of IPv4 (Internet Protocol Version 4), a protocol area indicating the encapsulated protocol type of the transport layer or the like is defined. Based on the value of the protocol area, it is possible to identify, for each IP datagram, what kind of protocol data, like a UDP datagram or a TCP segment, is encapsulated on the payload area; also see [0029]-[0030]; The device comprises: a packet type identifying circuit for identifying a user traffic sequence of the IP datagram received, and outputting a traffic type showing the protocol type of the transport layer; In the packet type identifying circuit, a user traffic sequence is identified from the header area of the IP datagram received, and the user traffic sequence number k thereof is outputted, and also the traffic type T(k) showing whether it is UDP traffic or TCP traffic is outputted; examiner articulates that TCP traffic corresponds to mailbox data being included in the PDU that is both required to be received in order and to be intolerable of a data loss; examiner also articulates that UDP traffic corresponds to streaming data being included in the PDU that is tolerable of a data loss), between (i)mailbox data that is both required to be received in order and to be intolerable of a data loss being included in the PDU (see [0010]; TCP is a protocol having a retransmission controlling function in the transport layer between transmitting and receiving terminals, having such a characteristic that packet loss is reduced due to a retransmission control. However, real time properties are degraded, so it is suitable for data communications in which request for real time properties is not high such as file downloading (“mailbox data”); also see [0026]; TCP timeout may be cased due to loss of IP datagrams in a wireless link section... In the case of timeout, a user has to transmit the TCP traffic again; also see [0110] in view of Fig.7: The sequence number of TCP in FIG. 7 … is transferred end-to-end between the communication device 40 and the communication device 31 for an order control in the transport layer) and (ii) streaming data that is tolerable of the data loss being included in the PDU (see [0007]; UDP is a protocol in which retransmission control is not performed in the transport layer between transmitting and receiving terminals. Therefore, although packets may be lost, UDP is excellent in real time properties, so it is suitable for traffic requiring real time properties such as voice communications (VOIP: voice over IP), TV phones and visual communications (“streaming data”); also see [0021]; Particularly, as for UDP, retransmission control is not performed in the transport layer, and there is no retransmission means even when packets are lost).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Takamichi with Newman to differentiate, responsive to a flag in a header of the PDU, between (i) mailbox data and (ii) streaming data that is tolerable of the data loss being included in the PDU.
One of ordinary skill in the art would have been motivated to suppress the useless traffic amount transferred to the IP network, so as to prevent effective availability of the network bandwidth from being reduced (Takamichi: [0034]).
Newman (modified by Takamichi) also does not explicitly disclose the sequence number of the PDU being configured to roll over from a particular maximum value to one.
However, in an analogous art, Kondrat teaches comparing (see Fig.7:708), by the remote node, a sequence number of the PDU found in a sequence number field of the PDU (see Fig.5:500) to an expected sequence number of the PDU (see Col.12: lines 16-18: the sequence number 500 is extracted from the frame in step 704 and is compared to the next expected sequence number), the sequence number of the PDU being:
incremented by one for each transmitted frame (see Col.12: lines 8-22; the sequence number will be incremented to calculate the next expected sequence number),
configured to roll over from a particular maximum value to one (see Col.10: lines 37-43; A frame sequence number 500 is scoped to a conversation between a pair of source and destination endpoints. The width (in bits) of the frame sequence number 500 controls the maximum number of unique frame sequence numbers before the sequence number is wrapped-around; for example, a sequence number field 500 of 8-bits allows for 255 sequence numbers in the sequence number space; also see Col.12: lines 8-22; The increment operation will roll the sequence number back to 1 if the maximum sequence number value is exceeded).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Kondrat with Newman and Takamichi so that the sequence number of the PDU is configured to roll over from a particular maximum value to one.
One of ordinary skill in the art would have been motivated to aid in the restoration of service after a failure by detecting gaps in the sequence numbers (Kondrat: see Col.12: lines 30-45).
Regarding claim 2, Newman (modified by Takamichi and Kondrat) discloses the computer-implemented method of claim 1, as set forth above. Newman further discloses informing, by the remote node, the ECU of the expected sequence number by specifying the expected sequence number in the message (see [0046]-[0047]; one of the PDUs, PDU 426, is missing, lost, or corrupted. The receiving device may send back a SACK message to the transmitter identifying the missing sequence number associated with missing PDU 426 and indicating that the missing PDU 426 was not properly received).
Regarding claim 4, Newman (modified by Takamichi and Kondrat) discloses the computer-implemented method of claim 1, as set forth above. Takamichi further discloses wherein the mailbox data is processed to be lossless from transmission to reception (see [0010]; TCP is a protocol having a retransmission controlling function in the transport layer between transmitting and receiving terminals, having such a characteristic that packet loss is reduced due to a retransmission control. However, real time properties are degraded, so it is suitable for data communications in which request for real time properties is not high such as file downloading (“mailbox data”); also see [0026]; TCP timeout may be cased due to loss of IP datagrams in a wireless link section... In the case of timeout, a user has to transmit the TCP traffic again; also see [0110] in view of Fig.7: The sequence number of TCP in FIG. 7 … is transferred end-to-end between the communication device 40 and the communication device 31 for an order control in the transport layer), while the streaming data is processed to permit the data loss from transmission to reception (see [0007]; UDP is a protocol in which retransmission control is not performed in the transport layer between transmitting and receiving terminals. Therefore, although packets may be lost, UDP is excellent in real time properties, so it is suitable for traffic requiring real time properties such as voice communications (VOIP: voice over IP), TV phones and visual communications (“streaming data”); also see [0021]; Particularly, as for UDP, retransmission control is not performed in the transport layer, and there is no retransmission means even when packets are lost).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Takamichi with Newman and Kondrat so that the mailbox data is processed to be lossless from transmission to reception, while the streaming data is processed to permit the data loss from transmission to reception.
One of ordinary skill in the art would have been motivated to suppress the useless traffic amount transferred to the IP network, so as to prevent effective availability of the network bandwidth from being reduced (Takamichi: [0034]).
Regarding claim 6, Newman (modified by Takamichi and Kondrat) discloses the computer-implemented method of claim 1, as set forth above, including the flag in the header of the PDU indicating that the mailbox data is included in the PDU (in Takamichi, see [0011]; In the header area of an IP datagram, in the case of IPv4 (Internet Protocol Version 4), a protocol area indicating the encapsulated protocol type of the transport layer or the like is defined. Based on the value of the protocol area, it is possible to identify, for each IP datagram, what kind of protocol data, like a UDP datagram or a TCP segment, is encapsulated on the payload area; also see [0029]-[0030]; The device comprises: a packet type identifying circuit for identifying a user traffic sequence of the IP datagram received, and outputting a traffic type showing the protocol type of the transport layer; In the packet type identifying circuit, a user traffic sequence is identified from the header area of the IP datagram received, and the user traffic sequence number k thereof is outputted, and also the traffic type T(k) showing whether it is UDP traffic or TCP traffic is outputted; examiner articulates that TCP traffic corresponds to mailbox data being included in the PDU that is both required to be received in order and to be intolerable of a data loss; examiner also articulates that UDP traffic corresponds to streaming data being included in the PDU that is tolerable of a data loss).
Newman further discloses sending, by the remote node, a message to the ECU including a next expected sequence number (see [0057]; The second device includes a sequence acknowledgement unit configured to maintain a register of sequence numbering for received PDUs and to send a selective acknowledgement message indicating sequence numbers for PDUs that are not properly received by the second device), responsive to: the flag in the header of the PDU indicating that the mailbox data is included in the PDU (see [0055]; the PDUs represent IEEE802.2 (LLC) type 2 frames; LLC Type 2 is a connection-oriented operational mode. Sequence numbering ensures that the frames received are guaranteed to be in the order they have been sent; Logical Link Control (LLC) protocol type 2 header may be added).
In addition, Kondrat further discloses the sequence number of the PDU matching the expected sequence number of the PDU (see Col.12: lines 15-19; sequence number 500 is greater than or equal to the next expected sequence number).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Kondrat with Newman and Takamichi to send, by the remote node, a message to the ECU including a next expected sequence number, responsive to: the flag in the header of the PDU indicating that the mailbox data is included in the PDU.
One of ordinary skill in the art would have been motivated to aid in the restoration of service after a failure by detecting gaps in the sequence numbers (Kondrat: see Col.12: lines 30-45).
Regarding claim 7, Newman (modified by Takamichi and Kondrat) discloses the computer-implemented method of claim 1, as set forth above, including the flag in the header of the PDU indicating that the mailbox data is included in the PDU (in Takamichi, see [0011]; In the header area of an IP datagram, in the case of IPv4 (Internet Protocol Version 4), a protocol area indicating the encapsulated protocol type of the transport layer or the like is defined. Based on the value of the protocol area, it is possible to identify, for each IP datagram, what kind of protocol data, like a UDP datagram or a TCP segment, is encapsulated on the payload area; also see [0029]-[0030]; The device comprises: a packet type identifying circuit for identifying a user traffic sequence of the IP datagram received, and outputting a traffic type showing the protocol type of the transport layer; In the packet type identifying circuit, a user traffic sequence is identified from the header area of the IP datagram received, and the user traffic sequence number k thereof is outputted, and also the traffic type T(k) showing whether it is UDP traffic or TCP traffic is outputted; examiner articulates that TCP traffic corresponds to mailbox data being included in the PDU that is both required to be received in order and to be intolerable of a data loss; examiner also articulates that UDP traffic corresponds to streaming data being included in the PDU that is tolerable of a data loss).
Kondrat further discloses discarding, by the remote node, the PDU (see Fig.7:711), responsive to: the flag in the header of the PDU indicating that the mailbox data is included in the PDU (see Col.6: lines 56-60; The different types of frames or streams can be distinguished by MAC addresses, IP addresses, TCP ports or any other piece of information contained within the frame or underlying MAC protocol); and the sequence number of the PDU mismatching the expected sequence number of the PDU (see Col.12: lines 23-24; If the sequence number 500 is less than the next expected sequence number then the frame will be discarded).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Kondrat with Newman and Takamichi to discard, by the remote node, the PDU, responsive to: the flag in the header of the PDU indicating that the mailbox data is included in the PDU; and the sequence number of the PDU mismatching the expected sequence number of the PDU.
One of ordinary skill in the art would have been motivated to aid in the restoration of service after a failure by detecting gaps in the sequence numbers (Kondrat: see Col.12: lines 30-45).
Regarding claim 8, Newman (modified by Takamichi and Kondrat) discloses the computer-implemented method of claim 1, as set forth above. Takamichi further discloses processing, by the remote node, the PDU (see [0030]; In the loss rate calculation circuit, based on the user traffic sequence number k outputted from the packet identifying circuit and the sequence number SQN(k) transferred from a user terminal by using the radio header of a wireless link section, the IP datagram loss rate L(k) in the wireless link section is calculated for each user traffic sequence at a constant cycle Tmax), responsive to: the flag in the header of the PDU indicating that the streaming data is included in the PDU (see [0011]; In the header area of an IP datagram, in the case of IPv4 (Internet Protocol Version 4), a protocol area indicating the encapsulated protocol type of the transport layer or the like is defined. Based on the value of the protocol area, it is possible to identify, for each IP datagram, what kind of protocol data, like a UDP datagram or a TCP segment, is encapsulated on the payload area; also see [0029]-[0030]; The device comprises: a packet type identifying circuit for identifying a user traffic sequence of the IP datagram received, and outputting a traffic type showing the protocol type of the transport layer; In the packet type identifying circuit, a user traffic sequence is identified from the header area of the IP datagram received, and the user traffic sequence number k thereof is outputted, and also the traffic type T(k) showing whether it is UDP traffic or TCP traffic is outputted; examiner articulates that UDP traffic corresponds to streaming data included in the PDU).
In addition, Kondrat further discloses processing, by the remote node, the PDU, responsive to: the sequence number of the PDU matching the expected sequence number of the PDU (see Col.12: lines 15-19; if sequence number 500 is greater than or equal to the next expected sequence number then the frame is accepted in step and the sequence number will be incremented to calculate the next expected sequence number in step 707 and stored in the array).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Kondrat with Newman and Takamichi to process, by the remote node, the PDU, responsive to: the sequence number of the PDU matching the expected sequence number of the PDU.
One of ordinary skill in the art would have been motivated to aid in the restoration of service after a failure by detecting gaps in the sequence numbers (Kondrat: see Col.12: lines 30-45).
Regarding claim 9, Newman (modified by Takamichi and Kondrat) discloses the computer-implemented method of claim 1, as set forth above. Takamichi further discloses processing, by the remote node, the PDU (see [0030]; In the loss rate calculation circuit, based on the user traffic sequence number k outputted from the packet identifying circuit and the sequence number SQN(k) transferred from a user terminal by using the radio header of a wireless link section, the IP datagram loss rate L(k) in the wireless link section is calculated for each user traffic sequence at a constant cycle Tmax), responsive to: the flag in the header of the PDU indicating that the streaming data is included in the PDU (see [0011]; In the header area of an IP datagram, in the case of IPv4 (Internet Protocol Version 4), a protocol area indicating the encapsulated protocol type of the transport layer or the like is defined. Based on the value of the protocol area, it is possible to identify, for each IP datagram, what kind of protocol data, like a UDP datagram or a TCP segment, is encapsulated on the payload area; also see [0029]-[0030]; The device comprises: a packet type identifying circuit for identifying a user traffic sequence of the IP datagram received, and outputting a traffic type showing the protocol type of the transport layer; In the packet type identifying circuit, a user traffic sequence is identified from the header area of the IP datagram received, and the user traffic sequence number k thereof is outputted, and also the traffic type T(k) showing whether it is UDP traffic or TCP traffic is outputted; examiner articulates that UDP traffic corresponds to streaming data included in the PDU).
In addition, Kondrat further discloses processing, by the remote node, the PDU, responsive to: the sequence number of the PDU being newer than the expected sequence number of the PDU (see Col.12: lines 15-19; if sequence number 500 is greater than or equal to the next expected sequence number then the frame is accepted in step and the sequence number will be incremented to calculate the next expected sequence number in step 707 and stored in the array).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Kondrat with Newman and Takamichi to process, by the remote node, the PDU, responsive to: the sequence number of the PDU being newer than the expected sequence number of the PDU.
One of ordinary skill in the art would have been motivated to aid in the restoration of service after a failure by detecting gaps in the sequence numbers (Kondrat: see Col.12: lines 30-45).
Regarding claim 10, Newman (modified by Takamichi and Kondrat) discloses the computer-implemented method of claim 1, as set forth above, including the flag in the header of the PDU indicating that the streaming data is included in the PDU (in Takamichi, see [0011]; In the header area of an IP datagram, in the case of IPv4 (Internet Protocol Version 4), a protocol area indicating the encapsulated protocol type of the transport layer or the like is defined. Based on the value of the protocol area, it is possible to identify, for each IP datagram, what kind of protocol data, like a UDP datagram or a TCP segment, is encapsulated on the payload area; also see [0029]-[0030]; The device comprises: a packet type identifying circuit for identifying a user traffic sequence of the IP datagram received, and outputting a traffic type showing the protocol type of the transport layer; In the packet type identifying circuit, a user traffic sequence is identified from the header area of the IP datagram received, and the user traffic sequence number k thereof is outputted, and also the traffic type T(k) showing whether it is UDP traffic or TCP traffic is outputted; examiner articulates that UDP traffic corresponds to streaming data included in the PDU).
Newman (modified by Takamichi) does not explicitly disclose discarding, by the remote node, the PDU, responsive to: the flag in the header of the PDU indicating that the streaming data is included in the PDU; and the sequence number of the PDU being older than the expected sequence number of the PDU.
Kondrat discloses discarding, by the remote node, the PDU (see Fig.7:711), responsive to: the flag in the header of the PDU indicating that the streaming data is included in the PDU (see Col.6: lines 56-60; The different types of frames or streams can be distinguished by MAC addresses, IP addresses, TCP ports or any other piece of information contained within the frame or underlying MAC protocol); and the sequence number of the PDU being older than the expected sequence number of the PDU (see Col.12: lines 23-24; If the sequence number 500 is less than the next expected sequence number then the frame will be discarded).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Kondrat with Newman and Takamichi to discard, by the remote node, the PDU, responsive to: the flag in the header of the PDU indicating that the streaming data is included in the PDU; and the sequence number of the PDU being older than the expected sequence number of the PDU.
One of ordinary skill in the art would have been motivated to aid in the restoration of service after a failure by detecting gaps in the sequence numbers (Kondrat: see Col.12: lines 30-45).
Regarding claim 12, Newman (modified by Takamichi and Kondrat) discloses the computer-implemented method of claim 1, as set forth above. Newman further discloses performing, by at least one of the remote node or the ECU, a recovery action for the PDU responsive to: the flag in the header of the PDU indicating that the mailbox data is included in the PDU (see [0055]; the PDUs represent IEEE802.2 (LLC) type 2 frames; LLC Type 2 is a connection-oriented operational mode. Sequence numbering ensures that the frames received are guaranteed to be in the order they have been sent; Logical Link Control (LLC) protocol type 2 header may be added); and a detection of the unexpected reset of the remote node based on the sequence number of the PDU being equal to zero (see [0089]; the second device determines that it has received a control instruction, then at 1080, the second device may reset sequence numbering in accordance with control instruction. For example, the control instruction may indicate that sequence numbers earlier than a particular sequence number will no longer be retransmitted; also see [0038]; first device 110 may indicate to the receiver to perform certain actions, such as reset the sequence numbering window… The receiver may then selectively proceed with delivering buffered frames before the particular sequence number, and any other frames which sequentially follow. This may prevent the first device 110 from having to retransmit several earlier lost or corrupted PDUs, which may have already expired in terms of the application delay tolerance criteria).
Regarding claim 15, Newman (modified by Takamichi and Kondrat) discloses the computer-implemented method of claim 1, as set forth above. Kondrat further discloses wherein the particular maximum value of the sequence number is 255 (see Col.10: lines 37-43; A frame sequence number 500 is scoped to a conversation between a pair of source and destination endpoints. The width (in bits) of the frame sequence number 500 controls the maximum number of unique frame sequence numbers before the sequence number is wrapped-around; for example, a sequence number field 500 of 8-bits allows for 255 sequence numbers in the sequence number space; also see Col.12: lines 8-22; The increment operation will roll the sequence number back to 1 if the maximum sequence number value is exceeded).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Kondrat with Newman and Takamichi so that the particular maximum value of the sequence number is 255.
One of ordinary skill in the art would have been motivated to aid in the restoration of service after a failure by detecting gaps in the sequence numbers (Kondrat: see Col.12: lines 30-45).
As for Claim(s) 17 and 23, the claims list all the same elements of claim 1, but in a computer program product configured to manage data between an Electronic Control Unit (ECU) and a remote node of a system, the computer program product comprising one or more non-transitory computer-readable media, having instructions (see Newman [0093]) and a remote node (see Fig.11: 1100) for communicating with an Electronic Control Unit (ECU) in a system, the remote node comprising: memories (see Fig.11: 1106), and processors (see Fig.11: 1102) form to carry out the steps of claim 1, rather than the method form. Therefore, the supporting rationale of the rejection to claim 1 applies equally as well to claims 17 and 23.
Regarding claims 18 and 20, the claims depend on claim 17, but do not teach or further define over the limitations in claims 2 and 4 respectively. Therefore, claims 18 and 20 are rejected for the same reasons as set forth in claims 2 and 4 respectively.
Regarding claim 25, the Newman discloses a computer-implemented method for managing data between an Electronic Control Unit (ECU) and a remote node of a system, the method comprising:
sending, by the ECU, a Protocol Data Unit (PDU) to the remote node (see [0006]; a series of protocol data units (PDUs) are transmitted from a first device via at least a first path of a network to a second device), the mailbox data that is both required to be received in order and to be intolerable of a data loss being included in the PDU being included in the PDU unit (see [0028]; the destination device must make sure the PDUs are delivered to upper layers in a proper order; lost PDUs may be omitted as long as the number of lost PDUs does not exceed the loss tolerance; also see [0055]; Sequence numbering ensures that the frames received are guaranteed to be in the order they have been sent, and no frames are lost); and
receiving, by the ECU, a message from the remote node indicating a mismatch, responsive to a sequence number of the PDU mismatching an expected sequence number of the PDU (see [0033]; first device 110 and the second device 130 maintain a register of sequence numbers associated with the packet stream... the sequence numbers provide an identification that the second device 130 may use to indicate which PDUs are received correctly or which are lost or corrupted. For example, the second device 130 may send a selective acknowledgement (SACK) message to the first device 110, the SACK message identifying the lost or corrupted PDUs; also see [0037]; a SACK message (or NACK message) from the receiver to the sender may be associated with identifying lost PDUs; also see [0046]-[0047] and [0057]), the sequence number of the PDU being: incremented by one for each transmitted frame (see [0074]; receiver has received all sequence numbers from 0 to 4000 except for 3991, 3990, 3985, 3984), and equal to zero only responsive to an unexpected reset of the remote node ([0038]; a signal from the first device 110 may indicate to the receiver to perform certain actions, such as... reset the sequence numbering window; examiner articulates that sequence number of the PDU would be reset to zero, as starting sequence number of the PDU is 0 based on teaching from [0074]).
Although, and as set forth above, Newman discloses sending, by the ECU, a Protocol Data Unit (PDU) to the remote node (see [0006]), and also discloses a sequence number field in the PDU (see [0033]), Newman does not explicitly disclose a flag configured to differentiate between (i) mailbox data and (ii) streaming data that is tolerable of the data loss being included in the PDU. Newman also does not explicitly disclose the sequence number of the PDU being configured to roll over from a particular maximum value to one.
However, in an analogous art, Takamichi discloses sending, by the ECU, a Protocol Data Unit (PDU) to the remote node (see [0029]; the present invention is a communication device for an IP network, provided in the IP network using a wireless link as an access means, which receives a radio signal from a user side radio terminal) and a flag configured to differentiate (see [0011]; In the header area of an IP datagram, in the case of IPv4 (Internet Protocol Version 4), a protocol area indicating the encapsulated protocol type of the transport layer or the like is defined. Based on the value of the protocol area, it is possible to identify, for each IP datagram, what kind of protocol data, like a UDP datagram or a TCP segment, is encapsulated on the payload area; also see [0029]-[0030]; The device comprises: a packet type identifying circuit for identifying a user traffic sequence of the IP datagram received, and outputting a traffic type showing the protocol type of the transport layer; In the packet type identifying circuit, a user traffic sequence is identified from the header area of the IP datagram received, and the user traffic sequence number k thereof is outputted, and also the traffic type T(k) showing whether it is UDP traffic or TCP traffic is outputted; examiner articulates that TCP traffic corresponds to mailbox data being included in the PDU that is both required to be received in order and to be intolerable of a data loss; examiner also articulates that UDP traffic corresponds to streaming data being included in the PDU that is tolerable of a data loss) between (i) mailbox data that is both required to be received in order and to be intolerable of a data loss being included in the PDU being included in the PDU unit (see [0010]; TCP is a protocol having a retransmission controlling function in the transport layer between transmitting and receiving terminals, having such a characteristic that packet loss is reduced due to a retransmission control. However, real time properties are degraded, so it is suitable for data communications in which request for real time properties is not high such as file downloading (“mailbox data”); also see [0026]; TCP timeout may be cased due to loss of IP datagrams in a wireless link section... In the case of timeout, a user has to transmit the TCP traffic again; also see [0110] in view of Fig.7: The sequence number of TCP in FIG. 7 … is transferred end-to-end between the communication device 40 and the communication device 31 for an order control in the transport layer) and (ii) streaming data that is tolerable of the data loss being included in the PDU (see [0007]; UDP is a protocol in which retransmission control is not performed in the transport layer between transmitting and receiving terminals. Therefore, although packets may be lost, UDP is excellent in real time properties, so it is suitable for traffic requiring real time properties such as voice communications (VOIP: voice over IP), TV phones and visual communications (“streaming data”); also see [0021]; Particularly, as for UDP, retransmission control is not performed in the transport layer, and there is no retransmission means even when packets are lost).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Takamichi with Newman to send a flag configured to differentiate between (i) mailbox data that is both required to be received in order and to be intolerable of a data loss being included in the PDU being included in the PDU unit and (ii) streaming data that is tolerable of the data loss being included in the PDU.
One of ordinary skill in the art would have been motivated to suppress the useless traffic amount transferred to the IP network, so as to prevent effective availability of the network bandwidth from being reduced (Takamichi: [0034]).
Newman (modified by Takamichi) does not explicitly disclose the sequence number of the PDU being configured to roll over from a particular maximum value to one.
However, Kondrat teaches the sequence number of the PDU (see Fig.5:500) mismatching an expected sequence number of the PDU (see Col.12: lines 16-25: the sequence number 500 is extracted from the frame in step 704 and is compared to the next expected sequence number; sequence number 500 is greater/ less than the next expected sequence number), the sequence number of the PDU being: incremented by one for each transmitted frame (see Col.12: lines 8-22; the sequence number will be incremented to calculate the next expected sequence number), and configured to roll over from a particular maximum value to one (see Col.10: lines 37-43; A frame sequence number 500 is scoped to a conversation between a pair of source and destination endpoints. The width (in bits) of the frame sequence number 500 controls the maximum number of unique frame sequence numbers before the sequence number is wrapped-around; for example, a sequence number field 500 of 8-bits allows for 255 sequence numbers in the sequence number space; also see Col.12: lines 8-22; The increment operation will roll the sequence number back to 1 if the maximum sequence number value is exceeded).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Kondrat with Newman and Takamichi so that the sequence number of the PDU is configured to roll over from a particular maximum value to one.
One of ordinary skill in the art would have been motivated to aid in the restoration of service after a failure by detecting gaps in the sequence numbers (Kondrat: see Col.12: lines 30-45).
As for Claim(s) 26, the claims list all the same elements of claim 25, but in an Electronic Control Unit (ECU) (see Fig.11: 1100) for communicating with a remote node in a system, the ECU comprising: memories (see Fig.11: 1106), and processors (see Fig.11: 1102) form to carry out the steps of claim 25, rather than the method form. Therefore, the supporting rationale of the rejection to claim 25 applies equally as well to claim 26.
Regarding claim 27, Newman (modified by Takamichi and Kondrat) discloses the computer-implemented method of claim 1, as set forth above. Takamichi further discloses wherein mailbox data is both required to be received in order by the remote node and to be intolerable of a data loss (see [0010]; TCP is a protocol having a retransmission controlling function in the transport layer between transmitting and receiving terminals, having such a characteristic that packet loss is reduced due to a retransmission control. However, real time properties are degraded, so it is suitable for data communications in which request for real time properties is not high such as file downloading (“mailbox data”); also see [0026]; TCP timeout may be cased due to loss of IP datagrams in a wireless link section... In the case of timeout, a user has to transmit the TCP traffic again; also see [0110] in view of Fig.7: The sequence number of TCP in FIG. 7 … is transferred end-to-end between the communication device 40 and the communication device 31 for an order control in the transport layer).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Takamichi with Newman and Kondrat so that mailbox data is both required to be received in order by the remote node and to be intolerable of a data loss.
One of ordinary skill in the art would have been motivated to suppress the useless traffic amount transferred to the IP network, so as to prevent effective availability of the network bandwidth from being reduced (Takamichi: [0034]).
Claim(s) 3 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Newman et al. (hereinafter, Newman, US 20140254351 A1) in view of Takamichi (US 20060198376 A1) in view of Kondrat et al. (hereinafter, Kondrat, US 7706255 B1) in view of RYU et al. (hereinafter, RYU, WO 2014005077 A1).
Regarding claim 3, Newman (modified by Takamichi and Kondrat) discloses the computer-implemented method of claim 1, as set forth above. Newman (modified by Takamichi and Kondrat) does not explicitly disclose processing, by the remote node, the mailbox data differently from the streaming data responsive to reviewing the flag in the header of the PDU to determine whether the PDU includes the mailbox data or the streaming data.
However, in an analogous art, RYU discloses processing, by the remote node, the mailbox data differently from the streaming data responsive to reviewing the flag in the header of the PDU to determine whether the PDU includes the mailbox data or the streaming data (see [0146] and [0152] in view of Table 12 on page 41; the reliability flag 1534 may include a bit that may be set to indicate that the data (e.g., media data) in the packet 1500 is loss tolerant. For example, the packets may be dropped without severe quality degradation. The reliability flag 1534 may indicate that the data (e.g., signaling data, service data, programing data, etc.) in the packet 1500 is not loss tolerant).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of RYU with Newman, Takamichi and Kondrat to process, by the remote node, the mailbox data differently from the streaming data responsive to reviewing the flag in the header of the PDU to determine whether the PDU includes the mailbox data or the streaming data.
One of ordinary skill in the art would have been motivated for greater reliability and/or lower packet loss rates (RYU: [0073]).
Regarding claim 19, the claim depends on claim 17, but does not teach or further define over the limitations in claim 3. Therefore, claim 19 is rejected for the same reasons as set forth in claim 3.
Claim(s) 5 and 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Newman et al. (hereinafter, Newman, US 20140254351 A1) in view of Takamichi (US 20060198376 A1) in view of Kondrat et al. (hereinafter, Kondrat, US 7706255 B1) in view of Sabaa et al. (hereinafter, Sabaa, US 6389016 B1).
Regarding claim 5, Newman (modified by Takamichi and Kondrat) discloses the computer-implemented method of claim 1, as set forth above, including wherein in a mailbox mode automatically applied to the mailbox data by the remote node responsive to the flag in the header of the PDU (in Newman, see [0146] and [0152] in view of Table 12 on page 41; the reliability flag 1534 may include a bit that may be set to indicate that the data (e.g., media data) in the packet 1500 is loss tolerant. For example, the packets may be dropped without severe quality degradation. The reliability flag 1534 may indicate that the data (e.g., signaling data, service data, programing data, etc.) in the packet 1500 is not loss tolerant).
Newman (modified by Takamichi and Kondrat) does not explicitly disclose PDUs are only accepted by the remote node in an intended order such that subsequent PDUs are discarded until an expected PDU is received and acknowledged.
However, Sabaa discloses PDUs are only accepted by the remote node in an intended order such that subsequent PDUs are discarded until an expected PDU is received and acknowledged (see Col.9: line 50 – Col.10: line 2; data packet 100 having sequence number 8 of Group 0 is lost in this scenario. Once the next packet 102 arrives, having a sequence number of 9, the receiver 72 detects an out-of-sequence error as the sequence number of the received packet 102 does not match the expected sequence number of 8; the receiver 72 discards all further packets received for group 0 until the one expected is received. Once the sender 70 receives the negative acknowledgment 104, it knows at that point that all sequence numbers up to 7 have been correctly received. The receiver then retransmits the packet 100 with sequence number 8, immediately followed by all of the next and higher-numbered packets in the group. Once these are received, the receiver 72 indicates the correct reception of the entire group by sending a positive acknowledgment 84).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Sabaa with Newman, Takamichi and Kondrat so that PDUs are only accepted by the remote node in an intended order such that subsequent PDUs are discarded until an expected PDU is received and acknowledged.
One of ordinary skill in the art would have been motivated to save considerable bandwidth (Sabaa: Col.10: line 10).
As for Claim 21, the claim depends on claim 17, but does not teach or further define over the limitations in claim 5. Therefore, claim 21 is rejected for the same reasons as set forth in claim 5.
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Newman et al. (hereinafter, Newman, US 20140254351 A1) in view of Takamichi (US 20060198376 A1) in view of Kondrat et al. (hereinafter, Kondrat, US 7706255 B1) in view of Jung (US 20010052072 A1).
Regarding claim 11, Newman (modified by Takamichi and Kondrat) discloses the computer-implemented method of claim 1, as set forth above, including unexpected reset of the remote node based on the sequence number being equal to zero (in Newman, see [0038]; a signal from the first device 110 may indicate to the receiver to perform certain actions, such as... reset the sequence numbering window; examiner articulates that sequence number of the PDU would be reset to zero, as starting sequence number of the PDU is 0 based on teaching from [0074]).
Newman (modified by Takamichi and Kondrat) does not explicitly disclose at least one visually and audibly indicating, by at least one of the remote node or the ECU, the unexpected reset of the remote node.
Jung discloses at least one visually and audibly indicating, by at least one of the remote node or the ECU, the unexpected reset of the remote node (see [0043]; Once a data recovery procedure is initiated, the sequence number processor 29 resets the sequence number back to its initial value. The sequence number processor 29 may then cause a sequence number reset message to be transmitted (via in-band or out-band signaling) indicating that the sequence number will restart (“visually indicating unexpected reset”); also see [0018]; also see claim 6).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Jung with Newman, Takamichi and Kondrat to at least one visually and audibly indicate, by at least one of the remote node or the ECU, the unexpected reset of the remote node based on the sequence number being equal to zero.
One of ordinary skill in the art would have been motivated to allow the transmitting and receiving sides to become resynchronized once again (Jung: see [0043]).
Claim(s) 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Newman et al. (hereinafter, Newman, US 20140254351 A1) in view of Takamichi (US 20060198376 A1) in view of Kondrat et al. (hereinafter, Kondrat, US 7706255 B1) in view of LE et al. (hereinafter, LE, US 20160308765 A1).
Regarding claim 13, Newman (modified by Takamichi and Kondrat) discloses the computer-implemented method of claim 1, as set forth above. Newman (modified by Takamichi and Kondrat) does not explicitly disclose sending, by the ECU, a new PDU to the remote node; resending, by the ECU, the new PDU after a timeout, responsive to the PDU including the mailbox data; and an absence of the ECU from receiving an acknowledgement of a receipt of the new PDU.
LE discloses method further comprising:
sending, by the ECU, a new PDU to the remote node (see [0078] and [0082]; forwarder node 802 sends a transmitted message M1 812, which is a copy of the received message M1 810, to the destination node 804, but the transmission fails);
resending, by the ECU, the new PDU after a timeout, responsive to the PDU including the mailbox data (see [0025] and [0037]; packet type identifier 204 in one example identifies if the received data packet is a data packet upon which special retransmission processing is to be performed); and an absence of the ECU from receiving an acknowledgement of a receipt of the new PDU (see[0082]; controller 808 monitors information sent from all forwarder nodes to determine if a receipt acknowledgement has been sent by the destination node 804. If no receipt acknowledgment has been sent by the destination node 804 over any transmission path, the controller determines that an ACK timeout occurs. Upon determining that an ACK timeout occurs, the controller proceeds to recreate the message M1 and retransmits it as retransmitted message M1 816 to the destination node 804).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of LE with Newman, Takamichi and Kondrat to send, by the ECU, a new PDU to the remote node; and to resend, by the ECU, the new PDU after a timeout, responsive to the PDU including the mailbox data; and an absence of the ECU from receiving an acknowledgement of a receipt of the new PDU.
One of ordinary skill in the art would have been motivated to allow quicker loss recovery and thus better performance (LE: see [0021]).
Claim(s) 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Newman et al. (hereinafter, Newman, US 20140254351 A1) in view of Takamichi (US 20060198376 A1) in view of Kondrat et al. (hereinafter, Kondrat, US 7706255 B1) in view of Hooper et al. (hereinafter, Hooper, US 20040202164 A1).
Regarding claim 14, Newman (modified by Takamichi and Kondrat) discloses the computer-implemented method of claim 1, as set forth above. Newman (modified by Takamichi and Kondrat) does not explicitly disclose wherein the PDU is sent in a multicast message to a plurality of remote nodes.
Hooper discloses wherein the PDU is sent in a multicast message to a plurality of remote nodes (see [0013]; downstream device generates PDUs carrying the multicast data and transmits the generated PDUs via the appropriate egress interfaces (e.g., links to remote network devices).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Hooper with Newman, Takamichi and Kondrat so that the PDU is sent in a multicast message to a plurality of remote nodes.
One of ordinary skill in the art would have been motivated to reduce traffic between devices, and to conserve resources of device by offloading duties from device (Hooper: see [0013]).
Claim(s) 16, 22 and 24 is/are rejected under 35 U.S.C. 103 as being unpatentable over Newman et al. (hereinafter, Newman, US 20140254351 A1) in view of Takamichi (US 20060198376 A1) in view of Kondrat et al. (hereinafter, Kondrat, US 7706255 B1) in view of Non-Patent Literature to McLean (“Automotive, In-Cabin Experience: Personalized Digitized, Immersive, Dec. 8, 2021”).
Regarding claim 16, Newman (modified by Takamichi and Kondrat) discloses the computer-implemented method of claim 1, as set forth above. Newman (modified by Takamichi and Kondrat) does not explicitly disclose wherein the remote node is configured to communicate with the ECU using an Ethernet to the Edge Bus (E2B) protocol.
McLean discloses wherein the remote node is configured to communicate with the ECU using an Ethernet to the Edge Bus (E2B) protocol (see “The Future Car: Connecting Your World” section on the last page; Ethernet-to-the-Edge Bus (E2B) uses the new automotive Ethernet 10BASE-T1S technology to enable Ethernet-to-edge connectivity for sensors and actuators).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of McLean with Newman, Takamichi and Kondrat so the remote node is configured to communicate with the ECU using an Ethernet to the Edge Bus (E2B) protocol.
One of ordinary skill in the art would have been motivated to reduce the number of ECU’s, and to support updates rolling out new and enhanced features (McLean: see “The Future Car: Connecting Your World” section on the last page).
Regarding claims 22 and 24, the claims depend on claims 17 and 23 respectively, but does not teach or further define over the limitations in claim 16. Therefore, claims 22 and 24 are rejected for the same reasons as set forth in claims 16.
Additional References
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
JIMMEI et al. (EP 0781010 A2) discloses the IP header also includes protocol information for identifying protocol used at the transport layer (the TCP/UDP).
White et al. (US 20200053018 A1) determines if the Protocol number or Next Header type of the outermost header is one of well-known flow identifiers.
GAO et al. (EP 1742476 A1) teaches that UDP is a protocol adapted to send independent packets of data, called datagrams, from one computer to another with no guarantees about arrival, and that TCP is specifically designed to provide a reliable end-to-end byte stream over an unreliable internetwork and to reassemble the datagrams into messages in the proper sequence.
PARRELLA et al. (WO 02099677 A1) teaches that TCP guarantees to deliver the stream of bytes in the order they were sent without duplication or data loss even if the IP package delivery service is unreliable while UDP does not guarantee packet delivery.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SANDARVA KHANAL whose telephone number is (571)272-8107. The examiner can normally be reached MON-FRI, 0800-1700.
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, Kamal B Divecha can be reached at 571-272-5863. 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.
/SANDARVA KHANAL/Primary Examiner, Art Unit 2453