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 .
Drawings
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(4) because each of references character “20” (as packet receipt schedule), “21” (as request queue 21), and “22” (as data queue) and “23” (as Nack queue) has been used for both forwarding engine “11” and outbound traffic modules “12” in FIG. 2. However, it appears that the objects in forwarding engine 11 are different from those in outbound traffic modules 12. For example, the request queue 21 in 11 are corresponding to the sum of all the request queues 21 in the N outbound traffic modules.
Examiner further suggests putting a word symbol to the object of each of the corresponding digital symbol to help readers understand the function of object without referring back the specification.
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. 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 § 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.
Claims 1-7 and 9-13 are rejected under 35 U.S.C. 103 as being unpatentable over D1 (US 9270598).
For claim 1, D1 discloses a method for operating a networking node for information centric data networking (FIG. 8, the flowchart shows a method operating on an information centric data network by FIG. 1), the method comprising the steps of:
queuing a number of interest packets (FIG. 15, interest packet 20 and the associated queue 56) and data packets (FIG. 5, data packet 52 and the associated queue 66) received at the networking node in an interest queue and in a data queue, respectively (FIG. 5 shows interest packet queue 56 and data packet queue 66, in view of c12/l53-64 “…, FIG. 5 is a simplified block diagram illustrating example details of an embodiment of communication system 10. Incoming interest packet 20 and data packet 52 may be assigned to respective queues. A WRED module 54 may assign a suitable weight to interest packet 20 to generate a weighted queue 56. …” and c13/l9-23);
wherein outbound interest packets and data packets are prioritized over each other by a forward decision module of the networking node based on a length of the interest queue, or the data queue, or both (FIG. 5, forward decision module “WFQ 62” in view of c12/l64-c13/l23 “All interest queues may start out with substantially equal weights (e.g., as in a traditional fair queue). As backpressure (e.g., buildup or increase in queue size from less outflow of packets in the queue) is detected (e.g., due to congestion), the weight (e.g., effective drain rate) of the queue which matches the FIB entry in question may be reduced proportionally. As backpressure reduces, weights may be returned to original values. For example, queue 56 may have lower thresholds for lower priority packets (e.g., interest packets experiencing congestion). A queue buildup (e.g., backpressure) may cause the lower priority packets to be dropped, protecting higher priority packets in the same queue. Each flow of weighted interest packets are weighted for queuing purposes (e.g., per session, or by other criteria independent of CM 28) by module 58 and placed into another queue 60 for processing by WFQ module 62. Data packet 52 may be likewise weighted for queuing purposes by module 64 and placed into queue 66 for processing by WFQ module 62. WFQ allows different scheduling priorities to statistically multiplexed data flows comprising interest packets and data packets. Each flow has a separate FIFO queue, namely queue 60 for interest packets, and queue 66 for data packets. In a general sense, with a link data rate of R, at any given time N active flows are serviced simultaneously, each at an average data rate of R/N; if different flows are assigned different weights for queuing purpose, each flow will experience a different flow rate based on the assigned weight.”).
D1 does not specifically state that the interest packets are request packets. However, D1 states in c2/l62-67 “As used herein, an ‘interest packet’ includes a unit of data communicated in NDN environments, wherein a consumer entity (e.g., nodes 12(3), 12(4)) asks for certain content, for example, by broadcasting its interest in the content over all available connectivity, trying different paths in some order, etc.”. In other words, an interest packet may be a packet for requesting certain content, which is considered as a request packet. OOSA would have been motivated to replace the interest packet by D1 with request
Therefore, it would have been obvious to OOSA before the effective filing date of the application to to replace the interest packet by D1 with request packet for the benefit of requesting desired information (c2/l62-67 of D1).
Independent claim 12 is rejected because it is a claim of a non-transitory computer readable media encoded a forwarding decision program that implemented the method of claim 1 and has the same subject matter as claim 1.
As to claim 2, D1 discloses claim 1, D1 further discloses: wherein sending out request packets is prioritized over sending out data packets when a length of the request queue, or the data queue, or both is below a congestion warning alert level (FIGs. 1-8 and the associated text, such as FIG. 5 in view of c12/l53-c13/l23 “…, FIG. 5 is a simplified block diagram illustrating example details of an embodiment of communication system 10. Incoming interest packet 20 and data packet 52 may be assigned to respective queues. A WRED module 54 may assign a suitable weight to interest packet 20 to generate a weighted queue 56. … weights may represent congestion. All interest queues may start out with substantially equal weights (e.g., as in a traditional fair queue). As backpressure (e.g., buildup or increase in queue size from less outflow of packets in the queue) is detected (e.g., due to congestion), the weight (e.g., effective drain rate) of the queue which matches the FIB entry in question may be reduced proportionally. As backpressure reduces, weights may be returned to original values. For example, queue 56 may have lower thresholds for lower priority packets (e.g., interest packets experiencing congestion). A queue buildup (e.g., backpressure) may cause the lower priority packets to be dropped, protecting higher priority packets in the same queue. ….”).
As to claim 3, D1 discloses claim 1, D1 further discloses: wherein sending out data packets is prioritized over sending out request packets when a length of the data queue is about to reach a congested state (FIGs. 1-8 and the associated text, such c12/l53-c13/l23 “…, FIG. 5 is a simplified block diagram illustrating example details of an embodiment of communication system 10. Incoming interest packet 20 and data packet 52 may be assigned to respective queues. A WRED module 54 may assign a suitable weight to interest packet 20 to generate a weighted queue 56. … weights may represent congestion. All interest queues may start out with substantially equal weights (e.g., as in a traditional fair queue). As backpressure (e.g., buildup or increase in queue size from less outflow of packets in the queue) is detected (e.g., due to congestion), the weight (e.g., effective drain rate) of the queue which matches the FIB entry in question may be reduced proportionally. As backpressure reduces, weights may be returned to original values. For example, queue 56 may have lower thresholds for lower priority packets (e.g., interest packets experiencing congestion). A queue buildup (e.g., backpressure) may cause the lower priority packets to be dropped, protecting higher priority packets in the same queue. …”).
As to claim 4, D1 discloses claim 1, D1 further discloses: listing incoming request packets in a packet receipt schedule managed at the networking node together with an identifier for an incoming network interface unit of the request packet (FIGs. 1-8 and the associated text, such as Tables with identifiers in FIG. 4 and c3/l55-67 “Each intermediate NDN node (e.g., NDN router) maintains three data structures: (1) a content store for temporary caching of received data packets; (2) a pending Interest Table (PIT) for storing information about each interest packet it receives; and (3) a FIB for determining the next hop, wherein entries are entered according to name prefixes (rather than IP address prefixes). In addition, the NDN router has a strategy module that makes forwarding decisions for each interest packet. For example, when the router receives an interest packet, the strategy module first checks whether there is a matching data packet in the content store. If a match is found, the data packet is sent back to the incoming interface of the interest packet.”, c10/l19-30, “When interest packet 20 is received at node 12(2), node 12(2) may check its content store, determine that a corresponding data is absent therein, check its PIT, enter the name in the PIT if not previously found, and forward interest packet 20 to node 12(3) according to its FIB entry (e.g., node 12(3) may have previously announced /com/ as a named prefix and consequently been associated at node 12(2) with name /com/ in its FIB). Each intermediate node 12(3)-12(4) may perform substantially identical functions. Assume that node 12(4) attempts to forward interest packet 20 to node 12(5) based on its FIB entry, which associates /com/example with an interface for link 16(4).” and c11/l56-64).
As to claim 5, D1 discloses claim 4, D1 further discloses:
caching data packets in a local storage unit of the networking node (FIGs. 1-8 and the associated text, such as data packet queue 56 in FIG. 5 and c12/l53-63 “FIG. 5 is a simplified block diagram illustrating example details of an embodiment of communication system 10. Incoming interest packet 20 and data packet 52 may be assigned to respective queues. ...”; note that data queue 66 in FIG. 5 is considered as a local storage unit);
looking up the packet receipt schedule for finding at least one data packet stored in the local storage unit and corresponding to at least one of the request packets listed in the packet receipt schedule (FIGs. 1-8 and the associated text, such as Tables with identifiers in FIG. 4, data packet queue 56 in FIG. 5 and c12/l53-63); and
sending the at least one data packet to the incoming network interface unit associated with the respective identifier listed in the packet receipt schedule when the corresponding data packet is stored in the local storage unit (FIGs. 1-8 and the associated text, such as Tables with identifiers in FIG. 4, data packet queue 56 in FIG. 5, and c3/l55-67 “Each intermediate NDN node (e.g., NDN router) maintains three data structures: (1) a content store for temporary caching of received data packets; (2) a pending Interest Table (PIT) for storing information about each interest packet it receives; and (3) a FIB for determining the next hop, wherein entries are entered according to name prefixes (rather than IP address prefixes). In addition, the NDN router has a strategy module that makes forwarding decisions for each interest packet. For example, when the router receives an interest packet, the strategy module first checks whether there is a matching data packet in the content store. If a match is found, the data packet is sent back to the incoming interface of the interest packet.”, c10/l19-30, and c11/l56-64).
As to claim 6, D1 discloses claim 5, D1 further discloses: sending the at least one of the request packets listed in the packet receipt schedule to another incoming network interface unit which is not associated with the respective identifier listed in the packet receipt schedule when the corresponding data packet is not stored in the local storage unit (FIGs. 1-8 and the associated text, such as FIG. 5 in view of c3/l55-67 “Each intermediate NDN node (e.g., NDN router) maintains three data structures: (1) a content store for temporary caching of received data packets; (2) a pending Interest Table (PIT) for storing information about each interest packet it receives; and (3) a FIB for determining the next hop, wherein entries are entered according to name prefixes (rather than IP address prefixes). In addition, the NDN router has a strategy module that makes forwarding decisions for each interest packet. For example, when the router receives an interest packet, the strategy module first checks whether there is a matching data packet in the content store. If a match is found, the data packet is sent back to the incoming interface of the interest packet.”, c10/l19-30, “When interest packet 20 is received at node 12(2), node 12(2) may check its content store, determine that a corresponding data is absent therein, check its PIT, enter the name in the PIT if not previously found, and forward interest packet 20 to node 12(3) according to its FIB entry (e.g., node 12(3) may have previously announced /com/ as a named prefix and consequently been associated at node 12(2) with name /com/ in its FIB). Each intermediate node 12(3)-12(4) may perform substantially identical functions. ....”).
As to claim 7, D1 discloses claim 6, D1 further discloses:
listing the at least one of the request packets sent together with an associated packet identifier in a timetable (FIGs. 1-8 and the associated text, such as Tables with identifiers in FIG. 4);
removing the entry regarding at least one of the request packets listed in the timetable after a timeout (FIGs. 1-8 and the associated text, such as c12/l64-c13/l23 “All interest queues may start out with substantially equal weights (e.g., as in a traditional fair queue). As backpressure (e.g., buildup or increase in queue size from less outflow of packets in the queue) is detected (e.g., due to congestion), the weight (e.g., effective drain rate) of the queue which matches the FIB entry in question may be reduced proportionally. As backpressure reduces, weights may be returned to original values. For example, queue 56 may have lower thresholds for lower priority packets (e.g., interest packets experiencing congestion). A queue buildup (e.g., backpressure) may cause the lower priority packets to be dropped, protecting higher priority packets in the same queue. …”).
As to claim 9, D1 discloses claim 1, D1 further discloses:
listing data packets forwarded by the networking node in a forwarding table managed at the networking node (FIGs. 1-8 and the associated text, such as FIG. 5 in view of c3/l55-67 “Each intermediate NDN node (e.g., NDN router) maintains three data structures: (1) a content store for temporary caching of received data packets; (2) a pending Interest Table (PIT) for storing information about each interest packet it receives; and (3) a FIB for determining the next hop, …);
receiving a Nack packet at the networking node (Abstract, “… transmitting the NACK packet over the NDN environment towards a sender of the interest packet.”); and
removing an entry corresponding to at least one of the data packets from the forwarding table (c7/l11-22 “… With existing interest shaping schemes, B would forward the interests to C which would reject them (drop or NACK), but the endpoints that receive NACK packets (or observe drops) would have to co-operatively retard interest packets to avoid goodput (e.g., application level throughput) loss. In contrast, embodiments of communication system 10 may include the congested prefix information in the NACK packet, allowing both endpoints and intermediate nodes to effectively apply throttling to reduce congestion without losing goodput.”).
As to claim 10, D1 discloses claim 1, D1 further discloses:
queuing Nack-packets received at the networking node in a Nack queue (c2/l4-8, “the method can also include generating a negative acknowledgement (NACK) packet that includes the prefix marker, the NACK packet being indicative of congestion for any interest packet in the class of traffic indicated by the prefix marker over any path that includes the link” in view of FIG. 5, wherein a NACK packet is an interest packet being put on the interest packet queue 56);
wherein outbound Nack packets, request packets, data packets, or any combination thereof are prioritized over each other by the forward decision module based on a length of the request queue, the data queue, the Nack queue, or any combination thereof c12/l53-c13/l23 “…. A WRED module 54 may assign a suitable weight to interest packet 20 to generate a weighted queue 56. … weights may represent congestion. All interest queues may start out with substantially equal weights (e.g., as in a traditional fair queue). As backpressure (e.g., buildup or increase in queue size from less outflow of packets in the queue) is detected (e.g., due to congestion), the weight (e.g., effective drain rate) of the queue which matches the FIB entry in question may be reduced proportionally. As backpressure reduces, weights may be returned to original values. For example, queue 56 may have lower thresholds for lower priority packets (e.g., interest packets experiencing congestion). A queue buildup (e.g., backpressure) may cause the lower priority packets to be dropped, protecting higher priority packets in the same queue. …”).
As to claim 11, D1 discloses claim 9, D1 further discloses: adding the Nack packet to the Nack queue when the forwarding table does not contain an entry regarding the corresponding data packet (FIGs. 1-8 and the associated text, such as FIG. 5 in view of c10/l19-30, “When interest packet 20 is received at node 12(2), node 12(2) may check its content store, determine that a corresponding data is absent therein, check its PIT, enter the name in the PIT if not previously found, and forward interest packet 20 to node 12(3) according to its FIB entry (e.g., node 12(3) may have previously announced /com/ as a named prefix and consequently been associated at node 12(2) with name /com/ in its FIB). Each intermediate node 12(3)-12(4) may perform substantially identical functions. ....”).
As to claim 13, D1 discloses claim 12, D1 further discloses: a networking node for an information centric data networking, the networking node comprising the non-transitory computer readable media according to claim 12 (FIGs. 1-8 and the associated text, such as one of networking nodes 12(2) in FIG. 2; or the networking node by FIG. 5).
Claim 8 are rejected under 35 U.S.C. 103 as being unpatentable over D1 (US 9270598) in view of D4 (EP 3032784 A1, Foreign Reference dated 09/06/24, 22 pages).
As to claim 8, D1 discloses claim 7, D1 further discloses:
checking the timetable for at least one of the request packets sent upon receipt of a corresponding data packet (FIGs. 1-8 and the associated text, such as Tables with identifiers in FIG. 4, data packet queue 56 in FIG. 5, and c3/l55-67 “Each intermediate NDN node (e.g., NDN router) maintains three data structures: (1) a content store for temporary caching of received data packets; (2) a pending Interest Table (PIT) for storing information about each interest packet it receives; and (3) a FIB for determining the next hop, wherein entries are entered according to name prefixes (rather than IP address prefixes). In addition, the NDN router has a strategy module that makes forwarding decisions for each interest packet. For example, when the router receives an interest packet, the strategy module first checks whether there is a matching data packet in the content store. If a match is found, the data packet is sent back to the incoming interface of the interest packet.”, c10/l19-30, and c11/l56-64);
prioritizing a data object from the corresponding data packet to be stored in the networking node when local storage resources of the networking node are above a pre-defined storage threshold, and when a time to retrieve the corresponding data packet from a respective data source exceeds the calculated end-to-end delay, or when the corresponding data object has a lower time-to-live than the calculated end-to-end delay, or both (FIGs. 1-8 and the associated text, such c12/l53-c13/l23 “…. A WRED module 54 may assign a suitable weight to interest packet 20 to generate a weighted queue 56. … weights may represent congestion. All interest queues may start out with substantially equal weights (e.g., as in a traditional fair queue). As backpressure (e.g., buildup or increase in queue size from less outflow of packets in the queue) is detected (e.g., due to congestion), the weight (e.g., effective drain rate) of the queue which matches the FIB entry in question may be reduced proportionally. As backpressure reduces, weights may be returned to original values. For example, queue 56 may have lower thresholds for lower priority packets (e.g., interest packets experiencing congestion). A queue buildup (e.g., backpressure) may cause the lower priority packets to be dropped, protecting higher priority packets in the same queue. …”).
D1 is silent but D4, in the same field of endeavor of data communication,
calculating an end-to-end delay based on a respective time value set upon queuing the at least one of the request packets in the request queue in order forwarded to a respective data source of the requested data packet ([0011] “A round-trip time (RTT) for an Interest/Data exchange in environment 100 is a period of time between a time when consumer 102 issues or sends the Interest and a time when the consumer receives the Data packet that satisfies the Interest. The RTT is a summation of the following contributory time delays: an accumulated Interest queueing delay (AIQD); an application processing delay (or simply "processing delay"); an accumulated Data queueing delay (ADQD); and an accumulated packet propagation time of all the links on the path.”), OOSA would have been motivated to apply the teaching of D4 above to the queues by D1 to yield an predictable result of reducing end-to-end delay.
Therefore, it would have been obvious to OOSA before the effective filing date of the application to combine D1 and D4 for the benefit of reducing end-to-end delay ([0011] of D4).
Claims 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over D1 (US 9270598) in view of D2 (NPL date 09/06/24, 6 pages).
As to claim 14, D1 discloses claim 13, and is silent but D2, in the same field of endeavor of data communication, discloses: a vehicle comprising at least one networking node according to claim 13 (Abstract, “… we design and develop a Flying Router (FR), which combines a CCN router and a UAV, …”). OOSA would have been motivated to apply the teaching of D2 above to the network node by D1 to yield a predictable result of providing routing for FR.
Therefore, it would have been obvious to OOSA before the effective filing date of the application to combine D1 and D2 for the benefit of reducing end-to-end delay (Abstract of D2).
As to claim 15, D1 in view of D2 discloses claim 14, D2 further discloses wherein the vehicle comprises an aircraft (Abstract, “… we design and develop a Flying Router (FR), which combines a CCN router and a UAV, …”). The motivation of combining D1 and D2 is the same as stated in claim 14.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JIANYE WU whose telephone number is (571)270-1665. The examiner can normally be reached M-TH 8am-6pm.
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, Yemane Mesfin can be reached at (571) 272-3927. 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.
/JIANYE WU/Primary Examiner, Art Unit 2462
Prosecution Insights