DETAILED ACTION
1. This office action is in response to the communication filed on 11/24/2025.
2. Claims 1-10 and 12 are pending.
Notice of Pre-AIA or AIA Status
3. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
4. A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 10/20/2025 has been entered.
Claim Objections
5. Claim(s) 1-2, 5-7, 10 and 12 is/are objected to because of the following informalities:
Regarding claims 1, 5, 10, and 12: the limitation “the receiver node” should be “the one of the receiver nodes” referring back to the limitation “one of the receiver nodes”.
In claims 1, 10 and 12, the limitation “said receiving node” lack an antecedent basis. The limitation should be “the one of the receiver nodes” referring back to the limitation “one of the receiver nodes”.
In claims 2 and 5, the limitation “the router node” should be “the one of the router nodes” referring back to the limitation “one of the router nodes” in claim 1.
In claims 6-7: the limitation “the at least one packet” lacks an antecedent basis. The limitation should be “at least one of the packets” referring back to the limitation “packets” in claim 1.
Appropriate correction(s) is/are required.
Response to Arguments
6. Applicant’s arguments, filed on 10/20/2025, have been fully considered but they are not persuasive.
Applicant’s argument: Sebayashi does not disclose that a repeater device receives, in a single message, a plurality of expected values of a protection parameter from a device associated with the receiving node. Furthermore, Sebayashi does not disclose "receiving said at least one packet from one of the transmitting nodes, said at least one packet being destined said receiving node and comprising said protection parameter in at least one field of said at least one packet," as recited in claim 1.
Applicant’s support: Sebayashi discloses signatures that are sets of conditions (traffic attributes, thresholds, etc.). These signatures are generated by a repeater device, based on network traffic analysis. These signatures are not "expected values" of a protection parameter to be compared against a field of a packet. They are sets of filtering criteria used by the repeater device to decide how to process the traffic. The filtering performed in Sebayashi consists of comparing the packet's attributes (IP address, port, etc.) against each locally stored signature. There is no single field in the packet (protection parameter) whose value would be compared against a plurality of expected values received from a receiver node. Accordingly, the mechanism described by Sebayashi is a multi- rule filtering approach (each signature being a rule), rather than a comparison against a list of expected values received from a receiver node.
Examiner’s response: The examiner respectfully directs applicant’s attention to see Sebayashi, figs. 1, 2 and para. 129, where a legitimate signature (i.e., a message comprises a legitimate signature as a protection parameter) is received from an adjacent repeater device (i.e., a device associated with a server or a communication terminal/equipment; see paras. 96, 127 where a legitimate signature includes attributes (e.g., source IP address, destination IP address, protocol, etc.) having values (e.g., source =172.16.10.24, destination =192.168.1.1/32, etc.) (i.e., expected values of a legitimate signature in at least one field such as source IP address and/or destination IP address of the packet) indicating characteristics of the legitimate packet; see paras. 102, 115 where a packet is received from a server or a communication equipment, and transmitted/passed to a communication equipment or a server without restriction when the packet has a legitimate signature.
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
7. Claim(s) 1-5, 8, 10 and 12 is/are rejected under 35 U.S.C. 102(a)(1)/102(a)(2) as being anticipated by Sebayashi et al. (US 2007/0166051 A1).
Regarding claim(s) 1, 10 and 12:
Sebayashi discloses a device for prioritizing at least one packet in a network composed of router nodes routing packets and of transmitter and receiver nodes transmitting and receiving the packets, the device being implemented in one of the router nodes that is connected to one of the receiver nodes (see fig. 1 and paras. 102-103 where a repeater device/router (i.e., device) controls the passage of a packet in a network comprising repeater devices/routers (i.e., routers nodes routing packets) and of servers and communication terminals/equipment (i.e., transmitter and receiver nodes transmitting and receiving the packets) based on a signature of the packet, wherein the packet corresponding to a legitimate signature is enabled to pass without restriction (i.e., prioritizing the packet)) and comprising:
a receiver (see fig. 2 for a packet acquiring unit);
(see fig. 2 for a network interfacing unit);
at least one processor; and at least one memory (see para. 113):
receiving a message comprising multiple expected values of a protection parameter, from a device associated with the receiver node; receiving said at least one packet from one of the transmitting nodes, said at least one packet being destined for said receiving node and comprising said protection parameter in at least one field of said at least one packet; and prioritizing said at least one packets when the value of said protection parameter corresponds to one of said expected values (see figs. 1, 2 and para. 129 where a legitimate signature (i.e., a message comprises a legitimate signature as a protection parameter) is received from an adjacent repeater device (i.e., a device associated with a server or a communication terminal/equipment); see paras. 96, 127 where a legitimate signature includes attributes (e.g., source IP address, destination IP address, protocol, etc.) having values (e.g., source =172.16.10.24, destination =192.168.1.1/32, etc.) (i.e., expected values of a legitimate signature in at least one field such as source IP address and/or destination IP address of the packet) indicating characteristics of the legitimate packet; see paras. 102, 115 where a packet is received from a server or a communication equipment, and transmitted/passed to a communication equipment or a server without restriction when the packet has a legitimate signature)).
Regarding claim(s) 2:
Sebayashi discloses:
placing the packets in a queue having access to one or more output interfaces of the router node, the access having priority over at least one other queue (see fig. 2 and para. 134 where legitimate packets are inputted into a legitimate cue (i.e., queue) to be outputted to another repeater device, a server, or a communications terminal).
Regarding claim(s) 3:
Sebayashi discloses:
filtering packets not comprising one of the expected values of the protection parameter (see fig. 9 and paras. 97, 150).
Regarding claim(s) 4:
Sebayashi discloses:
wherein the filtering comprises blocking, or destroying, or lowering the priority of the packets not comprising one of the expected values of the protection parameter (see fig. 9 and para. 134).
Regarding claim(s) 5:
Sebayashi discloses:
transmitting the message comprising the expected values of the protection parameter to a router node neighboring the router node connected to the receiver node (see paras. 127, 129).
Regarding claim(s) 8:
Sebayashi discloses:
wherein the at least one field comprising the protection parameter is one or more of the fields selected from a list consisting of: "Security Parameters Index" (SPI) of Internet Protocol security (IPsec),"Protocol" of Internet Protocol version 4 (IPv4),"Next Header" of Internet Protocol version 6 (IPv6),"Flow Label" of IPv6,Source Internet Protocol (IP) address, or destination IP address, or source port, or destination port, of IPv4 or IPv6,"Key" of Generic Routing Encapsulation (GRE), and Segment List, or Segment List [n], or Tag, or hash-based message authentication code (HMAC) tag-length-value (TLV) of Segment Routing IPv6 (Segment Routing IPv6 (SRv6)) (see paras. 96, 119, and/or 127).
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 of this title, 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.
8. Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sebayashi in view of Chien (US 2018/0131718 A1).
Regarding claim(s) 6:
Sebayashi discloses:
wherein the protection parameter is contained in a destination [Internet Protocol version 6 (IPv6)] address of the at least one packet (see para. 127 where legitimate IP packet(s) is/are communicated to a legitimate user associated with a destination IP address).
Sebayashi does not, but Chien discloses:
Internet Protocol version 6 (IPv6) address (see Chien, para. 24, for IPV6 addresses).
It would have been obvious to one having ordinary skill in the art to which the claimed invention pertains, before the effective filing date of the claimed invention, to modify Sebayashi's invention by enhancing it for Internet Protocol version 6 (IPv6) address, as taught by Chien, in order for associating flow control rules with IPV6 addresses (see Chien, para. 24).
9. Claim(s) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sebayashi in view of Waters, JR et al. (US 2014/0373140 A1, hereafter Waters).
Regarding claim(s) 7:
Sebayashi does not, but Waters discloses:
wherein the at least one packet is received through is an Internet Protocol security (IPsec) tunnel or an Internet Protocol (IP) tunnel (see Waters, para. 32, where packet(s) is/are transmitted over a network to an IP address through a tunnel (i.e., IP tunnel)).
It would have been obvious to one having ordinary skill in the art to which the claimed invention pertains, before the effective filing date of the claimed invention, to modify Sebayashi's invention by enhancing it for the flow is an IPsec tunnel or an IP tunnel, as taught by Waters, in order to scrub packets transmitted to an IP address through a tunnel (see Waters, para. 32).
10. Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sebayashi in view of Iqbal et al. (US 12120128 B1).
Regarding claim(s) 9:
Sebayashi discloses:
wherein the message comprising the expected values of the protection parameter is a message [in accordance with a protocol selected from the group consisting of: Border Gateway Protocol (BGP) Flow Spec, Network Configuration Protocol (NETCONF), Representational State Transfer Configuration (RESTCONF), Command line interface (CLI), Simple Network Management Protocol (SNMP), Application Program Interface (API) Representational State Transfer Configuration (REST), and API] (see fig. 1 and para. 129 where a repeater device receives legitimate signature(s) from an adjacent repeater device over a network; see paras. 96, 127 where a legitimate signature includes attributes, e.g., source IP address, destination IP address, protocol, etc. (i.e., expected values of a legitimate signature) indicating characteristics of the legitimate packet).
Sebayashi does not, but Iqbal discloses:
a message in accordance with a protocol selected from the group consisting of: Border Gateway Protocol (BGP) Flow Spec, Network Configuration Protocol (NETCONF), Representational State Transfer Configuration (RESTCONF), Command line interface (CLI), Simple Network Management Protocol (SNMP), Application Program Interface (API) Representational State Transfer Configuration (REST), and API (see Iqbal, col. 1, lines 11-14, where a router uses BGP protocol to send/receive routing information to/from another router).
It would have been obvious to one having ordinary skill in the art to which the claimed invention pertains, before the effective filing date of the claimed invention, to modify Sebayashi's invention by enhancing it for a message in accordance with a protocol selected from the group consisting of: Border Gateway Protocol (BGP) Flow Spec, Network Configuration Protocol (NETCONF), Representational State Transfer Configuration (RESTCONF), Command line interface (CLI), Simple Network Management Protocol (SNMP), Application Program Interface (API) Representational State Transfer Configuration (REST), and API, as taught by Iqbal, in order to enable routing devices to use BGP protocol to exchange routing information (see Iqbal, col. 1, lines 11-13).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUAN V. DOAN whose telephone number is 571-272-3809. The examiner can normally be reached on Monday – Thursday, 9:00am – 5:00pm EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, PHILIP CHEA, can be reached on 571-272-3951. 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.
/HUAN V DOAN/Primary Examiner, Art Unit 2499