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 07/21/2026 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/ remarks filed on 07/21/2026.
Independent claims 1, 17, 23, and 25-26 have been amended. Claim 27 is cancelled.
Claims 1-26 are presented for examination, and remain pending in this application.
Response to Arguments Regarding Claim Rejections - 35 USC § 103
The Applicant's amendment/ arguments, see page 8-10 of REMARKS, filed 07/21/2026, with respect to Claim Rejections - 35 USC § 103 have been fully considered but they are not persuasive. In the response filed on 07/21/2026, applicant puts forth in substance that:
“To the extent that the rejections are applicable to the claims as amended, Applicant respectfully traverses as follows.
Independent claim 1 has been amended to recite the feature of "wherein the mailbox data and the streaming data are encapsulated in the PDU associated with only a single communication protocol." In rejecting independent 1, the Office properly acknowledged that "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." Office Action at p. 14. Instead, the Office alleged that Takamichi discloses this feature and one skilled in the art would be motivated to modify Newman with Takamichi. Applicant respectfully disagrees.
As an initial matter, Takamichi discloses using TCP and UDP protocols for transporting data. In the passage cited by the Office in the Office Action, Takamichi states "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." Id., citing Takamichi at [0029]-[0030]. Here, Takamichi discloses identifying different payloads in different protocol data units associated with different communication protocols. Therefore, Newman and Takamichi fails to disclose or suggest at least this feature.” (See page 9 of REMARKS, filed 07/21/2026).
In response to the applicant’s arguments, examiner notes that the new limitation introduced by the amended claim recites “wherein the mailbox data and the streaming data are encapsulated in the PDU associated with only a single communication protocol”, without clarifying further details regarding the “single communication protocol”. Takamichi discloses layered processing in communication device (see Fig.1:10), including application layer, transport layer, IP processing unit and PDU generation unit. Takamichi further clarifies (see [0053]) that application data outputted from the upper layer processing unit 11 is inputted to the transport layer processing unit 12, and an application requiring real time properties is first encapsulated to RTP as a delay high-priority class, and then encapsulated to a UDP datagram. On the other hand, an application not requiring real time properties much is encapsulated to a TCP segment. Further, the IP processing unit 13 adds an IP header to the output of the transport layer processing unit 12 by applications and by destinations, and encapsulates it to an IP datagram (see [0053]). The PDU generation circuit shapes an inputted signal into a PDU (Protocol Data Unit) for wireless transmission (see [0053]). Examiner articulates that the Internet Protocol (IP) corresponds to a single communication protocol that the PDU is associated with. Since output of the transport layer (TCP segment and UDP datagram) are encapsulated to an IP datagram by IP processing unit 13 and shaped into PDU for wireless transmission, examiner articulates that this reads on the claimed limitation “wherein the mailbox data and the streaming data are encapsulated in the PDU associated with only a single communication protocol”.
“Further, the Office has failed to establish a prima facie case of obviousness for at least the reasons previously proffered and below. In addition to previously proffered reasons, which are hereby incorporated, Applicant submits that modifying Newman with Takamichi into the claimed invention changes the principle of operation of Newman. Specifically, Newman teaches "In some embodiments of this disclosure, the coordination of sequence numbers, SACK messages, and retransmissions are performed at the MAC layer 516 of the OSI protocol stack. While transport control protocol (TCP) resides at the transport layer (not shown) above the network layers 518, 528, performing the acknowledgement and retransmit operations at the MAC layer may provide lower layer handling of PDU transmissions. In some embodiments, the network layers 518, 528 may be unaware that multiple physical layers or multiple communications medium are being used for selective diverse retransmission of lost or corrupt MPDUs." Newman at [0060].
However, the Office is attempting to modify Newman, which relies on the MAC layer to handle retransmission, with the teachings of the TCP protocol and the UDP protocol at the transport layer (that sits above the network layer), into the claimed invention. Such combination would change the principle of operation of Newman because it would require modifying the retransmission control at the network layer. This modification would fundamentally change how Newman operates, and is not disclosed or suggested by Takamichi. As such, independent claim 1 is patentable over Newman and Takamichi. Kondrat, Ryu, Sabaa, Jung, Le, Hooper, and McLean do not cure the deficiencies above. As such, independent claim 1 is patentable over the applied art.” (See page 9-10 of REMARKS, filed 07/21/2026).
Applicant’s arguments with respect to modifying Newman with Takamichi and more specifically that such combination would change the principle of operation of Newman have been considered but are moot because the new ground of rejection does not rely on modifying Newman with Takamichi for any teaching or matter specifically challenged in the argument. New ground of rejection is presented herein, modifying teachings of Takamichi with those of Newman and Kondrat to arrive at the claimed invention.
Applicant's arguments for independent claims 17, 23, and 25-26 (see page 10 of REMARKS, filed 07/21/2026) appear to stem from the applicant's assertion that the combination of cited references fails to establish a prima facie case of obviousness given the similarly recited limitations of claim 1. However, as set forth above, this assertion does not hold ground, and therefore, the current rejection of record for the independent claim persists.
Applicant's arguments for dependent claims 2-16, 18-22 and 24 (see page 10 of REMARKS, filed 07/21/2026) appear to stem from the applicant's assertion that the combination of cited references fails to establish a prima facie case of obviousness for respective independent claims. However, as set forth above, this assertion does not hold ground, and therefore, the current rejection of record for the dependent claim persists.
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-26 is/are rejected under 35 U.S.C. 103 as being unpatentable over Takamichi (US 20060198376 A1) in view of Newman et al. (hereinafter, Newman, US 20140254351 A1) in view of Kondrat et al. (hereinafter, Kondrat, US 7706255 B1).
Regarding claim 1, Takamichi discloses a computer-implemented method for managing data between an Electronic Control Unit (ECU) and a remote node of a system (see [0029]), the method comprising:
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 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 (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 being included in the PDU, wherein the streaming data is tolerable of the data loss (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);
a sequence number of the PDU found in a sequence number field of the PDU (see [000]; a user traffic sequence is identified from the header area of the IP datagram received; also see Fig.6), the sequence number of the PDU being incremented by one for each transmitted frame (see [0030]; the user traffic sequence number k thereof (k is any positive integer not more than the maximum number of user traffic sequences capable of being processed by the communication device); the sequence number SQN(k) transferred from a user terminal; SQN(k) is a number which is incremented by one for each IP datagram for each user traffic sequence k); and
wherein the mailbox data and the streaming data are encapsulated in the PDU associated with only a single communication protocol (see [0053]; Application data outputted from the upper layer processing unit 11 is inputted to the transport layer processing unit 12, and an application requiring real time properties is first encapsulated to RTP as a delay high-priority class, and then encapsulated to a UDP datagram. On the other hand, an application not requiring real time properties much is encapsulated to a TCP segment… The IP processing unit 13 adds an IP header to the output of the transport layer processing unit 12 by applications and by destinations, and encapsulates it to an IP datagram. The user traffic sequence outputted from the IP processing unit 13 is inputted into the PDU generation circuit 14; also see [0054]; The PDU generation circuit shapes an inputted signal into a PDU (Protocol Data Unit) for wireless transmission; examiner articulates that the Internet Protocol (IP) corresponds to a single communication protocol that the PDU is associated with).
Takamichi does not explicitly disclose comparing, by the remote node, a sequence number of the PDU found in a sequence number field of the PDU to an expected sequence number of the PDU, the sequence number of the PDU being: configured to roll over from a particular maximum value to one, and equal to zero only responsive to an unexpected reset of the remote node; 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.
However, in an analogous art, Newman discloses 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);
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]).
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 Newman with Takamichi to compare, by the remote node, a sequence number of the PDU found in a sequence number field of the PDU to an expected sequence number of the PDU, the sequence number of the PDU being: incremented by one for each transmitted frame, and equal to zero only responsive to an unexpected reset of the remote node; 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.
One of ordinary skill in the art would have been motivated to allow for path splitting, packet sequencing, selective acknowledge of MPDUs, and retransmission (Newman [0024]) and/or for enhanced acknowledgement and selective retransmission of lost or corrupted protocol data units (Newman, [0005]).
Takamichi (modified by Newman) 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), 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 Takamichi and Newman 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, Takamichi (modified by Newman 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).
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 Newman with Takamichi and Kondrat to inform, by the remote node, the ECU of the expected sequence number by specifying the expected sequence number in the message.
One of ordinary skill in the art would have been motivated to allow for path splitting, packet sequencing, selective acknowledge of MPDUs, and retransmission (Newman [0024]) and/or for enhanced acknowledgement and selective retransmission of lost or corrupted protocol data units (Newman, [0005]).
Regarding claim 4, Takamichi (modified by Newman 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).
Regarding claim 6, Takamichi (modified by Newman 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 Takamichi and Newman 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, Takamichi (modified by Newman 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 Takamichi and Newman 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, Takamichi (modified by Newman 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 Takamichi and Newman 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, Takamichi (modified by Newman 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 Takamichi and Newman 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, Takamichi (modified by Newman 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).
Takamichi (modified by Newman) 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 Takamichi and Newman 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, Takamichi (modified by Newman 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).
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 Newman with Takamichi and Kondrat to perform, 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; and a detection of the unexpected reset of the remote node based on the sequence number of the PDU being equal to zero.
One of ordinary skill in the art would have been motivated to allow for path splitting, packet sequencing, selective acknowledge of MPDUs, and retransmission (Newman [0024]) and/or for enhanced acknowledgement and selective retransmission of lost or corrupted protocol data units (Newman, [0005]).
Regarding claim 15, Takamichi (modified by Newman 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 Takamichi and Newman 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 Takamichi discloses a computer-implemented method for managing data between an Electronic Control Unit (ECU) and a remote node of a system (see [0029]), the method comprising:
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 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 (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 being included in the PDU, wherein the streaming data is tolerable of the data loss (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).
Takamichi does not explicitly disclose 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, the sequence number of the PDU being: incremented by one for each transmitted frame, configured to roll over from a particular maximum value to one, and equal to zero only responsive to an unexpected reset of the remote node.
However, in an analogous art, Newman discloses
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]).
Takamichi (modified by Newman) 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 Takamichi and Newman 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.
Claim(s) 3 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Takamichi (US 20060198376 A1) in view of Newman et al. (hereinafter, Newman, US 20140254351 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, Takamichi (modified by Newman and Kondrat) discloses the computer-implemented method of claim 1, as set forth above. Takamichi (modified by Newman 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 Takamichi, Newman 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 Takamichi (US 20060198376 A1) in view of Newman et al. (hereinafter, Newman, US 20140254351 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, Takamichi (modified by Newman 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).
Takamichi (modified by Newman 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 Takamichi, Newman 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 Takamichi (US 20060198376 A1) in view of Newman et al. (hereinafter, Newman, US 20140254351 A1) in view of Kondrat et al. (hereinafter, Kondrat, US 7706255 B1) in view of Jung (US 20010052072 A1).
Regarding claim 11, Takamichi (modified by Newman 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]).
Takamichi (modified by Newman, Kondrat) does not explicitly disclose at least one visually and audibly indicating, by at least one of the remote node or 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 Takamichi, Newman 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 Takamichi (US 20060198376 A1) in view of Newman et al. (hereinafter, Newman, US 20140254351 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, Takamichi (modified by Newman and Kondrat) discloses the computer-implemented method of claim 1, as set forth above. Takamichi (modified by Newman 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 Takamichi, Newman 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 Takamichi (US 20060198376 A1) in view of Newman et al. (hereinafter, Newman, US 20140254351 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, Takamichi (modified by Newman and Kondrat) discloses the computer-implemented method of claim 1, as set forth above. Takamichi (modified by Newman 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 Takamichi, Newman 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 Takamichi (US 20060198376 A1) in view of Newman et al. (hereinafter, Newman, US 20140254351 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, Takamichi (modified by Newman and Kondrat) discloses the computer-implemented method of claim 1, as set forth above. Takamichi (modified by Newman 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 Takamichi, Newman 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 do not teach or further define over the limitations in claim 16. Therefore, claims 22 and 24 are rejected for the same reasons as those set forth in claims 16.
Additional References
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
LEPP et al. (EP 3820093 B1) discloses aggregating messages into a single transmission.
MUNSON et al. (CA 2590965 C) teaches applying the delay-based adaptation to a packet-loss tolerant reliable LTDP.
NANDA (AU 2005294421 A1) discloses a single MAC Protocol Data Unit (MPDU) is encapsulated in a single Physical layer (PHY) Protocol Data Unit (PPDU).
WHITEHEAD (CA 2187828 A) teaches a single applications which mix delay-tolerant and delay-intolerant packets.
Mantha et al. (US 20030126551 A1) teaches a single HARQ protocol can allow both delay-sensitive and delay-insensitive communications.
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
Prosecution Insights