Prosecution Insights
Last updated: April 19, 2026
Application No. 18/658,486

Parallel Data Encoding and Decoding

Non-Final OA §102§103§112
Filed
May 08, 2024
Examiner
ALSHACK, OSMAN M
Art Unit
2112
Tech Center
2100 — Computer Architecture & Software
Assignee
Aps Technology 1 LLC
OA Round
1 (Non-Final)
86%
Grant Probability
Favorable
1-2
OA Rounds
2y 6m
To Grant
99%
With Interview

Examiner Intelligence

Grants 86% — above average
86%
Career Allow Rate
445 granted / 517 resolved
+31.1% vs TC avg
Moderate +14% lift
Without
With
+14.4%
Interview Lift
resolved cases with interview
Typical timeline
2y 6m
Avg Prosecution
33 currently pending
Career history
550
Total Applications
across all art units

Statute-Specific Performance

§101
13.0%
-27.0% vs TC avg
§103
44.7%
+4.7% vs TC avg
§102
7.3%
-32.7% vs TC avg
§112
22.5%
-17.5% vs TC avg
Black line = Tech Center average estimate • Based on career data from 517 resolved cases

Office Action

§102 §103 §112
DETAILED ACTION Notice of Pre-AIA or AIA Status 1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Status of Claims 2. Claims 1-21 are presented for examination. Abstract 3. The abstract of the disclosure is acceptable for examination purposes. Oath Declaration 4. The Oath complies with all the requirements set forth in MPEP 602 and therefore is accepted. Information Disclosure Statement 5. The references listed in the information disclosure statement (IDS) submitted on 11/14/2024 have been considered. The submission complies with the provisions of 37 CFR 1.97. Form PTO- 1449 is signed and attached hereto. Drawings 6. The drawings are objected to because: At least the components 214, 212, and 210 of Fig. 2 are lack of bidirectional arrows. Paragraph [0024] of the applicant’s specification states “the decoder 220 may send a message back to state that six symbols have been received but the encoder 210 knows it needs seven symbols to complete the series. So, the encoder 210 knows to send the seventh symbol. If encoder 210 does not get a message from the decoder 222 in time (e.g., before a time-out) then the encoder 210 goes ahead and sends another set of symbols. If the block is 7 by 1476 bytes then seven symbols must be sent. When a block is encoded, a useful number (e.g., an optimized number) of symbols and symbol size is chosen.” As described above in Paragraph [0024], there is a communication back and forward between the encoder 210 and decoder 222. Therefore, the bidirectional arrows are required. Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance. Claim Rejections - 35 USC § 112 The following is a quotation of the first paragraph of 35 U.S.C. 112(a): (a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention. The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112: The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention. 7. Claims 5 and 13 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the enablement requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and/or use the invention. In regards to claim 5, the claim recites "listening, on a communications channel at the service, for a third plurality of encoded data packets over the packet network when total sent symbols for the first plurality of encoded data packets has not been received---; or listening, on the communications channel at the service, for a fourth plurality of encoded data packets over the packet network when total sent symbols for the second plurality of encoded data packets has not been received." The phrase of “listening.” Emphasis added, which was not described in the applicant’s specification in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and/or use the invention. The claim is too broad and the nature of the claim not enable to make and use the invention and what is reasonable will depend on the nature of the invention and the underlying art, the specification is not clear or complete enough to teach a person skilled in the art how to make and use the invention without undue experimentation. The enablement requirement refers to the requirement of that the specification must describe the invention in such terms that one skilled in the art can make and use the claimed invention. Dependent claim 13 recites similar limitations of claim 5. Therefore, is rejected for the same reason of claim 5. Claim Rejections - 35 USC § 112 The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION. The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. 8. Claims 1-21 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention. In regards to claim 1, the claim recites " receiving, at a service over a packet network, a first data block contained in a first plurality of encoded data packets and a second data block contained in a second plurality of encoded data packets; analyzing, at the service, the first plurality of encoded data packets to identify a first encoder-decoder pair identifier, wherein the first encoder-decoder pair identifier matches a first client encoder with a first service decoder for the first data block; analyzing, at the service, the second plurality of encoded data packets to identify a second encoder-decoder pair identifier, wherein the second encoder-decoder pair identifier matches a second client encoder with a second service decoder for the second data block; and decoding, at the service, the first plurality of encoded data packets using the first service decoder and the second plurality of encoded data packets using the second service decoder.” The phrase “service” “Emphasis added” is vague and leave the reader in doubt as to the meaning of technical feature to which it refers because there are many services have been described in the applicant’s specification. For example, transport protocol service, encoding service, aggregator service, packetization service, and decoding service. Thereby rendering the claim unclear. Clarification is required. Other independent claims 10 and 18 recite similar feature of claim 1. Therefore, are rejected for the same reason of claim 1 above. Dependent claims 2-9, 11-17, and 19-21 depend from the base claims 1, 10, and 18 respectively and inherently include limitations therein and therefore are rejected under 35 USC 112, 2nd paragraph as well. In regards to claim 5, the claim recites "listening, on a communications channel at the service, for a third plurality of encoded data packets over the packet network when total sent symbols for the first plurality of encoded data packets has not been received---; or listening, on the communications channel at the service, for a fourth plurality of encoded data packets over the packet network when total sent symbols for the second plurality of encoded data packets has not been received." The phrase of “listening.” Emphasis added. The specification does not provide any more clarification than the claim and it’s unclear in the claim as that what is meant by “listening,” is it means or refers to waiting, detecting, or sending? and thus, rendering the claim ambiguous. Please clarify. Paragraph [0047] of the applicant’s specification states “As discussed earlier, when symbols are not acknowledged as being received then additional symbols can be sent from the encoder(s). For example, a communications channel at the decoder service may listen for a third plurality of encoded data packets over the packet network when the total sent symbols for the first plurality of encoded data packets has not been received---. The communications channel at the service may also listen for a fourth plurality of encoded data packets over the packet network when total sent symbols for the second plurality of encoded data packets has not been received.” As described on the paragraph [0049] above, there is no explanation or definition what the term “listening” means or refers to. Therefore, the Examiner directs the applicant’s attention that during examination, a claim must be given its broadest reasonable interpretation (BRI) consistent with the specification as it would be interpreted by one of ordinary skill in the art (MPEP 2111). So, the Examiner interprets the feature of “listening” as “sending” and the claims being examined based on the examiner’s interpretation. “Emphasis added.” Dependent claim 13 recites similar limitations of claim 5. Therefore, is rejected for the same reason of claim 5. In regards to claim 6, the claim recites the limitation of "wherein the first plurality of encoded data packets, the second plurality of encoded data packets, or both comprise data fields representing at least one of: a total number of symbols, a symbol size, a sequence number, or a combination thereof." This feature is a "Markush group" because the claim recites a list of alternatively useable species, and it is improper to use the term "comprise" instead of "consisting of.” See MPEP 2173.05(h). (Emphasis added). Please clarify. Dependent claim 14 recites similar limitations of claim 6. Therefore, is rejected for the same reason of claim 6. In regards to claim 8, the claim recites “decapsulating the first plurality of encoded data packets and the second plurality of encoded data packets as UDP packets received over the packet network.” The phrase of “decapsulating.” Emphasis added. It’s unclear to the Examiner how to decapsulate the first and the second plurality of encoded data packets and there is no encapsulation to the first and second plurality of encoded data packets. Emphasis added. Please clarify. Dependent claim 16 recites similar limitations of claim 8. Therefore, is rejected for the same reason of claim 8. Claim Rejections - 35 USC § 102 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a) (1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention. 9. Claims 1, 2, and 4-19, and 21 are rejected under 35 U.S.C. 102(a) (1) as being anticipated by Medard et al. (US 2014/0269505 A1) "herein after as Medard." As per claim 1: Medard teaches or discloses a computer implemented method, comprising (see abstract, paragraph [0007], herein systems, circuits, and techniques described herein, a method for use in providing reliable data transfer in a wireless network comprises, and Figs. 2, 4&5): receiving, at a service over a packet network, a first data block contained in a first plurality of encoded data packets and a second data block contained in a second plurality of encoded data packets (see paragraph [0092], herein obtaining data elements associated with a data transfer operation between a first node and a remote second node; distributing the data elements among a plurality of encoder worker threads; and employing random linear network coding (RLNC) in the encoder worker threads to generate, for corresponding data elements, coded segments for transmission from the first node to the second node, and paragraph [0089], herein the decoder master thread 202 directs each incoming coded IP packet to a corresponding decoder worker thread 204a, . . . , 204n according to its TID. The decoder worker thread may then process the packets it receives to recover the original data packets. The original data packets may then be delivered to the appropriate application, paragraph [0092], herein After coded segments have been generated, the coded segments may be encapsulated (312) by adding NC headers to form coded IP packets, and Figs. 4, 5, & 6), and Figs. 2, 4, 5, & 6); analyzing, at the service, the first plurality of encoded data packets to identify a first encoder-decoder pair identifier block (see paragraph [0044], herein receiving coded segments from a remote wireless node, each coded segment being associated with a specific coding thread and being coded with a random linear network code (RLNC); reading thread identifiers within the received coded segments and directing the coded segments to corresponding decoder worker threads based thereon, each decoder worker thread having a corresponding encoder worker thread associated with the remote wireless node), wherein the first encoder-decoder pair identifier matches a first client encoder with a first service decoder for the first data block (see paragraph [0088], herein the decoder process 200 may include a decoder master thread 202 and a plurality of decoder worker threads 204a, . . . , 204n. Each of the encoder worker threads 104a, . . . , 104n in the source node may correspond to one of the decoder worker threads 204a, . . . , 204n in the destination node. Each encoder-decoder thread pair may operate independently from the other pairs and may be identified by a unique thread ID (TID), and Fig. 5); analyzing, at the service, the second plurality of encoded data packets to identify a second encoder-decoder pair identifier (see paragraph [0044], herein receiving coded segments from a remote wireless node, each coded segment being associated with a specific coding thread and being coded with a random linear network code (RLNC); reading thread identifiers within the received coded segments and directing the coded segments to corresponding decoder worker threads based thereon, each decoder worker thread having a corresponding encoder worker thread associated with the remote wireless node), wherein the second encoder-decoder pair identifier matches a second client encoder with a second service decoder for the second data block (see paragraph [0088], herein the decoder process 200 may include a decoder master thread 202 and a plurality of decoder worker threads 204a, . . . , 204n. Each of the encoder worker threads 104a, . . . , 104n in the source node may correspond to one of the decoder worker threads 204a, . . . , 204n in the destination node. Each encoder-decoder thread pair may operate independently from the other pairs and may be identified by a unique thread ID (TID), and Fig. 5); and decoding, at the service, the first plurality of encoded data packets using the first service decoder and the second plurality of encoded data packets using the second service decoder (see paragraph [0044], herein using the coded segments within the corresponding decoder worker threads to recover original data elements, paragraph [0089], herein he decoder master thread 202 directs each incoming coded IP packet to a corresponding decoder worker thread 204a, . . . , 204n according to its TID. The decoder worker thread may then process the packets it receives to recover the original data packets. The original data packets may then be delivered to the appropriate application, and Fig. 5). PNG media_image1.png 646 494 media_image1.png Greyscale As per claim 2: Medard teaches or discloses that decoding, at the service, the first plurality of encoded data packets using the first service decoder in a first time window and the second plurality of encoded data packets using the second service decoder in a second time window (see paragraph [0088], herein decoder process 200 may include a decoder master thread 202 and a plurality of decoder worker threads 204a, . . . , 204n. Each of the encoder worker threads 104a, . . . , 104n in the source node may correspond to one of the decoder worker threads 204a, . . . , 204n in the destination node. Each encoder-decoder thread pair may operate independently from the other pairs and may be identified by a unique thread ID (TID). In some implementations, different worker threads being executed within a node may be processed concurrently within different processors or processor cores associated with the node. In other implementations, multiple worker threads may be executed within a single processor in a node using, for example, time division multiplexing or a similar technique). As per claim 4: Medard teaches or discloses that sending, from the first service decoder to the first client encoder, a first acknowledge message indicating total received symbols for the first plurality of encoded data packets; and sending, from the second service decoder to the second client encoder, a second acknowledge message indicating total received symbols for the second plurality of encoded data packets (see paragraph [0016], herein employing random linear network coding further includes repeating generating and linearly combining to generate other coded segments in the first encoder worker thread until a predetermined number of coded segments has been generated or an acknowledgement message has been received from a corresponding processing thread in the second node, and paragraph [0048]). As per claim 5: Medard teaches or discloses that listening, on a communications channel at the service, for a third plurality of encoded data packets over the packet network when total sent symbols for the first plurality of encoded data packets has not been received, wherein the third plurality of encoded data packets is associated with the first data block; or listening, on the communications channel at the service, for a fourth plurality of encoded data packets over the packet network when total sent symbols for the second plurality of encoded data packets has not been received, wherein the fourth plurality of encoded data packets is associated with the second data block (see paragraph [0108], herein a transmitter will determine whether to retransmit information based on whether or not an acknowledgement (ACK) message or a negative acknowledgement (NACK) message is received in response to a transmission. Using the ARQ mechanism, block retransmissions are processed independently, and paragraph [0111]). As per claim 6: Medard teaches or discloses that wherein the first plurality of encoded data packets, the second plurality of encoded data packets, or both comprise data fields representing at least one of: a total number of symbols, a symbol size, a sequence number, or a combination thereof (see paragraph [0097], herein coded segments generated in a source node may be encapsulated into coded IP packets before transmission. During the encapsulation procedure, an NC header is added to the coded segment. FIG. 7 is a diagram illustrating an NC header format 400 that may be used in accordance with an embodiment. As shown, the NC header format 400 may include: an IP header field 402, a thread ID (TID) field 404, a block ID (BID) field 406, a segment ID (SID) field 408, a filed 412 for the number N.sub.s of segments in the coding block, and a coding coefficients field 414, and Fig. 7). As per claim 7: Medard teaches or discloses that decoding the first plurality of encoded data packets and the second plurality of encoded data packets using random linear network coding (RLNC) (see paragraph [0045], herein using the coded segments within the corresponding decoder worker threads to recover original data elements includes using the coded segments as redundant information to the uncoded segments within the decoder worker threads to recover the original data elements using systematic RLNC., and paragraph [0071], herein utilize systematic intra-session random linear network coding (RLNC) as a packet erasure code to support fast and reliable information transfer between wireless nodes. The systematic RLNC coding and decoding may be performed within, for example, a number of coding/decoding threads that span the channel between a transmitter and a receiver). As per claim 8: Medard teaches or discloses that decapsulating the first plurality of encoded data packets and the second plurality of encoded data packets as UDP packets received over the packet network (see paragraph [0100], herein the decoding process used at a decoder worker thread is essentially a reverse of the encoding process used in the corresponding encoder worker thread (see, e.g., FIG. 6). First, de-capsulation may be performed to strip the NC header from a received coded segment). As per claim 9: Medard teaches or discloses that releasing the first service decoder when the first data block has been decoded and the second service decoder when the second data block has been decoded (see paragraph [0085], herein at the destination node, a netfilter may intercept the incoming coded IP packets handed from WiMAX to the OS and deliver them to a corresponding network coding module in user space. The network coding module of the destination node may then send decoded packets (or original data packets) to the corresponding OS, which forwards the packets to the destination application). As per claim 10: Medard teaches or discloses a system for enhancing communications between a client and a service in a network, comprising (see abstract, paragraph [0007], herein systems, circuits, and techniques described herein, a method for use in providing reliable data transfer in a wireless network comprises, and Figs. 4&5): at least one processor (see Fig. 2, processor(s) 52); and a memory device (see Fig. 2, Memory 54) including instructions that, when executed by the at least one processor, cause the system to (see paragraph [0081], herein Memory 54 may include any type of system, device, or component, or combination thereof, that is capable of storing digital information (e.g., digital data, computer executable instructions and/or programs, etc.) for access by a processing device or other component): receive, at the service from a client over a packet network, a first data block contained in a first plurality of encoded data packets and a second data block contained in a second plurality of encoded data packets (see paragraph [0007], herein obtaining data elements associated with a data transfer operation between a first node and a remote second node; distributing the data elements among a plurality of encoder worker threads; and employing random linear network coding (RLNC) in the encoder worker threads to generate, for corresponding data elements, coded segments for transmission from the first node to the second node, and paragraph [0089], herein the decoder master thread 202 directs each incoming coded IP packet to a corresponding decoder worker thread 204a, . . . , 204n according to its TID. The decoder worker thread may then process the packets it receives to recover the original data packets. The original data packets may then be delivered to the appropriate application, paragraph [0092], herein After coded segments have been generated, the coded segments may be encapsulated (312) by adding NC headers to form coded IP packets, paragraphs [0034], [0097], and Figs. 4, 5, & 7); analyze, at the service, the first and second plurality of encoded data packets to identify a first data block number that matches a first client encoder with a first service decoder for the first data block and a second data block number that matches a second client encoder with a second service decoder for the second data block (see paragraph [0044], herein receiving coded segments from a remote wireless node, each coded segment being associated with a specific coding thread and being coded with a random linear network code (RLNC); reading thread identifiers within the received coded segments and directing the coded segments to corresponding decoder worker threads based thereon, each decoder worker thread having a corresponding encoder worker thread associated with the remote wireless node, and paragraph [0088], herein the decoder process 200 may include a decoder master thread 202 and a plurality of decoder worker threads 204a, . . . , 204n. Each of the encoder worker threads 104a, . . . , 104n in the source node may correspond to one of the decoder worker threads 204a, . . . , 204n in the destination node. Each encoder-decoder thread pair may operate independently from the other pairs and may be identified by a unique thread ID (TID), and Fig. 5); decode, at the service, the first plurality of encoded data packets using the first service decoder; and decode, at the service, the second plurality of encoded data packets using the second service decoder (see paragraph [0044], herein using the coded segments within the corresponding decoder worker threads to recover original data elements, paragraph [0089], herein he decoder master thread 202 directs each incoming coded IP packet to a corresponding decoder worker thread 204a, . . . , 204n according to its TID. The decoder worker thread may then process the packets it receives to recover the original data packets. The original data packets may then be delivered to the appropriate application, and Fig. 5). PNG media_image1.png 646 494 media_image1.png Greyscale As per claim 11: Medard teaches or discloses that when executed by the at least one processor, cause the system to: decode the first plurality of encoded data packets using the first service decoder in a first time window; and decode, at the service, the second plurality of encoded data packets using the second service decoder in a second time window, wherein the first time window overlaps with the second time window (see paragraph [0088], herein decoder process 200 may include a decoder master thread 202 and a plurality of decoder worker threads 204a, . . . , 204n. Each of the encoder worker threads 104a, . . . , 104n in the source node may correspond to one of the decoder worker threads 204a, . . . , 204n in the destination node. Each encoder-decoder thread pair may operate independently from the other pairs and may be identified by a unique thread ID (TID). In some implementations, different worker threads being executed within a node may be processed concurrently within different processors or processor cores associated with the node. In other implementations, multiple worker threads may be executed within a single processor in a node using, for example, time division multiplexing or a similar technique). As per claim 12: Medard teaches or discloses that when executed by the at least one processor, cause the system to: send, from the first service decoder to the first client encoder, a first acknowledge message indicating total received symbols for the first plurality of encoded data packets; and send, from the second service decoder to the second client encoder, a second acknowledge message indicating total received symbols for the second plurality of encoded data packets (see paragraph [0016], herein employing random linear network coding further includes repeating generating and linearly combining to generate other coded segments in the first encoder worker thread until a predetermined number of coded segments has been generated or an acknowledgement message has been received from a corresponding processing thread in the second node, and paragraph [0048]). As per claim 13: Medard teaches or discloses that when executed by the at least one processor, cause the system to: listen, on a communications channel at the service, for a third plurality of encoded data packets over the packet network when total sent symbols for the first plurality of encoded data packets has not been received, wherein the third plurality of encoded data packets is associated with the first data block; or listen, on the communications channel at the service, for a fourth plurality of encoded data packets over the packet network when total sent symbols for the second plurality of encoded data packets has not been received, wherein the fourth plurality of encoded data packets is associated with the second data block (see paragraph [0108], herein a transmitter will determine whether to retransmit information based on whether or not an acknowledgement (ACK) message or a negative acknowledgement (NACK) message is received in response to a transmission. Using the ARQ mechanism, block retransmissions are processed independently, and paragraph [0111]). As per claim 14: Medard teaches or discloses that wherein the first plurality of encoded data packets, the second plurality of encoded data packets, or both comprise fields representing at least one of a total number of symbols, a symbol size, a sequence number, or a combination thereof (see paragraph [0097], herein coded segments generated in a source node may be encapsulated into coded IP packets before transmission. During the encapsulation procedure, an NC header is added to the coded segment. FIG. 7 is a diagram illustrating an NC header format 400 that may be used in accordance with an embodiment. As shown, the NC header format 400 may include: an IP header field 402, a thread ID (TID) field 404, a block ID (BID) field 406, a segment ID (SID) field 408, a filed 412 for the number N.sub.s of segments in the coding block, and a coding coefficients field 414, and Fig. 7). As per claim 15: Medard teaches or discloses that when executed by the at least one processor, cause the system to decode the first plurality of encoded data packets and the second plurality of encoded data packets using random linear network coding (RLNC) (see paragraph [0045], herein using the coded segments within the corresponding decoder worker threads to recover original data elements includes using the coded segments as redundant information to the uncoded segments within the decoder worker threads to recover the original data elements using systematic RLNC., and paragraph [0071], herein utilize systematic intra-session random linear network coding (RLNC) as a packet erasure code to support fast and reliable information transfer between wireless nodes. The systematic RLNC coding and decoding may be performed within, for example, a number of coding/decoding threads that span the channel between a transmitter and a receiver). As per claim 16: Medard teaches or discloses that when executed by the at least one processor, cause the system to decapsulate the first plurality of encoded data packets and the second plurality of encoded data packets as first user datagram protocol (UDP) packets received over the packet network (see paragraph [0100], herein the decoding process used at a decoder worker thread is essentially a reverse of the encoding process used in the corresponding encoder worker thread (see, e.g., FIG. 6). First, de-capsulation may be performed to strip the NC header from a received coded segment). As per claim 17: Medard teaches or discloses that when executed by the at least one processor, cause the system to release the first service decoder when the first data block has been decoded and the second service decoder when the second data block has been decoded (see paragraph [0085], herein at the destination node, a netfilter may intercept the incoming coded IP packets handed from WiMAX to the OS and deliver them to a corresponding network coding module in user space. The network coding module of the destination node may then send decoded packets (or original data packets) to the corresponding OS, which forwards the packets to the destination application). As per claim 18: Kamath substantially teaches or discloses a computer implemented method, comprising (see abstract, paragraph [0007], herein systems, circuits, and techniques described herein, a method for use in providing reliable data transfer in a wireless network comprises, and Figs. 4&5) receiving, at a client from a service over a packet network, a first data block contained in a first plurality of encoded data packets and a second data block contained in a second plurality of encoded data packets (see paragraph [0092], herein obtaining data elements associated with a data transfer operation between a first node and a remote second node; distributing the data elements among a plurality of encoder worker threads; and employing random linear network coding (RLNC) in the encoder worker threads to generate, for corresponding data elements, coded segments for transmission from the first node to the second node, and paragraph [0089], herein the decoder master thread 202 directs each incoming coded IP packet to a corresponding decoder worker thread 204a, . . . , 204n according to its TID. The decoder worker thread may then process the packets it receives to recover the original data packets. The original data packets may then be delivered to the appropriate application, paragraph [0034], herein the one or more processors are configured to: (a) cause encoded segments to be generated in at least one of the encoder worker threads for corresponding data elements; and transmit the coded and encoded segments to the destination node via the transceiver to implement systematic RLNC, paragraph [0092], herein After coded segments have been generated, the coded segments may be encapsulated (312) by adding NC headers to form coded IP packets, and Figs. 4, 5, & 6); analyzing, at the client, the first plurality of encoded data packets to identify a first encoder-decoder pair identifier (see paragraph [0044], herein receiving coded segments from a remote wireless node, each coded segment being associated with a specific coding thread and being coded with a random linear network code (RLNC); reading thread identifiers within the received coded segments and directing the coded segments to corresponding decoder worker threads based thereon, each decoder worker thread having a corresponding encoder worker thread associated with the remote wireless node), wherein the first encoder-decoder pair identifier matches a first service encoder with a first client decoder for the first data block (see paragraph [0088], herein the decoder process 200 may include a decoder master thread 202 and a plurality of decoder worker threads 204a, . . . , 204n. Each of the encoder worker threads 104a, . . . , 104n in the source node may correspond to one of the decoder worker threads 204a, . . . , 204n in the destination node. Each encoder-decoder thread pair may operate independently from the other pairs and may be identified by a unique thread ID (TID), and Fig. 5); analyzing, at the client, the second plurality of encoded data packets to identify a second encoder-decoder pair identifier (see paragraph [0044], herein receiving coded segments from a remote wireless node, each coded segment being associated with a specific coding thread and being coded with a random linear network code (RLNC); reading thread identifiers within the received coded segments and directing the coded segments to corresponding decoder worker threads based thereon, each decoder worker thread having a corresponding encoder worker thread associated with the remote wireless node), wherein the second encoder-decoder pair identifier matches a second service encoder with a second client decoder for the second data block (see paragraph [0088], herein the decoder process 200 may include a decoder master thread 202 and a plurality of decoder worker threads 204a, . . . , 204n. Each of the encoder worker threads 104a, . . . , 104n in the source node may correspond to one of the decoder worker threads 204a, . . . , 204n in the destination node. Each encoder-decoder thread pair may operate independently from the other pairs and may be identified by a unique thread ID (TID), and Fig. 5); and decoding, at the client, the first plurality of encoded data packets using the first client decoder and the second plurality of encoded data packets using the second client decoder (see paragraph [0044], herein using the coded segments within the corresponding decoder worker threads to recover original data elements, paragraph [0089], herein he decoder master thread 202 directs each incoming coded IP packet to a corresponding decoder worker thread 204a, . . . , 204n according to its TID. The decoder worker thread may then process the packets it receives to recover the original data packets. The original data packets may then be delivered to the appropriate application, and Fig. 5). PNG media_image1.png 646 494 media_image1.png Greyscale As per claim 19: Medard teaches or discloses that decoding, at the client, the first plurality of encoded data packets using the first client decoder in a first time window and the second plurality of encoded data packets using the second client decoder in a second time window (see paragraph [0088], herein decoder process 200 may include a decoder master thread 202 and a plurality of decoder worker threads 204a, . . . , 204n. Each of the encoder worker threads 104a, . . . , 104n in the source node may correspond to one of the decoder worker threads 204a, . . . , 204n in the destination node. Each encoder-decoder thread pair may operate independently from the other pairs and may be identified by a unique thread ID (TID). In some implementations, different worker threads being executed within a node may be processed concurrently within different processors or processor cores associated with the node. In other implementations, multiple worker threads may be executed within a single processor in a node using, for example, time division multiplexing or a similar technique). As per claim 21: Medard teaches or discloses that sending, from the first client decoder to the first service encoder, a first acknowledge message indicating total received symbols for the first plurality of encoded data packets; and sending, from the second client decoder to the second service encoder, a second acknowledge message indicating total received symbols for the second plurality of encoded data packets (see paragraph [0016], herein employing random linear network coding further includes repeating generating and linearly combining to generate other coded segments in the first encoder worker thread until a predetermined number of coded segments has been generated or an acknowledgement message has been received from a corresponding processing thread in the second node, and paragraph [0048]). 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 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 present in the application indicating obviousness or nonobviousness. 10. Claims 3 and 20 are rejected under 35 U.S.C. 103 (a) as being unpatentable over Medard et al. (US 2014/0269505 A1) "herein after as Medard" in view of Kamath et al. (US 2014/0344326 A1 "herein after as Kamath." As per claims 3 and 20: Medard does not explicitly teach analyzing a first user datagram protocol (UDP) header for a first UDP packet from the first plurality of encoded data packets to identify the first encoder-decoder pair identifier, wherein the first encoder-decoder pair identifier is a first data block number; and analyzing a second UDP header for a second UDP packet from the second plurality of encoded data packets to identify the second encoder-decoder pair identifier, wherein the second encoder-decoder pair identifier is a second data block number. However, Kamath in the same the field of endeavor teaches analyzing a first user datagram protocol (UDP) header for a first UDP packet from the first plurality of encoded data packets to identify the first encoder-decoder pair identifier, wherein the first encoder-decoder pair identifier is a first data block number; and analyzing a second UDP header for a second UDP packet from the second plurality of encoded data packets to identify the second encoder-decoder pair identifier (see paragraph [0344], herein traffic of one protocol is encapsulated within traffic of another protocol, such as lossy UDP traffic encapsulated via a lossless TCP header, the flow distributor may calculate the hash based on the headers of the encapsulated protocol (e.g. UDP headers) rather than the encapsulating protocol (e.g. TCP headers)), wherein the second encoder-decoder pair identifier is a second data block number (see paragraph [0307], herein the second core 662 identifies from encoding of the second session identifier 688 that the second core 662 is the establisher of the SSL session. For example, the second core 662 may determine that the core identifier in the received session identifier matches the second core identifier 656, and paragraph [0284]). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify the system of Medard with the teachings of Kamath by analyzing a first and second user datagram protocol (UDP) headers for a first UDP packet from the first and second plurality of encoded data packets to identify the first and second encoder-decoder pair identifiers, wherein the first and second encoder-decoder pair identifiers are a first and second data block number respectively. This modification would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, because one of ordinary skill in the art would have recognized the analyzing a first and second user datagram protocol (UDP) headers for a first UDP packet from the first and second plurality of encoded data packets to identify the first and second encoder-decoder pair identifiers, wherein the first and second encoder-decoder pair identifiers are a first and second data block number respectively would have improved the communication system performance. Examiner Notes 11. When amending the claims, applicants are respectfully requested to indicate the portion(s) of the specification which dictate(s) the structure relied on for proper interpretation and also to verify and ascertain the metes and bounds of the claimed invention. Prior Art 12. The prior art of record, considered pertinent to the applicant’s disclosure, is listed in the attached PTO-892 form. Conclusion 13. Any inquiry concerning this communication or earlier communications from the examiner should be directed to OSMAN ALSHACK whose telephone number is (571)272-2069. The examiner can normally be reached on MON-FRI 8:30 AM-5:00 PM EST, also please fax interview request to (571) 273- 2069. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, ALBERT DECADY can be reached on 5712723819. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /OSMAN M ALSHACK/Examiner, Art Unit 2112
Read full office action

Prosecution Timeline

May 08, 2024
Application Filed
Oct 17, 2025
Non-Final Rejection — §102, §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12591482
SECURITY CONTROL METHOD AND APPARATUS FOR INTEGRATED CIRCUIT, STORAGE MEDIUM, AND ELECTRONIC DEVICE
2y 5m to grant Granted Mar 31, 2026
Patent 12591801
NON-TRANSITORY COMPUTER-READABLE RECORDING MEDIUM STORING SIMULATION PROGRAM, SIMULATION METHOD, AND INFORMATION PROCESSING DEVICE
2y 5m to grant Granted Mar 31, 2026
Patent 12580682
ROLLBACK FOR COMMUNICATION LINK ERROR RECOVERY IN EMULATION
2y 5m to grant Granted Mar 17, 2026
Patent 12572838
METHOD OF RECOVERING QUANTUM ERROR INDUCED BY NON-MARKOVIAN NOISE
2y 5m to grant Granted Mar 10, 2026
Patent 12554575
DATA PROCESSING METHOD AND APPARATUS
2y 5m to grant Granted Feb 17, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

1-2
Expected OA Rounds
86%
Grant Probability
99%
With Interview (+14.4%)
2y 6m
Median Time to Grant
Low
PTA Risk
Based on 517 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month