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 .
DETAILED ACTION
Continued Examination Under 37 CFR 1.114
A request for continued examination (RCE) under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed on 02/17/2026 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 01/20/2026 has been entered.
DETAILED ACTION
As per instant Amendment, Claims 1, 8, 10 and 19 have been amended; claims 7 and 15 has been cancelled. Claims 1 and 19 are independent claims. Claims 1, 8-11 and 16-19 are pending. This Action is made Non-FINAL.
Response to Arguments
Applicants’ arguments in the instant Amendment, filed on 02/17/2026, with respect to limitations listed below, have been fully considered but they are not persuasive.
Applicant’s arguments: The combination of Nilsson and Han fails to teach or suggest a DL packet that is an IPv4 packet having a protocol identifier set to UDP, or a DL packet that is an IPv6 packet having a last next header set to UDP, as part of the DL packet characteristics on which the derivation of a reflective Quality of Service (QoS) rule for an Internet Protocol Security (IPSec) Security Association (SA) is based, as now recited in amended claims 1 and 19.
The Examiner disagrees with the Applicants. The Examiner respectfully submits that the combination of Nilsson and Han does disclose that a DL packet that is an IPv4 packet having a protocol identifier set to UDP, or a DL packet that is an IPv6 packet having a last next header set to UDP, as part of the DL packet characteristics on which the derivation of a reflective Quality of Service (QoS) rule for an Internet Protocol Security (IPSec) Security Association (SA) is based. As seen in paragraphs 0005-0006, 0025, 0036; 0042 and 0056-0060 of Nilsson. Nilsson teaches that the Packet Filter Set for UL data packets in the derived QoS rule is derived by the wireless device based on the received DL data packet, for example, the source IP address and port number of the DL data packet is used as the destination IP address and port number of the UL data packet, and vice versa. For a IP PDU session type, the Packet Filter Set supports UL packet filtering based on at least any combination of: a source and/or destination IP address or IPv6 prefix; a source and/or destination port number; a Protocol ID of the protocol above IP/Next header type; a Type of Service (TOS) (IPv4)/Traffic class (IPv6) and Mask; a Flow Label (IPv6), and a Security Parameter Index, SPI. The wireless device may receive a DL data packet and based on that DL data packet create or derive a QoS rule in the wireless device that is based on the values of the actual fields of the control information in the DL data packet, such as, for example, in the IPv4/v6, IPsec ESP, AH and TCP/UDP headers of the DL data packet. It is preferred that the control information indicates at least one first reflective parameter of a certain category, which parameter is intended to be reflected (i.e. copied, i.e. mirrored) into Uplink, UL, data packets of the bi-directional communications flow (130). In some embodiments, the control information or said first reflective parameter in the DL data packet may further indicate any one of: a source/destination IP address; an IPv6 prefix; a source/destination port number; a transport protocol identity; and a Security Parameter Index, SPI. The wireless device may receive a DL data packet and based on that DL data packet create or derive a QoS rule in the wireless device that is based on the values of the actual fields of the control information in the DL data packet, such as, for example, in the IPv4/v6, IPsec ESP, AH and TCP/UDP headers of the DL data packet. The Security Parameter Index, SPI, of a DL data packet of the IPsec protected communication will be used by the wireless device to create the Packet Filter Set upon deriving the QoS rule. IPsec consist of two different protocols that define its SPI, Encapsulated Security Payload, ESP, and Authentication Header, AH. For ESP, the SPI is defined in RFC 4303, section 2.1, as: “The SPI is an arbitrary 32-bit value that is used by a receiver to identify the Security Association (SA) to which an incoming packet is bound. The SPI field is mandatory. For a unicast SA, the SPI can be used by itself to specify an SA, or it may be used in conjunction with the IPsec protocol type (in this case ESP). This means that a wireless device receiving an ESP/AH data packet with a unicast SA in the DL direction will use the SPI to identify the Security Association (SA) that the received ESP/AH data packet belongs to. Further As seen in paragraph 0123 of Han. Han teaches that a reflective QoS mechanism is introduced to a 5G system, and is a method for obtaining an uplink data transmission QoS rule by a terminal device. A basic idea of the mechanism is that the terminal device derives the uplink data transmission QoS rule based on a downlink data packet. Therefore, the combination of Nilsson and Han does teach or suggest (i) that the DL packet has ESP/UDP/IP encapsulation or ESP/IP encapsulation, and (ii) that deriving the reflective QoS rule includes, when a UL IPsec security association (SA) corresponding to a DL IPsec SA identified by a Security Parameter Index (SPI) in the DL packet uses ESP/UDP/IP encapsulation: deriving a packet filter for UL IPsec-protected packets with ESP/UDP/IP encapsulation based on the SPI associated with the UL IPsec SA and does address IPsec SAs, NAT-T, or the claimed encapsulation-conditioned packet-filter derivation.
Applicant’s arguments: As described in Applicant's specification, current 3GPP standards (e.g., TS 23.501) do not address derivation of rules when IPSec traffic is UDP-encapsulated (Options 1-3). Therefore, because the cited art fails to recognize this technical gap, there is no motivation or rationale to derive a filter containing the claimed SPI type component based on a DL packet wherein an IPv4 protocol identifier or an IPv6 last next header being set to UDP.
In response to applicant's argument that the references fail to show certain features of applicant’s invention, it is noted that the features upon which applicant relies (i.e., current 3GPP standards (e.g., TS 23.501) do not address derivation of rules when IPSec traffic is UDP-encapsulated) are not recited in the rejected claim. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Independent claim 19 is directed to a device respectively that perform a method at least similar to that disclosed in claim1 and claims 8- 11 and 16-18 depend from claims 1 and 19. Thus Applicants’ arguments with respect to claims 1, 8-11 and 16-19, have been fully considered but they are not persuasive for at least the reasons explained above with respect to claim 1.
Thus, the amended limitations are still obvious over the prior art of record. Please see amended rejection below for the amended rejection.
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 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 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.
Claims 1, 8-11 and 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over Nilsson (US 2020/0404533) and in view of Han (US 2020/0120538).
Regarding claim 1, Nilsson discloses a method in a terminal device (Nilsson fig. 1; The wireless device 121), comprising:
receiving a downlink (DL), packet, the DL packet being Internet Protocol Security (IPSec) protected (Nilsson par. 0054, fig. 3; The wireless device 121 then receive a DL data packet (ESP/AH) with a DL SPI of a IPsec protected communication. See also par. 0050); and
deriving a reflective Quality of Service (QoS) rule for uplink (UL) direction per IPSec Security Association (SA) (Nilsson par. 0056-0060; After receiving the DL data packet in Action 302, the wireless device 121 may determine whether or not to create new reflective QoS rule, or rather a new Packet Filter Set of a reflective QoS rule for corresponding UL data packets of the IPsec communication. If there already exist a reflective QoS rule corresponding to the DL data packet, then there is no reason for the wireless device 121 to create a new reflective QoS rule. if no reflective QoS rule corresponding to the DL data packet exist, the wireless device 121 may proceed to querying a local database in the wireless device 121 according to Action 304. The wireless device 121 may then use the fact that the bi-directional communication is an IPsec protected communication and control information comprised in the DL data packet, such as, e.g. the DL SPI, in order to obtain a UL SPI for the UL data packets of the IPsec protected communication. After retrieving the UL SPI, the wireless device 121 derive a Packet Filter Set of a new reflective QoS rule for the IPsec protected communication based on the UL SPI);
wherein the DL packet has Encapsulating Security Payload (ESP) / User Datagram Protocol (UDP) / Internet Protocol (IP) encapsulation or ESP / IP encapsulation (Nilsson par. 0006 and 0025; The wireless device receive a DL data packet and based on that DL data packet create or derive a QoS rule in the wireless device that is based on the values of the actual fields of the control information in the DL data packet, such as, for example, in the IPv4/v6, IPsec ESP, AH and TCP/UDP headers of the DL data packet. One case is when the bi-directional communications flow is a IPsec protected communication. This because the Security Parameter Index, SPI, of a DL data packet of the IPsec protected communication will be used by the wireless device to create the Packet Filter Set upon deriving the QoS rule. IPsec consist of two different protocols that define its SPI, Encapsulated Security Payload, ESP, and Authentication Header, AH. See also par. 0054);
wherein the DL packet is an IP version 4 (IPv4) packet having a protocol identifier set to UDP, or the DL packet is an IP version 6 (IPv6) packet having a last next header set to UDP (0005-0006 and 0036; The Packet Filter Set for UL data packets in the derived QoS rule is derived by the wireless device based on the received DL data packet, for example, the source IP address and port number of the DL data packet is used as the destination IP address and port number of the UL data packet, and vice versa. For a IP PDU session type, the Packet Filter Set supports UL packet filtering based on at least any combination of: a source and/or destination IP address or IPv6 prefix; a source and/or destination port number; a Protocol ID of the protocol above IP/Next header type; a Type of Service (TOS) (IPv4)/Traffic class (IPv6) and Mask; a Flow Label (IPv6), and a Security Parameter Index, SPI. The wireless device may receive a DL data packet and based on that DL data packet create or derive a QoS rule in the wireless device that is based on the values of the actual fields of the control information in the DL data packet, such as, for example, in the IPv4/v6, IPsec ESP, AH and TCP/UDP headers of the DL data packet. It is preferred that the control information indicates at least one first reflective parameter of a certain category, which parameter is intended to be reflected (i.e. copied, i.e. mirrored) into Uplink, UL, data packets of the bi-directional communications flow (130). In some embodiments, the control information or said first reflective parameter in the DL data packet may further indicate any one of: a source/destination IP address; an IPv6 prefix; a source/destination port number; a transport protocol identity; and a Security Parameter Index, SPI); and
wherein deriving the reflective QoS rule includes, when a UL IPsec SA corresponding to a DL IPSec SA associated with a Security Parameter Index (SPI) in the DL packet uses ESP/UDP/IP encapsulation: deriving a packet filter for UL IPSec protected packets with ESP/UDP/IP encapsulation based on an SPI associated with the UL IPSec SA (Nilsson par. 0006 and 0025; The wireless device may receive a DL data packet and based on that DL data packet create or derive a QoS rule in the wireless device that is based on the values of the actual fields of the control information in the DL data packet, such as, for example, in the IPv4/v6, IPsec ESP, AH and TCP/UDP headers of the DL data packet. This means that a wireless device receiving an ESP/AH data packet with a unicast SA in the DL direction will use the SPI to identify the Security Association (SA) that the received ESP/AH data packet belongs to. However, it also means that it is the wireless device that will generate the SPI for the ESP/AH data packet with a unicast SA in the UL direction. This further explained in IKE RFC 7296 as: “ESP and AH SAs always exist in pairs, with one SA in each direction.” This means that a bi-directional communications flow that is a IPsec protected communication must use two SAs, one for each direction. Since it is the wireless device that determine what SPI is used for a SA, it will typically mean that different SPI values will used for each direction. For reflective QoS, this means that the SPI field in the Packet Filter Set will be wrong, since it will copy the SPI value from the DL data packet. See also par. 0086), wherein the packet filter contains an SPI type component set to the SPI associated with the UL IPSec SA (Nilsson par. 0042; In some embodiments, in case the type of bi-directional communications flow 130 is an IPsec protected communication, the control information to be comprised in the UL data packet that is at least partly different from the information comprised in the DL data packet is a Security Parameter Index, SPI. This means that the wireless device 121 is able to create a new UE derived QoS rule, i.e. the second reflective QoS rule, with a packet filter set indicating the correct SPI for the IPsec SA used in the uplink direction based on a received DL data packet comprising an SPI for a IPsec SA in the downlink direction).
Nilsson discloses the wireless device then use the fact that the bi-directional communication is an IPsec protected communication and control information comprised in the DL data packet, such as, e.g. the DL SPI, in order to obtain a UL SPI for the UL data packets of the IPsec protected communication. After retrieving the UL SPI, the wireless device 121 may derive a Packet Filter Set of a new reflective QoS rule for the IPsec protected communication based on the UL SPI (Nilsson par. 0058-0060). However, Nilsson does not explicitly disclose deriving a reflective Quality of Service (QoS) rule based on the DL packet.
However, in an analogous field, Han discloses deriving a reflective Quality of Service (QoS) rule based on the DL packet (Han par. 0123; A reflective QoS mechanism is introduced to a 5G system, and is a method for obtaining an uplink data transmission QoS rule by a terminal device. A basic idea of the mechanism is that the terminal device derives the uplink data transmission QoS rule based on a downlink data packet).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the deriving a reflective Quality of Service, QoS, rule of Nilsson using the deriving a reflective Quality of Service, QoS, rule taught in Han in order implement QoS control to a communication method and an access network device (Han abstract and par. 0002).
Regarding claim 8, Nilsson and Han disclose the method of claim 1,
Nilsson further discloses wherein the packet filter for UL IPSec protected packets with ESP/UDP/IP encapsulation further contains:
a single local port type component set to a value of a source port field of the UL IPsec SA, and a single remote port type component set to a value of a destination port field of the UL IPsec SA (Nilsson par.0044; According to some embodiments, the wireless device 121 may decrypt the IPsec protected DL data packet of the IPsec protected communication in order to obtain the SPI comprised in the DL data packet. The decryption may be performed in order to first determine some control information of the encrypted downlink IPsec data packet, such as, the local IP address, local port, protocol, remote IP address, remote port of the encrypted downlink IPsec data packet, and then by querying the SPD, determine the SPI value to associated with uplink IP data packets of the protocol sent from local IP address and local port towards the remote IP address and remote port and set this SPI value as the uplink SPI value in the Packet Filter Set of the second reflective QoS rule).
Regarding claim 9, Nilsson and Han disclose the method of claim 8,
Nilsson further discloses wherein the packet filter for UL IPSec protected packets with ESP/UDP/IP encapsulation further contains: an IP remote address component set to a value of a source address field of the DL packet, an IP local address component set to a value of a destination address field of the DL packet, and a protocol identifier or next header type component set to a value of UDP (Nilsson par. 0005; The Packet Filter Set for UL data packets in the derived QoS rule is derived by the wireless device based on the received DL data packet, for example, the source IP address and port number of the DL data packet is used as the destination IP address and port number of the UL data packet, and vice versa. For a IP PDU session type, the Packet Filter Set supports UL packet filtering based on at least any combination of: a source and/or destination IP address or IPv6 prefix; a source and/or destination port number; a Protocol ID of the protocol above IP/Next header type; a Type of Service (TOS) (IPv4)/Traffic class (IPv6) and Mask; a Flow Label (IPv6), and a Security Parameter Index, SPI. The QFI for the UL data packet filtered by the derived QoS rule is set to the same QFI as received in the DL packet. When reflective QoS is activated, the precedence value for all derived QoS rules is set to a standardised value).
Regarding claim 10, Nilsson and Han disclose the method of claim 1,
Nilsson further discloses wherein, when the DL packet has ESP/UDP/IP encapsulation, the packet filter for UL IPSec protected packets with ESP/UDP/IP encapsulation further contains: a single local port type component set to a value of a destination port field of the DL packet, and a single remote port type component set to a value of a source port field of the DL packet (Nilsson Par. 0065; The wireless device 121 may then receive a DL data packet of the bi-directional communications flow, e.g. a IMS voice flow. The DL data packet may indicate that reflective QoS is to be applied, for example, by comprising a RQI and/or a CQI indicator or information).
Regarding claim 11, Nilsson and Han disclose the method of claim 10,
Nilsson further discloses wherein the packet filter for UL IPSec protected packets with ESP/UDP/IP encapsulation further contains: an IP remote address component set to a value of a source address field of the DL packet, an IP local address component set to a value of a destination address field of the DL packet, and a protocol identifier or next header type component set to a value of a protocol identifier field or a last next header field of the DL packet (Nilsson par. 0005; The Packet Filter Set for UL data packets in the derived QoS rule is derived by the wireless device based on the received DL data packet, for example, the source IP address and port number of the DL data packet is used as the destination IP address and port number of the UL data packet, and vice versa. For a IP PDU session type, the Packet Filter Set supports UL packet filtering based on at least any combination of: a source and/or destination IP address or IPv6 prefix; a source and/or destination port number; a Protocol ID of the protocol above IP/Next header type; a Type of Service (TOS) (IPv4)/Traffic class (IPv6) and Mask; a Flow Label (IPv6), and a Security Parameter Index, SPI. The QFI for the UL data packet filtered by the derived QoS rule is set to the same QFI as received in the DL packet. When reflective QoS is activated, the precedence value for all derived QoS rules is set to a standardised value).
Regarding claim 15, Nilsson and Han disclose the method of claim 1,
Regarding claim 16, Nilsson and Han disclose the method of claim 1,
Nilsson further discloses wherein the DL packet contains a Reflective QoS Indicator, RQI, set to 1 (Nilsson par. 0065; The wireless device 121 may then receive a DL data packet of the bi-directional communications flow, e.g. a IMS voice flow. The DL data packet may indicate that reflective QoS is to be applied, for example, by comprising a RQI and/or a CQI indicator or information).
Regarding claim 17, Nilsson and Han disclose the method of claim 1,
Nilsson further discloses further comprising, for a UL packet that is IPSec protected and has ESP/UDP/IP encapsulation: when a reflective QoS rule for UL direction has IP header components matching IP header components of the UL packet and an SPI component matching an SPI component of the UL packet, associating the UL packet with the reflective QoS rule for UL direction, or when no reflective QoS rule for UL direction has IP header components matching the IP header components of the UL packet and an SPI component matching the SPI component of the UL packet, associating the UL packet with a reflective QoS rule for UL direction that has IP header components matching the IP header components of the UL packet and has no SPI component (Nilsson par. 0056-0060; After receiving the DL data packet in Action 302, the wireless device 121 may determine whether or not to create new reflective QoS rule, or rather a new Packet Filter Set of a reflective QoS rule for corresponding UL data packets of the IPsec communication. If there already exist a reflective QoS rule corresponding to the DL data packet, then there is no reason for the wireless device 121 to create a new reflective QoS rule. if no reflective QoS rule corresponding to the DL data packet exist, the wireless device 121 may proceed to querying a local database in the wireless device 121 according to Action 304. The wireless device 121 may then use the fact that the bi-directional communication is an IPsec protected communication and control information comprised in the DL data packet, such as, e.g. the DL SPI, in order to obtain a UL SPI for the UL data packets of the IPsec protected communication. After retrieving the UL SPI, the wireless device 121 derive a Packet Filter Set of a new reflective QoS rule for the IPsec protected communication based on the UL SPI).
Regarding claim 18, Nilsson and Han disclose the method of claim 1,
Nilsson further discloses further comprising, for a UL packet that is Internet Key Exchange, IKE, protected and has ESP/UDP/IP encapsulation: associating the UL packet with a reflective QoS rule for UL direction that has IP header components matching IP header components of the UL packet and has no SPI component (Nilsson par. 0025; “The SPI is an arbitrary 32-bit value that is used by a receiver to identify the Security Association (SA) to which an incoming packet is bound. For a unicast SA, the SPI can be used by itself to specify an SA, or it may be used in conjunction with the IPsec protocol type (in this case AH). Because for unicast SAs the SPI value is generated by the receiver, whether the value is sufficient to identify an SA by itself or whether it must be used in conjunction with the IPsec protocol value is a local matter.” This means that a wireless device receiving an ESP/AH data packet with a unicast SA in the DL direction will use the SPI to identify the Security Association (SA) that the received ESP/AH data packet belongs to. However, it also means that it is the wireless device that will generate the SPI for the ESP/AH data packet with a unicast SA in the UL direction. This further explained in IKE RFC 7296 as: “ESP and AH SAs always exist in pairs, with one SA in each direction.” This means that a bi-directional communications flow that is a IPsec protected communication must use two SAs, one for each direction. Since it is the wireless device that determine what SPI is used for a SA, it will typically mean that different SPI values will used for each direction. For reflective QoS, this means that the SPI field in the Packet Filter Set will be wrong, since it will copy the SPI value from the DL data packet).
Regarding claim 19; claim 19 is directed to a system associated with the method claimed in claim 1. Claim 19 similar in scope to claim 1, and is therefore rejected under similar rationale respectively.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SANCHIT K SARKER whose telephone number is (571)270-7907. The examiner can normally be reached M-F 8:30 AM-5:30 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, FARID HOMAYOUNMEHR can be reached at 571-272-3739. 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.
/SANCHIT K SARKER/Primary Examiner, Art Unit 2495