DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
Acknowledgment is made of applicant's claim for foreign priority based on an application filed in Korea on 11/16/23. It is noted, however, that applicant has not filed a certified copy of the KR10-2023-0159339 application as required by 37 CFR 1.55. SEE IFW PD.RETR.FAIL (4/16/25) that an attempt by the Office to electronically retrieve the priority document FAILED on 4/16/25.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
Per Federal Register [Vol. 76, No 27, Weds. Feb 9, 2011] guidance, pg. 7167:
The following is a list of non-structural terms that may invoke § 112, ¶6: "mechanism
for," "module for," "device for," "unit for," "component for," "element for," "member
for," "apparatus for," "machine for," or "system for." This list is not exhaustive and other
non-structural terms may invoke § 112, ¶6
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: ‘delay time determination unit configured to determine ... prevent ... apply ... applies ... calculates ...’ and ‘delay time flooding unit configured to apply (flood)’ in dependent claims 4, 5, 6 and 9.
FURTHER NOTE: ‘intermediate node request collector configured to receive ... collects ...’ and ‘intermediate node calculator configured to calculate ... determine ... encode ... calculates ... recognizes ...’ and ‘intermediate node request transmitter configured to transmit ... transmit ... transmit ...’ in claims 1-4, 8 and 10 are interpreted to not invoke 112f since the plain meaning of collector and calculator (i.e. software or function that “collects” and software or function that “calculates” and modifiers “intermediate node request” and “intermediate node” are not phrases known to denote structure (i.e. these modifiers may be software) and the specification does not provide descriptions sufficient to denote structure) are not being used as a generic placeholder that is a substitute for ‘means’ (prong A fails) and ‘transmitter’ is a known structure that performs the function of transmitting (prong C fails).
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. SEE ALSO MPEP 2181: Therefore, the broadest reasonable interpretation of a claim limitation that invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is the structure, material or act described in the specification as performing the entire claimed function and equivalents to the disclosed structure, material or act. As a result, section 112(f) or pre-AIA section 112, sixth paragraph, limitations will, in some cases, be afforded a more narrow interpretation than a limitation that is not crafted in "means plus function" format. See related 112a and 112b rejections below for details of written description analyses.
101 rejection of claims 1-10 was considered; however, inclusion of “transmitter” in claim 1 system is clearly a machine and, therefore, statutory.
101 Alice rejection of dependent claims 5-7 considered since claims may be interpreted as reciting an abstract idea (mathematical formulas); however, the exception is integrated into a practical application that is a technical benefit/improvement network coding of bidirectional traffic (see IFW: abstract, [0006-7]).
Claim 1 term “deadline” is broadly interpreted as a delay time (see IFW [0035] (PGPub [0033]): ... The intermediate node calculator 20 determines the deadline, which is the optimal delay time according to the bidirectional link state data between the n types of source nodes and the destination node included in the RREQ packet, and encodes necessary information from packets transmitted from the n types of source nodes).
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.
Claims 4-9 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 written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention. Specifically, claim limitation(s) ‘delay time determination unit configured to determine ... prevent ... apply ... applies ... calculates ...‘ and ‘delay time flooding unit configured to apply (flood) ...’ in dependent claims 4, 5, 6 and 9 invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. Specifically, required structure to properly invoke 1112 is not disclosed such as processors, circuitry and memories and, furthermore, there are no algorithm(s) (at least two steps) for claimed limitation(s) and IFW disclosure merely discloses same claimed details of claimed functionalities (see IFW [0009-10;13;18; 34]). Claims 7 and 8 are rejected due to dependency and due to not resolving above issues. Therefore, the written description is deficient.
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.
Per Federal Register [Vol. 76, No 27, Weds. Feb 9, 2011] guidance, pg. 7167:
The following is a list of non-structural terms that may invoke § 112, ¶6: "mechanism
for," "module for," "device for," "unit for," "component for," "element for," "member
for," "apparatus for," "machine for," or "system for." This list is not exhaustive and other
non-structural terms may invoke § 112, ¶6
Claims 4-9 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim limitation(s) ‘delay time determination unit configured to determine ... prevent ... apply ... applies ... calculates ...‘ and ‘delay time flooding unit configured to apply (flood) ...’ in dependent claims 4, 5, 6 and 9 invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. Specifically, required structure to properly invoke 1112 is not disclosed such as processors, circuitry and memories and, furthermore, there are no algorithm(s) (at least two steps) for claimed limitation(s) and IFW disclosure merely discloses same claimed details of claimed functionalities (see IFW [0009-10;13;18; 34]). Claims 7 and 8 are rejected due to dependency and due to not resolving above issues. Therefore, the claims is/are indefinite and is/are rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
To overcome this/these rejection(s), applicant is encouraged to amend claims with substance equivalent to ‘delay time determination function configured to determine ... prevent ... apply ... applies ... calculates ...‘ and ‘delay time flooding function configured to apply (flood) ....’
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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 1 is rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Publication No. 2022/0095198 to Zhang et al. (“Zhang”) in view of U.S. Patent Publication No. 2015/0271062 to Vijayasankar et al. (“VJ”).
As to claim 1, Zhang discloses a delay control system for improving network coding of bidirectional traffic, the delay control system (Zhang : fig 1-9) comprising:
an intermediate node request collector configured to receive a route request (RREQ) packet transmitted from a source node (emphasis added) (Zhang: fig 1-9, [0014-168]: fig 6 ... block 602 node (intermediate node) designates an adhoc0 interface to receive messages and block 604 node receives RREQ messages from adhoc0 interface (intermediate node request collector configured to receive a route request (RREQ) packet transmitted from a source node) ... block 608 node obtains source IP address and destination IP address ... block 620 node checks whether a delay packet queue has been established ... block 622 636 node adds RREQ packet into delay packet queue if not timed out (intermediate node request collector configured to receive a route request (RREQ) packet transmitted from a source node) [0107-108; 110; 116-117; 123-124]).
Zhang did not explicitly disclose an intermediate node calculator configured to calculate a deadline between the source node and a destination node based on the RREQ packet received by the intermediate node request collector.
VJ discloses an intermediate node calculator configured to calculate a deadline between the source node and a destination node based on the RREQ packet received by the intermediate node request collector (VJ: fig 1-13, [0015-88]: fig 2-5 ... a RREQ frame 312 being generated by the source 211 that is broadcast ... every other node that receives the broadcast RREQ frames then rebroadcasts the RREQ, as illustrated at 313, 314 for example, if that node is not the intended destination (i.e. intermediate nodes) (an intermediate node ... between the source node and a destination node ... the RREQ packet received by the intermediate node) [0048] ... for link quality based delay (... calculate a deadline between the source node and a destination node ...), each node (see with [0048] above - intermediate nodes) that needs to rebroadcast the route request frame delays the retransmission for a time unit proportional to the link quality indicator (LQI) of the received link (see with [0048] above - an intermediate node calculator configured to calculate a deadline between the source node and a destination node based on the RREQ packet received by the intermediate node request collector) ... Equation 1 illustrates a possible implementation of random delay based on LQI [0054-55] ... RREQ frame is generated with a sequence number, originator address, destination address and hop count field ... at each hop (an intermediate node), the link cost for the link between the sender and the node is calculated (see with [0048; 54] above - an intermediate node calculator configured to calculate a deadline between the source node and a destination node ...) and added it to the route cost in the RREQ frame to get an overall route cost to that node (... based on the RREQ packet received by the intermediate node request collector) ... at each node that forwards a RREQ frame, a routing table entry is created for the originator with the next hop as the sender address ... the route cost is field is updated to be the new route cost that is calculated (... based on the RREQ packet received by the intermediate node request collector); the Hop count field is incremented; and the weak link count is incremented [0049-51] ... fig 9A-B ... source node may broadcast 902 a routing request packet (RREQ packet) that targets a destination node and this initial broadcast is received by a first set of nearby nodes, which may also be referred to as a first level of nodes (an intermediate node ... between the source node and a destination node ... the RREQ packet received by the intermediate node) as described with regard to FIGS. 4-5 ... each node that receives the RREQ then waits 906 for at least a minimum non-zero amount of delay time to allow for RREQ broadcasts from earlier levels ... a node may wait an additional randomized amount of wait time before rebroadcasting the RREQ (see with [0048-51] above - an intermediate node calculator configured to calculate a deadline between the source node and a destination node based on the RREQ packet received by the intermediate node request collector)) [0081-82]).
Zhang and VJ are analogous art because they are from the same field of endeavor with respect to router requests (RREQs).
Before the effective filing date, for AIA , it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by VJ into the system by Zhang. The suggestion/motivation would have been to provide LQI for different intermediate) nodes varies due to channel conditions that results in an inherent randomization of the timing of RREQ frame re-broadcasts and by randomizing RREQ retransmission, collisions may be reduced and, in addition to achieving randomization, use of LQI in this manner also inherently gives priority for RREQ transmission to nodes with better route costs (VJ: [0054]).
Zhang and VJ further disclose an intermediate node request transmitter configured to transmit the RREQ packet through an optimal path between the source node and the destination node based on the deadline (VJ: fig 1-13, [0015-88]: fig 2-5 & 9A-B ... while the Link cost based delay approach enables nodes with better link quality to transmit route request before others, it does not guarantee that route requests with lower overall route cost reaches a node first (optimal path) ... during the waiting period, a node (an intermediate node) may receive a RREQ which has a lower route cost (see with [0048-51;81-82] above - ... the RREQ packet through an optimal path between the source node and the destination node based on the deadline) ... the node may suppress the earlier RREQ and schedule (transmit) the RREQ with a lower cost for forwarding with the appropriate delay (see with [0048-51;81-82] above - an intermediate node request transmitter configured to transmit the RREQ packet through an optimal path between the source node and the destination node based on the deadline) ... importantly, when combined with protocol elements such as link cost based delay and artificial ordering of route request frames, it increases the chances of receiving a route request with better routing cost ahead of poorer route cost route request and, as a result, a near optimal routing request performance may be produced (see with [0048-51;81-82] above - an intermediate node request transmitter configured to transmit the RREQ packet through an optimal path between the source node and the destination node based on the deadline) [0065])
Same motivation applies as mentioned above to make the proposed modification.
Claims 2-3 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Publication No. 2022/0095198 to Zhang et al. (“Zhang”) in view of U.S. Patent Publication No. 2015/0271062 to Vijayasankar et al. (“VJ”) and further in view of U.S. Patent Publication No. 2011/0026429 to Ben Slimane et al. (“BS”).
As to claim 2, Zhang and VJ disclose the system of claim 1.
For motivation, see rejection of claim 1.
Zhang did not explicitly disclose wherein the intermediate node request collector collects the RREQ packet including bidirectional link state data between n types of source nodes and the destination node at an intermediate node.
BS discloses wherein the intermediate node request collector collects the RREQ packet including bidirectional link state data between n types of source nodes and the destination node at an intermediate node (BS: fig 1-11, [0007-105]: fig 2 ... step S10 involves providing or estimating a respective communication quality parameter associated with preferably each of the N source nodes (see with [0050; 87;89] below - wherein the intermediate node request collector collects the RREQ packet including bidirectional link state data between n types of source nodes and the destination node at an intermediate node) ... step S10 preferably involves estimating quality parameters representative of a respective communication quality (bidirectional link state data) associated with the source nodes (... between n types of source nodes and the destination node at an intermediate node) and the estimation of step S10 is preferably performed for each of the N source nodes, giving at total of at least N quality parameters (see with [0050; 87;89] below - wherein the intermediate node request collector collects the RREQ packet including bidirectional link state data between n types of source nodes and the destination node at an intermediate node) [0047] ... fig 6A-B ... quality parameters representative of the dynamic quality of communication links 41, 43, 45, 47 between the source nodes 10, 12, 14, 16 and the destination node 30 are estimated in step S10 of FIG. 2 ... the relay-destination link quality can be used together with the N source-relay quality parameters (bidirectional link state data between n types of source nodes and the destination node at an intermediate node)) [0050] ... fig 9-11 ... relay node 20 (an intermediate node) comprises a transmitter/receiver or transceiver 22 with connected antenna (system) for conducting communications with external nodes and the receiver is arranged to receive data (configured to receive a route request (RREQ) packet) from source nodes (from n source nodes) [0087] ... the relay node 20 (an intermediate node) comprises a data or receiver buffer 26 (intermediate node request collector) temporarily storing data received from other units, including the source nodes (see with [0047;50;87] above - an intermediate node request collector configured to receive a route request (RREQ) packet transmitted from n source nodes) and, in such cases, the network coder 24 can operate on and (re-) encode data stored therein [0089]).
Zhang, VJ and BS are analogous art because they are from the same field of endeavor with respect to network coding.
Before the effective filing date, for AIA , it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by BS into the system by Zhang and VJ. The suggestion/motivation would have been to provide network coding that significantly improves system throughput in communication qualities for different source nodes (BS: [0015]).
As to claim 3, see similar rejection to claim 2 where the system is taught by the system.
As to claim 3, Zhang, VJ and BS further disclose determine the deadline which is an optimal delay time according to bidirectional link state data between n types of source nodes and the destination node included in the RREQ packet (BS: fig 1-11, [0007-105]: ... examples of such quality parameters include delay parameters and data rate parameters and thus, a delay parameter can be representative of the communication delay occurring from the transmission time at the source node up to the reception time at the relay or destination node of the sent data (see with [0047;50;87] above - determine the deadline which is an optimal delay time according to bidirectional link state data between n types of source nodes and the destination node included in the RREQ packet) [0048] ... relay node 20 (an intermediate node) then performs network coding on data received from grouped nodes 12, 16 and forwards the resulting combined data to the base station 30, which is also the destination node for that data (see with [0047-48;50;87] above - determine the deadline which is an optimal delay time according to bidirectional link state data between n types of source nodes and the destination node included in the RREQ packet) [0075] ... function input can be communication quality parameters and the set of source nodes that optimizes the objective function is selected and information of the selected source nodes is employed by the relay node (an intermediate node) for providing the correct data and network encode it into the combined data destined for the destination node (see with [0047-48;50;75; 87] above - determine the deadline which is an optimal delay time according to bidirectional link state data between n types of source nodes and the destination node included in the RREQ packet) [0013] ... ... the relay node 20 (an intermediate node) comprises a data or receiver buffer 26 (intermediate node request collector) temporarily storing data received from other units, including the source nodes (see with [0013;47-48;50;75;87] above - an intermediate node request collector configured to receive a route request (RREQ) packet transmitted from n source nodes) and, in such cases, the network coder 24 can operate on and (re-) encode data stored therein [0089]).
For motivation, see rejection of claim 1.
As to claim 10, see similar rejection to claims 1-3.
As to claim 10, Zhang, VJ and BS further disclose transmit an RREQ packet encoded at an intermediate node to the destination node along a path having shortest transmission delay based on the deadline (VJ: fig 1-13, [0015-88]: fig 2-5 & 9A-B ... embodiments of the present disclosure include a wait mechanism that allows each node to wait for a designated period of time and to select a best RREQ from all those received (see with [0013;47-48;50;75;87;89] above - transmit an RREQ packet encoded at an intermediate node to the destination node along a path having shortest transmission delay based on the deadline) and to discard the other RREQ frames that it has received (see with [0013;47-48;50;75;87;89] above – NOT transmit an RREQ packet encoded at an intermediate node to the destination node along a path NOT having shortest transmission delay based on the deadline) and, in this manner, network congestion may be reduced by promoting the selection of the best available route for each transaction request (see with [0013;47-48;50;75;87;89] above - transmit an RREQ packet encoded at an intermediate node to the destination node along a path having shortest transmission delay based on the deadline) [0030]), and
transmit a route reply (RREP) packet corresponding to the encoded RREQ packet transmitted from the destination node to the source node (VJ: fig 1-13, [0015-88]: fig 2-5 & 9A-B ... forwarding them until they reach the destination, generation of RREPs upon receipt of an RREQ by the indicated destination, and hop-by-hop forwarding of these unicast RREPs towards the originator (see with [0013;30;47-48;50;75;87;89] above - transmit a route reply (RREP) packet corresponding to the encoded RREQ packet transmitted from the destination node to the source node) [0029]).
For motivation, see rejection of claim 1.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Publication No. 2022/0095198 to Zhang et al. (“Zhang”) in view of U.S. Patent Publication No. 2015/0271062 to Vijayasankar et al. (“VJ”), U.S. Patent Publication No. 2011/0026429 to Ben Slimane et al. (“BS”).and further in view of IEEE journal paper “Coding-Aware Multi-path Routing in Multi-Hop Wireless Networks” (2008) to Han et al. (“Han”).
As to claim 4, see similar rejection to claims 1-3 where the system is taught by the system.
For motivation, see rejection of claim 2.
Zhang did not explicitly disclose the intermediate node calculator calculates an expected delay time according to bidirectional link state data between n types of source nodes and the destination node included in the RREQ packet, and the delay control system comprises a delay time determination unit configured to determine the optimal deadline in the expected delay time (emphasis added).
Han discloses the intermediate node calculator calculates an expected delay time according to bidirectional link state data between n types of source nodes and the destination node included in the RREQ packet, and the delay control system comprises a delay time determination unit configured to determine the optimal deadline in the expected delay time (emphasis added)(Han: section B Coding-aware Packet Forwarding, pg 96-98: ... fig. 3 shows a scenario where node A (source node 1) wants to deliver packet a to D (see fig 3 - source node 1 and the destination node included in the RREQ packet), and at the same time B (source node 2) wants to deliver packet b to C (see fig 3 - source node 1 and the destination node included in the RREQ packet) and assume that the best path from A to D is A-E-GD, and the best path from B to C is B-E-F-C (see fig 3 - delay time according to bidirectional link state data between n types of source nodes and the destination node included in the RREQ packet) ... as long as paths E-A-C and E-B-D are also cached in node E, under CAMP node E will XOR a and b, and broadcast a ⊕ b to A and B. Then A and B could decode a⊕ b to get b and a respectively (see fig 3 - the intermediate node calculator calculates an expected delay time according to bidirectional link state data between n types of source nodes and the destination node included in the RREQ packet) and A then forwards b to C, and B can forward a to D (see fig 3 - the intermediate node calculator calculates an expected delay time according to bidirectional link state data between n types of source nodes and the destination node included in the RREQ packet) ... after the route discovery phase, the source has got multiple path candidates to the destination with ETX of all links on each path and source evaluates the ETX for each path and selects the top K of them (see fig 3 & ETX^P & T(i) equations 2 & 3 - the delay control system comprises a delay time determination unit configured to determine the optimal deadline in the expected delay time) (pg 96).
Zhang, VJ, BS and Han are analogous art because they are from the same field of endeavor with respect to ETX (expected transmission count).
Before the effective filing date, for AIA , it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Han into the system by Zhang, VJ and BS. The suggestion/motivation would have been to provide CAMP which employs a route discovery mechanism which returns multiple paths along with ETX (Han: abstract).
Conclusion
1. The following prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
A) US 12213051 – Xie
Disclosed are a route discovery method and apparatus, a device, and a storage medium. This method includes: receiving a route request packet that is broadcast to a current node; determining whether it is the first time that the current node receives the route request packet; if yes, evaluating, based on link overheads and retransmission overheads, performance of a real-time route and a historical route to obtain an evaluation result; and if the evaluation result indicates that the real-time route is better than the historical route, updating a reverse route of the current node based on the real-time route, to discover a route between a source node and a destination node based on the updated reverse route of the current node. Therefore, link overheads and retransmission overheads are considered in an AODV route discovery process, so that a discovered route has more balanced forward and reverse transmission performance.
B) US 20130265872 – Noh
A scheduling method and a scheduling apparatus based on physical layer network coding for bidirectional traffic are provided. The method includes setting up paths passing through a node to perform the physical layer network coding of the bidirectional traffic of sessions that pass through the node. The method further includes requesting, from neighboring nodes of the node, information to be used to schedule the sessions for the physical layer network coding. The method further includes scheduling the sessions for the physical layer network coding based on a queue differential of each session that is calculated based on the information, and a rate of each link of each session
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUNE SISON whose telephone number is (571)270-5693. The examiner can normally be reached 9:00 am - 5:00 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Emmanuel Moise can be reached at 571-272-3865. 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.
/JUNE SISON/Primary Examiner, Art Unit 2455