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 .
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 2, 4-8, 10-22 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-20 of U.S. Patent No. 11977508, in view of obviousness. Although the claims at issue are not identical, they are not patentably distinct from each other because the instant application and the patent are both directed to:
Data Frames and Channels: Both applicants describe methods of receiving, processing, and transmitting data frames via data channels.
Header and Payload Data: Both focus on operations involving header and payload data, including read and write operations based on this data.
Checksum Validation: Both include steps for validating checksums to ensure data integrity before proceeding with operations.
Synchronous Operations: Both highlight the importance of synchronously receiving and transmitting frames, often in the same time interval or synchronously with a clock signal
Bus Node Configuration: Both describe a bus node comprising transmitting and receiving devices, control logic, and frame encoders/decoders configured to handle data frames and operations.
The differences between 11977508 are rendered obvious in view of Roethig and Mishra as cited in the 103 rejection below.
Instant Application
17/814370
Patent
11977508
Claim 1
A method comprising:
receiving a first frame via a first data channel,
wherein the first frame comprises at least a first header field having first header data and a first payload field having first payload data;
implementing a read operation at a read address determined by the first header data;
generating a second frame containing at least a second payload field having second payload data based on the data read when implementing the read operation;
transmitting the second frame via a second data channel with a temporal overlap with receiving the first frame via the first data channel;
and implementing a write operation on the basis of the first payload data.
claims 1, 2, 4, 5, 6 and 7
Receiving the first frame (claim 1)
Claim 1 describes receiving a first frame (including first header data and first payload data, plus a first checksum) via a first data channel using a serial data interface
[ie. “An electronic communication method comprising: receiving, via a serial data interface at a first bus node comprising a first interface controller, a first frame via a first data channel using clocked data transfer”, claim 1]
wherein the first frame comprises first header data, first payload data and a first checksum”, claim 1]
Read operation determined by header data (claims 4 and 5) Claim 4 specifies that a portion of the first header data comprises a memory address and that the method accesses this memory address
[ie.” The method of claim 1, wherein the portion of the first header data comprises a memory address of a memory included with the first bus node, and wherein the function accesses the memory address”, claim 4]
Claim 5 details that the function includes reading first data from that memory address, where the data read (the “first data”) determine the content used for the second payload.
[ie. “The method of claim 4, wherein the function accessing the memory address further comprises reading first data from the memory address, and wherein the second payload data are dependent on the first data”, claim 5]
Generating the Second Frame Based on the Read Data (claims 1 and 5)
In claim 1, after receiving a portion of the first frame,
[ie.” a function is executed to generate second header data and second payload data” claim 1].
Claim 5 further clarifies that the second payload data are dependent on the data read from the memory (i.e., the “first data”)
[ie. “The method of claim 4, wherein the function accessing the memory address further comprises reading first data from the memory address, and wherein the second payload data are dependent on the first data”, claim 5]
Transmitting the second frame with temporal overlap (claims 1 and 2)
Claim 1 explicitly requires that the second frame be transmitted via a second data channel (different from the first) simultaneously while receiving the first frame.
[ie.” a second frame comprising the second header data, the second payload data, and a second checksum calculated using the second payload data and the first header data simultaneously while the first frame is received; and transmitting, from the first bus node to the second bus node using the clocked data transfer from the first interface controller to the second interface controller via a second data channel different from the first data channel, the second frame simultaneously while receiving the first frame via the first data channel”, claim 1]
Claim 2 reinforces this by stating that the transmission of the second frame occurs while the first frame is being received
[ie. “The method of claim 1, wherein the second frame is transmitted while the first frame is being received”, claim 2]
Write Operation Based on the First Payload Data (claims 6 and 7)
The “write operation” is reflected in claims 6 and 7
Claim 6 adds that the function accessing the memory address (discussed in Claims 4 and 5) further comprises writing second data to that same memory address, where the second data are associated with the first payload data.
[ie. “The method of claim 5, wherein the function accessing the memory address further comprises writing second data to the memory address, and wherein the second data are associated with the first payload data”, claim 6]
Claim 7 clarifies the order (read before write) and the association between the data read and the second payload data.
[ie. “The method of claim 6, wherein the first data are read before the second data are written, and wherein the first data are associated with the second payload data”, claim 7]
Claim 2
The method as claimed in claim 1, wherein the first frame additionally contains a checksum
and the write operation is implemented only after successful checking of the checksum.
claims 1, 6, 7 and 9
Checksum inclusion (claim 1)
Claim 1 already recites that the first frame comprises first header data, first payload data, and a first checksum.
[ie. “wherein the first frame comprises first header data, first payload data and a first checksum; and responsive to receiving a portion of the first frame, executing, at the first bus node, a function to generate second header data and second payload data based at least on a portion of the first header data; generating, at the first bus node, a second frame comprising the second header data, the second payload data, and a second checksum calculated using the second payload data and the first header data simultaneously while the first frame is received”, claim 1]
Checksum validation (claim 9)
[ie. “The method of claim 1, further comprising: validating, at the first bus node, the first checksum based on the first header data and the first payload data”, claim 9]
The new limitation requires that the write operation be performed only after the first checksum has been successfully checked. Although none of the claims explicitly state that the write step is gated by checksum validation, Claim 9 adds the step of validation.
[ie. “The method of claim 1, further comprising: validating, at the first bus node, the first checksum based on the first header data and the first payload data”, Claim 9]
Write operation features (claims 6 and 7)
The write operation itself is described in Claims 6 and 7 (where second data are written to the memory address only after reading data from that address).
[ie. “The method of claim 5, wherein the function accessing the memory address further comprises writing second data to the memory address, and wherein the second data are associated with the first payload data”, claim 6]
[ie. “The method of claim 6, wherein the first data are read before the second data are written, and wherein the first data are associated with the second payload data”, claim 7]
Combining these elements, the amendment effectively introduces the requirement that the write operation (as per Claims 6 and 7) is executed only after the successful checksum validation (as per Claim 9).
Claim 3 (now part of claim 1):
The method as claimed in claim 1,
wherein the first payload data contain information regarding a write address and a data word,
and wherein implementing the write operation comprises writing data based on the data word to the write address.
claims 1, 4, 6 and 7:
Claim 1 discloses the overall method
[ie. “wherein the first frame comprises first header data, first payload data and a first checksum…”, claim 1]
and write operation is performed as a part of the method.
Structure of the first payload data
The limitation directs that the first payload is structured to include both a write address and a data word. However, per claim 4, the write address is obtained from the header [ie. “The method of claim 1, wherein the portion of the first header data comprises a memory address of a memory included with the first bus node, and wherein the function accesses the memory address”, claim 4]
Implementation of the write operation
Claim 6 (with claim 7) discloses the write operation. The specific write operation--writing data (the data word) to the write address—is functionally equivalent to the write step disclosed in Claim 6 (and sequenced in Claim 7),
[ie. “The method of claim 5, wherein the function accessing the memory address further comprises writing second data to the memory address, and wherein the second data are associated with the first payload data”, claim 6]
[ie. “The method of claim 6, wherein the first data are read before the second data are written, and wherein the first data are associated with the second payload data”, claim 7]
Claim 4:
The method as claimed in claim 1, wherein the second frame is transmitted in the same time interval in which the first frame is received.
Claims 1 and 2
Underlying Framework from Claim 1:
Claim 1 provides the basic method framework including receiving the first frame and transmitting the second frame.
[ie. “a second frame comprising the second header data, the second payload data, and a second checksum calculated using the second payload data and the first header data simultaneously while the first frame is received; and transmitting, from the first bus node to the second bus node using the clocked data transfer from the first interface controller to the second interface controller via a second data channel different from the first data channel, the second frame simultaneously while receiving the first frame via the first data channel”, claim 1]
Concurrent Transmission and Reception:
Claim 2 specifies that the second frame is transmitted concurrently (i.e., during the same time interval) with the reception of the first frame.
[ie.” The method of claim 1, wherein the second frame is transmitted while the first frame is being received”, claim 2]
Claim 5
The method of claim 1, wherein the second frame is transmitted while the first frame is being received.
claims 1 and 3
Base Framework from Claim 1
The method of Claim 1 already involves receiving a first frame and transmitting a second frame via clocked data transfer.
[ie. “a first frame via a first data channel using clocked data transfer via the serial data interface from a second bus node to the first bus node, wherein the second bus node comprises a second interface controller using the clocked data transfer… from the first bus node to the second bus node using the clocked data transfer”, claim 1]
Synchronous Operation with a Clock Signal:
The requirement for synchronous transmission and reception—i.e. the use of a clock signal to control the data transfer—is mapped to Claim 3
[ie. “The method of claim 1, wherein the clocked data transfer is a synchronous clocked data transfer using a clock signal generated by the second interface controller at the second bus node.”, claim 3]
Claim 6
The method as claimed in claim 1, wherein implementing the read operation takes place directly after receiving the first header data and even before the first frame has been completely received.
claim 1
In Claim 1 the first frame is received and, responsive to receiving a portion of it, a function is executed that includes generating the second frame. This “responsive” language implies that certain operations (like the read) may begin before the entire first frame is received.
[ie. “wherein the first frame comprises first header data, first payload data and a first checksum; and responsive to receiving a portion of the first frame”, claim 1] which implies that the read operation (a component of the function that generates the second frame) is initiated without waiting for the complete first frame
Claim 7
A bus node comprising: a transmitting and receiving device configured to receive a first frame via a first data channel,
wherein the first frame comprises at least a first header field having first header data and a first payload field having first payload data;
a control logic configured to implement a read operation at a read address determined by the first header data, and further configured to implement a write operation on the basis of the first payload data;
and a frame encoder configured to generate a second frame containing at least a second payload field having second payload data based on the data read when implementing the read operation;
wherein the transmitting and receiving device is further configured to transmit the second frame via a second data channel with a temporal overlap with receiving the first frame via the first data channel.
Claims 4-7 and 10
Transmitting/Receiving Device (claim 10)
[ie.” A first bus node for electronic communication, the first bus node comprising: a first interface controller configured to receive a first frame via a first data channel”, claim 10]
[ie. “wherein the first frame comprises first header data, first payload data and a first checksum”, claim 10]
Control Logic for Read and Write Operations (claims 4-7 and 10]
[ie. “a control logic configured to execute a function associated with the first header data, wherein the function is executed simultaneously while the first frame is received”, claim 10].
In the method claims (particularly Claims 4–7), that function includes both reading from a memory address (derived from the header) and performing a write operation (with the write operation associated with the payload data.
[ie. “The method of claim 1, wherein the portion of the first header data comprises a memory address of a memory included with the first bus node, and wherein the function accesses the memory address”, claim 4]
[ie. “The method of claim 4, wherein the function accessing the memory address further comprises reading first data from the memory address, and wherein the second payload data are dependent on the first data”, claim 5]
[ie. “The method of claim 5, wherein the function accessing the memory address further comprises writing second data to the memory address, and wherein the second data are associated with the first payload data”, claim 6]
[ie. “The method of claim 6, wherein the first data are read before the second data are written, and wherein the first data are associated with the second payload data”, claim 7]
Frame Encoder (claim 10)
[ie. “and a frame encoder configured to generate a second frame further comprising second header data, second payload data, and a second checksum, and further configured to calculate the second checksum based on the second payload data and the first header data”, claim 10]
Temporal Overlap (claim 10)
This “simultaneous” or “temporal overlap” operation is the same.
[ie. “wherein the first interface controller is further configured to transmit the second frame to the second interface controller via a second data channel different from the first data channel simultaneously while receiving the first frame via the first data channel”, claim 10]
Claim 8
The bus node as claimed in claim 7, wherein the first frame additionally contains a checksum
and the control logic is configured to implement the write operation only after successful checking of the checksum.
claims 1, 6, 7 and 9
Checksum Inclusion (claim 1)
Claim 1, which discloses that the first frame comprises a checksum
[ie. “wherein the first frame comprises first header data, first payload data and a first checksum; and responsive to receiving a portion of the first frame, executing, at the first bus node, a function to generate second header data and second payload data based at least on a portion of the first header data; generating, at the first bus node, a second frame comprising the second header data, the second payload data, and a second checksum calculated using the second payload data and the first header data simultaneously’, claim 1]
Conditional Write Operation (claims 6, 7 and 9)
Claim 9, specifies that the first bus node validates the first checksum (based on the first header and payload data) before proceeding with further operations. In the method, the write operation (described in Claims 6 and 7) is performed only after this validation is successful.
[ie. “The method of claim 1, further comprising: validating, at the first bus node, the first checksum based on the first header data and the first payload data”, claim 9]
[ie. “The method of claim 5, wherein the function accessing the memory address further comprises writing second data to the memory address, and wherein the second data are associated with the first payload data”, claim 6]
[ie. “The method of claim 6, wherein the first data are read before the second data are written, and wherein the first data are associated with the second payload data, claim 7]
Claim 9 (now part of claim 7)
The bus node as claimed in claim 7, wherein the first payload data contain information regarding a write address and a data word,
and wherein implementing the write operation comprises writing data based on the data word to the write address.
claims 1, 4, 6 and 7
Modification of the First Payload Data: •The claim requires that “the first payload data contain information regarding a write address and a data word.” • In the original disclosure (Claim 1), the first frame is defined to include first header data and first payload data [ie. “wherein the first frame comprises first header data, first payload data and a first checksum”, claim 1].
However, Claim 4 teaches that a portion of the first header data comprises a memory address used in the read operation. In contrast, this limitation shifts the location of the write address from the header to the payload, thereby modifying the structure of the first payload [ie. “The method of claim 1, wherein the portion of the first header data comprises a memory address of a memory included with the first bus node, and wherein the function accesses the memory address”, claim 4]
Implementation of the Write Operation: • The claim further recites that “implementing the write operation comprises writing data based on the data word to the write address.” • In the patent’s disclosure, Claim 6 specifies that the function accessing the memory address further comprises writing second data to that memory address [ie. “The method of claim 5, wherein the function accessing the memory address further comprises writing second data to the memory address, and wherein the second data are associated with the first payload data”, claim 6], with Claim 7 clarifying the sequence (i.e. that the read occurs before the write) [ie. “The method of claim 6, wherein the first data are read before the second data are written, and wherein the first data are associated with the second payload data”, claim 7] • Thus, while the original claims associate the write operation with a memory address extracted from the header (per Claim 4), this limitation maps to the same functional write operation disclosed in Claims 6 and 7 but with the address and data now derived from the payload.
Claim 10
The bus node as claimed in claim 7, wherein the control logic is configured to implement the read operation directly after receiving the first header data
even before the first frame has been completely received
claims 1 and 7
This emphasizes that the read operation is initiated immediately upon receipt of the header rather than waiting for the entire fame. Although none of the dependent claims spell out this exact timing, the inherent processing in claim 1 support this approach.
The overall method in claim 1 teaches that operations (such as generating the second frame) occur concurrently with the reception of the first frame. The new limitation specially narrows this by requiring that the read operation starts as soon as the header is available, without waiting for the remainder of the frame. This is consistent with the “responsive to receiving a portion” language in claim 1 [ie. “wherein the first frame comprises first header data, first payload data and a first checksum; and responsive to receiving a portion of the first frame, executing, at the first bus node”, claim 1],
and the ordered sequencing of operations (read-before write) clarified in claim 7 [ie. “The method of claim 6, wherein the first data are read before the second data are written, and wherein the first data are associated with the second payload data”, claim 7]
Claims 11-22 are rejected for similar reasons as stated above.
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.
Claim(s) 1, 2, 4-8, 10-12, 17-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Roethig et al. (US 20160261375) in view of Mishra (20210303489).
Per claim 1,
Roethig discloses
A method comprising:
receiving a first frame via a first data channel, wherein the first frame comprises at least a first header field having first header data and a first payload field having first payload data. The process of receiving a frame of encoded data from a communication link is explained with the frame features a predefined fixed length and incorporates a synchronization symbol. [ie. “A method performed at a physical layer of a communication interface in a receiving device, comprising: receiving a frame of encoded data from a communication link, wherein the frame has a predefined fixed length; receiving a synchronization symbol associated with the frame of encoded data; and identifying a type of the frame based on the synchronization symbol, wherein the synchronization symbol is encoded using a redundant coding scheme that supports error correction for information in the symbol identifying the type of the frame”, Roethig, claim 18].
Details the format of a 2-byte header in a data packet with the header includes an 8-bit channel identifier and metadata, which may contain a payload size and target address [ie. “FIG. 8 illustrates the format of a 2-byte header 800 in a data packet. The format and contents of the header 800 can provide additional information that may act as a reliable guard-band against multiple bit errors. The header 706, 734 includes an 8-bit channel identifier (Channel ID) 806 occupying the first 8 UI intervals 802. The second 8 UI intervals 804 carry a 3-bit sequence number 808 and a 5-bit ECC or CRC field 810. The ECC/CRC field 810 may be used to carry a single-bit error correction, dual-bit error detection (SECDED) code. That is, the SECDED code can detect and correct a single-bit error and detect, but not correct, a dual-bit error”, Roethig, FiG.8, [0093]]. The explanation of a first data packet consists of a fixed length header and a payload data with redundant data included for integrity checking to ensure proper processing of the received frame is described [ie. “In one example, a first data packet is encoded to obtain the frame of encoded data. The first data packet may include a header of fixed length and payload data. The first data packet may include redundant data that provides for data integrity checking of at least a portion of the first data packet. The redundant data may include an error correction code for the header, an error correction code for the payload, and/or a checksum for the payload. The first data packet may be encoded into a number of frames determined based on size of the data packet. A first frame may be indicated as a starting frame of the number of frames using a first type of synchronization symbol. In some instances, one or more frames used to encode the data in addition to the first frame may be indicated as continuation frames using a second type of synchronization symbol that is different from the first type of synchronization symbol”, Roethig, [0121]]. Illustration of the structure of frame and how synchronization symbols precede data transmission is shown. [Roethig, FIG. 7].
implementing a read operation at a read address determined by the first header data;
The header field contain metadata such as channel ID, payload size, and target address in a destination memory, which is used for reading data from a specific memory location [ie. “The channel ID 806 may be used to indicate the routing information of the packet. In one example, the routing information includes source and destination information. All metadata associated with a packet may be associated with the channel ID. The metadata may include payload size, target address in a destination memory, requirement for response, requirement for re-transmission in case of failure, and other information. A set of metadata may be pre-defined for each channel ID. For example, channel ID 0x0 may be used for packets of size 128 byte routed from point A to point B, channel ID 0x1 may be used for packets containing messages of size 4 byte and requiring re-transmission in case of failure, and so on”, Roethig, FIG. 8, [0094]].
The process of encoding first data packet, which includes a header and payload data, into a frame of encoded data, where the header specifies the location which the payload should be read is described [ie. “In one example, a first data packet is encoded to obtain the frame of encoded data. The first data packet may include a header of fixed length and payload data. The first data packet may include redundant data that provides for data integrity checking of at least a portion of the first data packet. The redundant data may include an error correction code for the header, an error correction code for the payload, and/or a checksum for the payload. The first data packet may be encoded into a number of frames determined based on size of the data packet. A first frame may be indicated as a starting frame of the number of frames using a first type of synchronization symbol. In some instances, one or more frames used to encode the data in addition to the first frame may be indicated as continuation frames using a second type of synchronization symbol that is different from the first type of synchronization symbol.”, Roethig, [0121]].
In addition, metadata is specified in the header in which it can include a destination memory address for the data and the type of data transfer (e.g. read, write) [ie. “The Link Layer 404 may form data packets in a way that indicates the nature of the data itself. General-purpose interfaces such as PCI-E, Ethernet or USB use a header to provide metadata associated with the data. Such metadata can include, for example: the size of the data block that follows, a destination memory address for the data, the type of data transfer (e.g. read, write), and/or protocol features associated with the data block (e.g. acknowledge required, resend in case of error). Special-purpose interfaces such as multi-media interfaces can use a timed sequence for primary data that closely follows a standard video format timing specification and fixed time slots for secondary data.”, Roethig, [0061]].
generating a second frame containing at least a second payload field having second payload data based on the data read when implementing the read operation. Encoding a first data packet into a frame of encoded data, including a header and payload field is described. Also in the encoding process, data integrity checking, such as ECC and CRC, is also included [ie. “In one example, a first data packet is encoded to obtain the frame of encoded data. The first data packet may include a header of fixed length and payload data. The first data packet may include redundant data that provides for data integrity checking of at least a portion of the first data packet. The redundant data may include an error correction code for the header, an error correction code for the payload, and/or a checksum for the payload. The first data packet may be encoded into a number of frames determined based on size of the data packet. A first frame may be indicated as a starting frame of the number of frames using a first type of synchronization symbol. In some instances, one or more frames used to encode the data in addition to the first frame may be indicated as continuation frames using a second type of synchronization symbol that is different from the first type of synchronization symbol “, Roethig, [0121]].
A high-priority second data packet that can be transmitted before completing the transmission of the first packet, effective generating a second frame while another frame is still in progress [ie. ”A high priority second packet may be transmitted after transmission of a first packet has been commenced, and before transmission of the first packet is completed. For example, the first data packet may be encoded into a plurality of frames, and at least one of the plurality of frames may have been transmitted on the communication link. A second data packet carrying low latency or high priority data may be encoded into a prioritized frame, and the prioritized frame may be transmitted before the plurality of frames has been transmitted in its entirety on the communication link. In some instances, the low latency or high priority data may be encoded into a single prioritized frame. The remaining frames of the plurality of frames may be transmitted after the second frame is transmitted”, Roethig, [0122]].
The second frame may contain configurable metadata based on data read from a previous operation, and that such a frame may be prioritized if the metadata changes. [ie. “In some examples, the header includes an identification number indicating a type of the first data packet and metadata associated with the type of the first data packet. The header may indicate that the payload includes configurable metadata. When the configurable metadata is determined to have changed, a second data packet may be encoded into a prioritized frame, the second data packet including the configurable metadata. The prioritized frame may be transmitted as a high-priority frame. In some instances, the second data packet may be encoded into a single prioritized frame”, Roethig, [0123]].
transmitting the second frame via a second data channel with a temporal overlap with receiving the first frame via the first data channel.
Claim 15 states that a first frame and a second frame are transmitted concurrently on the communication link. The claim also specifies that each subsequent portion of the data packet is allocated to a next-in-sequence lane, supporting multi-channel transmission [ie. “The method of claim 14, wherein providing the frame of encoded data comprises: providing a third frame of encoded data for transmission on a third lane of the communication link, wherein the first frame, the second frame, and the third frame are transmitted concurrently on the communication link”, Roethig, claim 15].
Claim 14 provides a first frame on a first lane and a second frame on a second lane, encoding different portions of the same data packet. This ensures simultaneous transmission of frames across different data channels [ie. “The method of claim 1, wherein the communication link comprises a plurality of lanes, and wherein providing the frame of encoded data comprises: providing a first frame of encoded data for transmission on a first lane of the communication link, the first frame encoding a first received portion of a data packet to be transmitted on the communication link; and providing a second frame of encoded data for transmission on a second lane of the communication link, the second frame encoding a second portion of the data packet that is received immediately after the first portion, wherein the first frame and the second frame are transmitted concurrently on the communication link, and wherein each subsequent portion of the data packet is allocated to a next-in-sequence lane”, Roethig, claim 14].
Paragraph [0139] explains that the first and second frames can be transmitted concurrently on a communication link with each portion of the packet being sent over a different lane [ie. “In some examples, the communication link has a plurality of lanes. A first frame of encoded data may be received from a first lane of the communication link, where the first frame encodes a first received portion of a data packet to be transmitted on the communication link. A second frame of encoded data may be received from a second lane of the communication link, where the second frame encodes a second portion of the data packet that is received immediately after the first portion. The first frame and the second frame may be transmitted concurrently on the communication link. Each subsequent portion of the packet of data may be received from a next-in-sequence lane”, Roethig, [0139]].
and implementing a write operation on the basis of information regarding a write address and a data word contained in the first payload data, wherein implementing the write operation comprises writing data based on the data word to the write address.
Paragraph [0094] discusses metadata within the header, including target addresses in destination memory for routing the packet. This metadata can define whether the payload contains data for a write operation [ie. “The channel ID 806 may be used to indicate the routing information of the packet. In one example, the routing information includes source and destination information. All metadata associated with a packet may be associated with the channel ID. The metadata may include payload size, target address in a destination memory, requirement for response, requirement for re-transmission in case of failure, and other information. A set of metadata may be pre-defined for each channel ID. For example, channel ID 0x0 may be used for packets of size 128 byte routed from point A to point B, channel ID 0x1 may be used for packets containing messages of size 4 byte and requiring re-transmission in case of failure, and so on”, Roethig, [0094]].
The encoding a first data packet, which includes a header and payload data; and the payload may contain write data, which the system uses to perform write operations at the specified address are described [ie. “In one example, a first data packet is encoded to obtain the frame of encoded data. The first data packet may include a header of fixed length and payload data. The first data packet may include redundant data that provides for data integrity checking of at least a portion of the first data packet. The redundant data may include an error correction code for the header, an error correction code for the payload, and/or a checksum for the payload. The first data packet may be encoded into a number of frames determined based on size of the data packet. A first frame may be indicated as a starting frame of the number of frames using a first type of synchronization symbol. In some instances, one or more frames used to encode the data in addition to the first frame may be indicated as continuation frames using a second type of synchronization symbol that is different from the first type of synchronization symbol”, Roethig, [0121]].
Paragraph [0061] states that the payload data may include write instructions to update a specific memory location. It also mentions that error correction codes (ECC) are applied to ensure data integrity during the write process.” Roethig, [0061]].
The metadata in the header can include a destination memory address for data and the type of data transfer (e.g. read, write) [ie. “The Link Layer 404 may form data packets in a way that indicates the nature of the data itself. General-purpose interfaces such as PCI-E, Ethernet or USB use a header to provide metadata associated with the data. Such metadata can include, for example: the size of the data block that follows, a destination memory address for the data, the type of data transfer (e.g. read, write), and/or protocol features associated with the data block (e.g. acknowledge required, resend in case of error). Special-purpose interfaces such as multi-media interfaces can use a timed sequence for primary data that closely follows a standard video format timing specification and fixed time slots for secondary data”, Roethig, [0061]].
Meta data within the header, including a target address in a destination memory, which could be used as address [ ie. “The channel ID 806 may be used to indicate the routing information of the packet. In one example, the routing information includes source and destination information. All metadata associated with a packet may be associated with the channel ID. The metadata may include payload size, target address in a destination memory, requirement for response, requirement for re-transmission in case of failure, and other information. A set of metadata may be pre-defined for each channel ID. For example, channel ID 0x0 may be used for packets of size 128 byte routed from point A to point B, channel ID 0x1 may be used for packets containing messages of size 4 byte and requiring re-transmission in case of failure, and so on”, Roethig, [0094]]. “the payload includes configurable metadata” [12].
The above two sections confirm that the first payload data may contain a write address and a data word, and that write operations are implemented based on this information. Also, the new claim language could be interpreted that the “write operation” is based on the “write address” and “the data word contained in the first payload data”. Under this interpretation it is not required that the write address is contained in the first payload. If Applicant wants this interpretation, it is suggested that Applicant amend the claim to have the “write address” also contained in the first payload data.
Roethig does not specifically show the use of implementing the write operation on the basis on information regarding a write address and a data word contained in the first payload data, wherein implementing the write operation comprises writing data based on the data word to the write address. However, Mishra shows the use of the write operation on the basis on information regarding a write address and a data word contained in the first payload data, wherein implementing the write operation comprises writing data based on the data word to the write address (e.g., paragraph 9 and abstract).
It would have been obvious to one of ordinary skill in the art prior to the effective filing date to modify the method of Roethig with Mishra because it would provide for the use of encapsulation, to allow communication between devices using multiple protocols.
Per claim 2, Roethig discloses, The method as claimed in claim 1- refer to the indicated claim for reference(s)
Roethig further discloses
wherein the first frame additionally contains a checksum
Paragraph [0121] mentions that the first data packet includes redundant data for integrity checking. It also specifies the redundant data may include an error correction code for the header, an error code for the payload, and /or a checksum for the payload [ie.” In one example, a first data packet is encoded to obtain the frame of encoded data. The first data packet may include a header of fixed length and payload data. The first data packet may include redundant data that provides for data integrity checking of at least a portion of the first data packet. The redundant data may include an error correction code for the header, an error correction code for the payload, and/or a checksum for the payload. The first data packet may be encoded into a number of frames determined based on size of the data packet. A first frame may be indicated as a starting frame of the number of frames using a first type of synchronization symbol. In some instances, one or more frames used to encode the data in addition to the first frame may be indicated as continuation frames using a second type of synchronization symbol that is different from the first type of synchronization symbol”, Roethig, [0121]].
and the write operation is implemented only after successful checking of the checksum.
The checksum is used for data integrity checking, ensuring that the write operation only proceeds upon successful validation [ie. “In some examples, a first data packet is decoded. The first data packet may include a header of fixed length, and payload data from the frame of encoded data. The first data packet may include redundant data that provides for data integrity checking of at least a portion of the first data packet. The redundant data may include an error correction code for the header, an error correction code for the payload, and/or a checksum for the payload”, Roethig, [0134]].
Per claim 4, Roethig discloses, The method as claimed in claim 1- refer to the indicated claim for reference(s)
Roethig further discloses
wherein the second frame is transmitted in the same time interval in which the first frame is received.
The first frame of encoded data is received from a first lane, while a second frame is received from a second lane, encoding consecutive portions of the same data packet. It also states that the first frame and the second frame maybe transmitted concurrently on the communication link, confirming temporal overlap in their transmission [ie. “In some examples, the communication link has a plurality of lanes. A first frame of encoded data may be received from a first lane of the communication link, where the first frame encodes a first received portion of a data packet to be transmitted on the communication link. A second frame of encoded data may be received from a second lane of the communication link, where the second frame encodes a second portion of the data packet that is received immediately after the first portion. The first frame and the second frame may be transmitted concurrently on the communication link. Each subsequent portion of the packet of data may be received from a next-in-sequence lane”, Roethig, [0139]].
Per claim 5, Roethig discloses, The method as claimed in claim 1- refer to the indicated claim for reference(s)
Roethig further discloses
wherein the first frame and the second frame are received and respectively transmitted synchronously with a clock signal.
Transmit clock (TXCLK) that determines data transmission rates, ensuring synchronization of frame transmission with a clock signal is described. [ie. “In the example illustrated in FIG. 3, a sensor device 302 is coupled to a controller 320 through the control and/or data bus 330. In one example, the sensor device 302 may be provided in an IC device adapted to provide a sensor control function 304 that manages an image sensor, for example. In another example, the sensor device 302 may be adapted to provide a sensor control function 304 that monitors an environmental condition, or the operational state of a machine. The sensor device 302 may include configuration registers 306 and/or other storage devices 324, a processing circuit and/or control logic 312, a transceiver 310 and a number of line driver/receiver circuits 314a, 314b as needed to couple the sensor device 302 to a multi-wire control and/or data bus 330. The processing circuit and/or control logic 312 may include a processor such as a state machine, sequencer, signal processor or general-purpose processor. The transceiver 310 may include one or more receivers 310a, one or more transmitters 310c and certain common circuits 310b, including timing, logic and storage circuits and/or devices. In some instances, the transceiver 310 may include encoders and decoders, clock and data recovery circuits, and the like. A transmit clock (TXCLK) signal 328 may be provided to the transmitter 310c, where the TXCLK signal 328 can be used to determine data transmission rates”, Roethig, [0042]].
To ensure synchronization between transmission and reception of frames, data may be serialized and transmitted in accordance with a clock signal [ie. “The control and/or data bus 330 is typically implemented as a serial bus in which data is converted from parallel to serial form (i.e. serialized) and/or encoded in sequences of symbols by a transmitter, which transmits the encoded data as a serial bitstream. A receiver processes the received serial bitstream using a decoder and/or serial-to-parallel convertor to decode and deserialize the data. In one example, the I2C bus provides two bidirectional lines 316, 318. Data may be serialized and transmitted on a Serial Data Line (SDA) 318 in accordance with a clock signal transmitted on a Serial Clock Line (SCL) 316. In some examples, data may be encoded and transmitted as symbols on two or more lines 316, 318. In some examples, data may be transmitted concurrently on independent channels using separate lines of a control and/or data bus 330”, Roethig, [0044]].
Per claim 6, Roethig discloses, The method as claimed in claim 1- refer to the indicated claim for reference(s)
Roethig further discloses
wherein implementing the read operation takes place directly after receiving the first header data and even before the first frame has been completely received.
Paragraph [0136] describes at least one frame of a data packet can be received before all frames associated with the data packet have been received. It also mentioned that out of sequence frame may be decoded to obtain second data packet before the first data packet is fully reviewed, which supports the concept of early read operations [ie. “In some instances, at least one of a plurality of frames associated with the first data packet from the communication link may be received before an out-of-sequence frame is received from the communication link, and before all frames associated with the first data packet have been received from the communication link. The out-of-sequence frame may be decoded to obtain a second data packet. The remaining frames of the plurality of frames may be received after the out-of-sequence frame is received and/or decoded”, Roethig, [0136]]
Per claim 7.
Roethig discloses
A bus node comprising: a transmitting and receiving device configured to receive a first frame via a first data channel, wherein the first frame comprises at least a first header field having first header data and a first payload field having first payload data; a control logic configured to implement a read operation at a read address determined by the first header data, and further configured to implement a write operation on the basis of information regarding a write address and a data word contained in the first payload data, wherein implementing the write operation comprises writing data based on the data word to the write address; and a frame encoder configured to generate a second frame containing at least a second payload field having second payload data based on the data read when implementing the read operation; wherein the transmitting and receiving device is further configured to transmit the second frame via a second data channel with a temporal overlap with receiving the first frame via the first data channel.
A sensor device connected to a controller and/or data bus, mentioning a processing circuit and/or control logic that may include a state machine, sequencer, or processor, similar to the control logic in the claim is described [ie. “In the example illustrated in FIG. 3, a sensor device 302 is coupled to a controller 320 through the control and/or data bus 330. In one example, the sensor device 302 may be provided in an IC device adapted to provide a sensor control function 304 that manages an image sensor, for example. In another example, the sensor device 302 may be adapted to provide a sensor control function 304 that monitors an environmental condition, or the operational state of a machine. The sensor device 302 may include configuration registers 306 and/or other storage devices 324, a processing circuit and/or control logic 312, a transceiver 310 and a number of line driver/receiver circuits 314a, 314b as needed to couple the sensor device 302 to a multi-wire control and/or data bus 330. The processing circuit and/or control logic 312 may include a processor such as a state machine, sequencer, signal processor or general-purpose processor. The transceiver 310 may include one or more receivers 310a, one or more transmitters 310c and certain common circuits 310b, including timing, logic and storage circuits and/or devices. In some instances, the transceiver 310 may include encoders and decoders, clock and data recovery circuits, and the like. A transmit clock (TXCLK) signal 328 may be provided to the transmitter 310c, where the TXCLK signal 328 can be used to determine data transmission rates”, Roethig, [0042]]
Discusses communication over a control and/or data bus, where IC devices transmit and receive data, supporting bidirectional communication, aligning with the transmitting and receiving device are mentioned [ie. “The IC devices 302, 320, and/or 322a-322n may communicate using the control and/or data bus 330. The control and/or data bus 330 may support unidirectional, bidirectional half-duplex or full-duplex modes of communication. The IC devices 302, 320, and/or 322a-322n may transmit data to other IC devices 302, 320, and/or 322a-322n. In some instances, certain IC devices 320 may be configured as a bus master, and certain devices 302, and/or 322a-322n may be configured as slave devices. The IC devices 302, 320, and/or 322a-322n may be compatible with, or compliant with one or more communications standards, protocols and signaling specifications”, Roethig, [0043]].
Details a communication link with multiple lanes, supporting simultaneous transmission of frames, and specifies that a first frame and a second frame may be transmitted concurrently, that confirming temporal overlap can be done [ie. “In some examples, the communication link includes a plurality of lanes. A first frame of encoded data may be provided for transmission on a first lane of the communication link, where the first frame encoding a first received portion of a data packet to be transmitted on the communication link. A second frame of encoded data may be provided for transmission on a second lane of the communication link, where the second frame encodes a second portion of the data packet that is received immediately after the first portion. The first frame and the second frame may be transmitted concurrently on the communication link. Each subsequent portion of the packet of data may be allocated to a next-in-sequence lane. A third frame of encoded data may be provided for transmission on a third lane of the communication link, where the first frame, the second frame, and the third frame are transmitted concurrently on the communication link”, Roethig, [0125]] “the payload includes configurable metadata” [12].
Per claim 8, Roethig discloses, The bus node as claimed in claim 7- refer to the indicated claim for reference(s)
Roethig further discloses
, wherein the first frame additionally contains a checksum and the control logic is configured to implement the write operation only after successful checking of the checksum. The first data packet includes redundant data for integrity checking, which may include a checksum for the payload. This confirms that error checking is performed before data processing, supporting the claim that a write operation occurs only after checksum verification [ie. “In one example, a first data packet is encoded to obtain the frame of encoded data. The first data packet may include a header of fixed length and payload data. The first data packet may include redundant data that provides for data integrity checking of at least a portion of the first data packet. The redundant data may include an error correction code for the header, an error correction code for the payload, and/or a checksum for the payload. The first data packet may be encoded into a number of frames determined based on size of the data packet. A first frame may be indicated as a starting frame of the number of frames using a first type of synchronization symbol. In some instances, one or more frames used to encode the data in addition to the first frame may be indicated as continuation frames using a second type of synchronization symbol that is different from the first type of synchronization symbol”, Roethig, [0121]]
Per claim 10, Roethig discloses, The bus node as claimed in claim 7- refer to the indicated claim for reference(s)
Roethig further discloses
wherein the control logic is configured to implement the read operation directly after receiving the first header data even before the first frame has been completely received. At least one frame of a data packet can be received before all frames associated with the data packet have been received. It also stated that out of sequence frame may be decoded to obtain second data packet before the first data packet is fully reviewed, supporting the idea of initiating a read operation immediately after receiving the first header data [ie. “In some instances, at least one of a plurality of frames associated with the first data packet from the communication link may be received before an out-of-sequence frame is received from the communication link, and before all frames associated with the first data packet have been received from the communication link. The out-of-sequence frame may be decoded to obtain a second data packet. The remaining frames of the plurality of frames may be received after the out-of-sequence frame is received and/or decoded “, Roethig, [0136]]
As per claims 11-12, 17-21, they are rejected for similar reasons as stated above.
Claim(s) 13, 15 and 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Roethig et al. (US 20160261375 A1, hereinafter “Roethig”) in view of Mishra (20210303489) and further in view of Wei (20210203491).
As per claim 13, Roethig does not specifically show the use of determine a checksum for the second frame based on at least the second payload data and on the first header data of the first frame. However, Wei shows the use of a checksum for the second frame based on at least the second payload data and on the first header data of the first frame (e.g., paragraph 83). It would have been obvious to one of ordinary skill in the art prior to the effective filing date to modify the method of Roethig because it would provide for detection of errors in data transmission.
A per claims 15 and 22, they are rejected for similar reasons as stated above.
Claim(s) 14 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Roethig et al. (US 20160261375 A1, hereinafter “Roethig”) in view of Mishra (20210303489) and further in view of Shribman (20220103525).
As per claim 14, Roethig does not specifically show the use of generate a second header field, and the second frame further comprises the second header field. However, Shribman shows the use of a second header field, and the second frame further comprises the second header field (e.g., figure 2a). It would have been obvious to one of ordinary skill in the art prior to the effective filing date to modify the method of Roethig because it would provide for control information for the transmitter/receiver on how to handle the received frame.
A per claim 16, it is rejected for similar reasons as stated above.
Applicant's arguments filed 1/26/26 have been fully considered but they are not persuasive in view of the new grounds of rejection.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Sela (11137914) shows the use of encapsulating write pointers/addresses in the payload of a data frame.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to John Follansbee whose telephone number is 571-272-3964. The examiner can normally be reached Monday -Friday 8AM-5PM.
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, Amy Johnson can be reached on 571-272-2238. 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.
/JOHN A FOLLANSBEE/Supervisory Patent Examiner, Art Unit 2444
Prosecution Insights