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 .
Continued Examination Under 37 CFR 1.114
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. Applicants’ submission filed on 07/06/2026 has been entered.
Response to Arguments
Applicant’s arguments with respect to claim(s) are rejected under 103, have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant argued in the remark that determination a class of service based on an Internet protocol (IP) address and a port number of a destination of the packet”.
Examiner respectfully disagrees. Browne discloses par 0025 the packet classifier 302 may determine a class of service for each packet received. The packet classifier 302 may determine a class of service based on any suitable combination of, e.g., a source IP address, a source port number, a destination IP address, a destination port number, and a protocol in use. Par discloses [0040] In block 406, the compute device 106 classifies the packet. The compute device 106 may determine a class of service for the packet in block 408. The compute device 106 may determine a class of service based on any suitable combination of, e.g., a source IP address, a source port number, a destination IP address, a destination port number, and a protocol in use. The compute device 106 determines whether the packet is a fragment of a datagram in block 410. And 0065] Example 2 includes the subject matter of Example 1, and wherein to determine the first class of service for the first plurality of packets comprises to determine the first class of service for the first plurality of packets based on one or more of, a source IP address, a source port number, a destination IP address, a destination port number, and a protocol in use of at least one packet of the plurality of first packets. [0075] Example 12 includes the subject matter of Example 11, and wherein determining the first class of service for the first plurality of packets comprises determining the first class of service for the first plurality of packets based on one or more of, a source IP address, a source port number, a destination IP address, a destination port number, and a protocol in use of at least one packet of the plurality of first packets. [0085] Example 22 includes the subject matter of Example 21, and wherein to determine the first class of service for the first plurality of packets comprises to determine the first class of service for the first plurality of packets based on one or more of, a source IP address, a source port number, a destination IP address, a destination port number, and a protocol in use of at least one packet of the plurality of first packets. [0095] Example 32 includes the subject matter of Example 31, and wherein the means for determining the first class of service for the first plurality of packets comprises means for determining the first class of service for the first plurality of packets based on one or more of, a source IP address, a source port number, a destination IP address, a destination port number, and a protocol in use of at least one packet of the plurality of first packets.
Applicant argued in the remark that wherein the outer header includes a medium access control(MAC) address of the UE and indicate the class of service corresponding to the packet.
Examiner respectfully disagrees. Suemura discloses generate an outer header based on the class of service (0058] In the EthernetMAC header 11, there are included a transmission source Ethernet MAC address, a destination Ethernet MAC address and the information on the classes of service, referred to below as EthernetCos. In the RPRMAC header 12 ( an outer header fig.2 ) , there are included a transmission source RPRMAC address, a destination RPRMAC address and the information on the class(es) of service, ); the outer header includes a medium access control ( MAC) address of the UE(0058 , in Ethernet, the MAC addresses are part of the Ethernet frame header, which is the “outer” header at the Data Link layer );
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.
Claim(s) 1,2,5-10, 13-14, 16, 17-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Khanna et al US 2008/0092229 in view of Anderson et al US 2008/0165679 in view of Browne et al US 2022/0006884 in view of Suemura et al US 2008/0232385.
As per clam 1. Khanna discloses user equipment (UE), comprising: a memory; at least one processor coupled to the memory and configured to(fig.7, par 0053, network element/ VPN sites and The format of the packet at this point is shown in FIG.2 ):
generate a packet that includes a payload and an inner header (par 0029 an IPSec encrypted IP packet that may be used to transfer data over an IPSec secure tunnel. As shown in FIG. 2, an original IP packet 22 includes the original IP header 24 and the original payload 26. The statement describes how IPsec Tunnel Mode works to create a secure, private connection (a VPN tunnel) over a public network like the internet. Here is a breakdown of what the text means:
"An original IP packet 22 includes the original IP header 24 and the original payload 26": This refers to a standard, unencrypted data packet generated by a device (e.g., a computer on a private network).
The original IP header 24 contains crucial routing information like the source and destination IP addresses.
The original payload 26 is the actual data (e.g., an email, a web page request).
"When the packet is encrypted according to the IPSec standard": The text is referring to the process of applying IPsec security measures, specifically in tunnel mode.
The Process: When IPsec is applied in tunnel mode:
The entire original IP packet (header + payload) is encrypted.
This encrypted original packet becomes the "inner" packet or payload of a new(I.e. generated an encrypted packet ), outer IP packet.
A new, outer IP header is added to this "inner" packet. This new header contains the IP addresses of the security gateways (like VPN routers or firewalls) that form the ends of the secure tunnel, not the final source/destination addresses);
generate an encrypted packet by encrypting the packet (0029, the encryption algorithm will add an Encapsulated Secure Payload (ESP) header 28, wherein the entire IP packet is encapsulated by the ESP header and the encryption algorithm is added to the encapsulated by the ESP header that means the ESP heard is an encrypted packet is being generated by the encryption algorithm);
generate a combined packet based on the encrypted packet and an outer header (fig. 2, 0029 A new, outer IP header is added,.i.e. combined, to this "inner" packet. This new header contains the IP addresses of the security gateways (like VPN routers or firewalls) that form the ends of the secure tunnel, not the final source/destination addresses),
wherein the outer header includes a class of service corresponding to the packet (0053 encrypt the packet, and apply the outer IP header (arrow 11) wherein the outer IP header included Tunnel IP services, i.e. indicates a class of service for the encrypted packet that is being generated by the encryption algorithm from the FIG.2, and " the network element will apply tunnel IP services, encrypt the packet, and apply the outer IP header (arrow 11). "The network element will apply tunnel IP services, i.e. class of service, ": The device initiates the process of creating a secure, virtual link (a tunnel) between itself and another specific network element. This involves setting up security associations and deciding to encapsulate traffic rather than just passing it through normally.
"Encrypt the packet": The network element takes the entire original IP packet (including its original source and destination IP addresses and the user data) and scrambles it using an encryption algorithm (like AES) so that it cannot be read by anyone monitoring the network. The entire original packet becomes the encrypted payload of a new packet.
"And apply the outer IP header": Since the original header is now encrypted and unreadable to intermediate routers, a new IP header is prepended to the encrypted data.
This outer IP header contains the IP addresses of the tunnel endpoints (the two VPN gateways), allowing the packet to be routed correctly across the public internet to the destination gateway.
Once the packet reaches the destination gateway, this outer header is stripped off, the inner packet is decrypted, and the original, secure data is delivered to the final internal destination.
); and
transmit the combined packet to a campus network via a secured tunnel (0029 n IPSec encrypted IP packet that may be used to transfer data over an IPSec secure tunnel and 0053 the network element will apply L2 encapsulation and send, i.e. transmit, the packet to an outbound interface. The outbound interface will apply outbound IP services and forward the packet onto the service provider's IP network (arrow 12) and the service provider IP network is a Wide Area Network (WAN), specifically designed to connect diverse and geographically dispersed networks, including campus networks and PANs, over large distances using telecommunications infrastructure).
Khanna does not disclose Packet outer header indicates a class of service (emphasis added).
However, Anderson discloses Packet outer header indicates a class of service (0024 outer header marked. i.e. indicates, with a priority , class of service, that matches and The marked header indicates to the AGW 312 whether or not the packets were transported over the air using the high priority bearer 304 or low priority bearer 306, i.e. class of service. This may allow the AGW 312 to apply the rules received by the Policy Server 314, and to permit access only to the packets with their outer header marked with a priority, i.e. class of service, that matches that of the filters configured in the AGW 312 by the Policy Server 314. And 0019 The access bearer typically carries traffic of the same generic type or class and 0029 The AGW 312 inspects the different traffic flows and identifies whether the QoS actual priority, i.e. class of service, that is indicated in the outer header 608 matches the expected priority in step 606 provided with the filter by the Policy Server as in step 602)
Khanna and Anderson are both considered to be analogous to the claimed invention because they are in the same field of tunneling the packet.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Khanna to incorporate the teachings of Anderson and provide priority flows at a centralized point in a network. Doing so would provide transmission prioritization level, thereby to prevent fraudulent access (par 0004).
The combination fails to disclose
determine a class of service based on an Internet protocol (IP) address and a port number of destination of the packet;
generate an outer header based on the class of service;
the outer header includes a medium access control ( MAC) address of the UE.
However, Browne discloses determine a class of service based on an Internet protocol (IP) address and a port number of destination of the packet (0025 the packet classifier 302 may determine a class of service for each packet received. The packet classifier 302 may determine a class of service based on any suitable combination of, e.g., a source IP address, a source port number, a destination IP address, a destination port number, and a protocol in use, the any suitable combination can be any IP addresses and any port numbers );
Khanna and Anderson and Browne are both considered to be analogous to the claimed invention because they are in the same field of tunneling the packet.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Khanna to incorporate the teachings of Anderson and the teaching of Browne and provide priority flows at a centralized point in a network. Doing so would provide transmission prioritization level, thereby preventing fraudulent access (par 0004).
The combination does not explicitly disclose generate an outer header based on the class of service; the outer header includes a medium access control ( MAC) address of the UE.
However, Suemura discloses generate an outer header based on the class of service (0058] In the EthernetMAC header 11, there are included a transmission source Ethernet MAC address, a destination Ethernet MAC address and the information on the classes of service, referred to below as EthernetCos. In the RPRMAC header 12 ( an outer header fig.2 ) , there are included a transmission source RPRMAC address, a destination RPRMAC address and the information on the class(es) of service, ); the outer header includes a medium access control ( MAC) address of the UE(0058 , in Ethernet, the MAC addresses are part of the Ethernet frame header, which is the “outer” header at the Data Link layer );
Khanna and Anderson and Browne and Suemura are both considered to be analogous to the claimed invention because they are in the same field of tunneling the packet. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Khanna to incorporate the teachings of Anderson and the teaching of Browne, and teaching of Suemura and provide priority flows at a centralized point in a network. Doing so would provide transmission prioritization level, thereby preventing fraudulent access (par 0004).
As per claim 2. Khanna and Anderson and Browne and Suemura disclose the UE of claim 1, Khanna discloses wherein the outer header further indicates permission to access the campus network (0053 the network element will apply L2 encapsulation and send, i.e. transmit, the packet to an outbound interface. The outbound interface will apply outbound IP services and forward the packet onto the service provider's IP network (arrow 12) and the service provider IP network is a Wide Area Network (WAN), specifically designed to connect diverse and geographically dispersed networks, including campus networks and PANs, over large distances using telecommunications infrastructure).
As per claim 5. Khanna and Anderson and Browne and Suemura disclose The UE of claim 1, Khanna discloses wherein the secured tunnel is an Internet protocol security (IPSEC) tunnel or a wireguard tunnel( 0012 CE-based VPN is to create Internet Protocol Security (IPSec) tunnels through the communication network).
As per claim 6. Khanna and Anderson and Browne and Suemura disclose The UE of claim 1, Khanna discloses wherein the outer header is an Internet protocol differentiated services code point (IP DSCP) header (0053 apply tunnel IP services, encrypt the packet, and apply the outer IP header (arrow 11). And 0056 apply tunnel IP services, encrypt the packet, and apply the outer IP header (arrow 11)).
As per claim 7. Khanna and Anderson and Fuang disclose The UE of claim 1, Khanna discloses wherein the inner header is a transmission control protocol/Internet protocol (TCP/IP) header ( [0008] A Provider Edge (PE) node is a router which connects to one or more CE devices using a dynamic routing protocol to exchange CE reachability information. The PE connects with at least one other PE or P node. When handling Internet Protocol (IP) MultiProtocol Label Switched (MPLS) traffic [0029] FIG. 2 shows an IPSec encrypted IP packet that may be used to transfer data over an IPSec secure tunnel. As shown in FIG. 2, an original IP packet 22 includes the original IP header 24 and the original payload 26. When the packet is encrypted according to the IPSec standard, the encryption algorithm will add an Encapsulated Secure Payload (ESP) header 28, an ESP trailer 30, and an ESP authentication field 32. The new packet will also be provided with a new outer IP header 34 ).
As per claim 8. Khanna and Anderson and Browne and Suemura disclose The UE of claim 1, Khanna discloses wherein the at least one processor is further configured to:
connect to the campus network (0029 n IPSec encrypted IP packet that may be used to transfer data over an IPSec secure tunnel and 0053 the network element will apply L2 encapsulation and send, i.e. transmit, the packet to an outbound interface. The outbound interface will apply outbound IP services and forward the packet onto the service provider's IP network (arrow 12) and the service provider IP network is a Wide Area Network (WAN), specifically designed to connect diverse and geographically dispersed networks, including campus networks and PANs, over large distances using telecommunications infrastructure ); and in response to connecting to the campus network, generate the combined packet (fig. 2, 0029 A new, outer IP header is added,.i.e. combined, to this "inner" packet. This new header contains the IP addresses of the security gateways (like VPN routers or firewalls) that form the ends of the secure tunnel, not the final source/destination addresses).
As per claims 9,17, those are rejected based on the same rational set forth in claim 1 respectively.
As per claims 16 and 20, those are rejected based on the same rational set forth in claim 8.
As per claims 10,18, those are rejected based on the same rational set forth in claim 2.
As per claim 13, this is rejected based on the same rational set forth in claim 5.
As per claim 14, this is rejected based on the same rational set forth in claim 6.
Claim(s) 22 is rejected under 35 U.S.C. 103 as being unpatentable over Khanna and Anderson in view of Browne and Suemura in view of Ahmed et al US 2025/0039074.
As per claim 22. Khanna and Anderson and Browne and Suemura disclose The non-transitory CRM of claim 17, the combination does not explicitly discloses wherein the secured tunnel is an Internet protocol security (IPSEC) tunnel or a wireguard tunnel.
Ahmed discloses wherein the secured tunnel is an Internet protocol security (IPSEC) tunnel or a wireguard tunnel( [0129] The tunnels may be secure tunnels. For example, the tunnels may be Internet Protocol Security, IPSec tunnels. Alternatively, the tunnels may be: Generic Routing Encapsulation, GRE, tunnels; OpenVPN tunnels; Secure Socket Tunneling Protocol, SSTP, tunnels; Layer 2 Tunneling Protocol, L2TP, tunnels; Virtual Extensible Local Area Network, VXLAN, tunnels or WireGuard tunnels.).
Khanna and Anderson and Browne and Suemura and Ahmed are both considered to be analogous to the claimed invention because they are in the same field of tunneling the packet. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Khanna to incorporate the teachings of Anderson and the teaching of Browne, and teaching of Suemura and teaching of Ahmed and provide priority flows at a centralized point in a network. Doing so would provide transmission prioritization level, thereby to prevent fraudulent access (par 0004).
Claim(s) 23 is rejected under 35 U.S.C. 103 as being unpatentable over Khanna and Anderson in view of Browne and Suemura in view of Ravindran et al US 2006/0245363.
As per claim 23. Khanna and Anderson and Browne and Suemura disclose The non-transitory CRM of claim 17, the combination fails to discloses wherein the outer header is an Internet protocol differentiated services code point (IP DSCP) header.
However, Ravindran discloses wherein the outer header is an Internet protocol differentiated services code point (IP DSCP) header ( [0006] IP traffic of a communications session through a tunnel retains its original IP header, while an outer IP header is attached and detached at tunnel endpoints. In general, the intermediate nodes between the tunnel endpoints operate solely on the outer IP header, and hence the per-hop-behavior (PHB) of the tunnel is determined by the contents of the Differentiated Services Code Point (DSCP) field of the outer IP header. The contents of this field is normally negotiated as part of the tunnel set-up procedure, typically by copying the DSCP field contents of the inner IP header. Once the DSCP field content of the outer IP header has been negotiated, it remains fixed for the life of the tunnel. In this manner, some Quality of Service ("QoS") guarantees are provided by classifying traffic into various classes and employing differentiated packet dropping schemes to achieve the target packet loss. However, these DSCP mechanisms (also, referred to as DiffServ mechanisms) are generally ignorant about any topology changes.).
Khanna and Anderson and Browne and Suemura and Ravindran are both considered to be analogous to the claimed invention because they are in the same field of tunneling the packet. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Khanna to incorporate the teachings of Anderson and the teaching of Browne, and teaching of Suemura and teaching of Ravindran and providing priority flows at a centralized point in a network. Doing so would provide transmission prioritization level, thereby preventing fraudulent access (par 0004).
Claim(s) 3,11 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Khanna and Anderson and Browne and Suemura and Bernardi US 2023/0216947.
As per claim 3. Khanna and Anderson and Browne and Suemura disclose the UE of claim 1, the combination fails to disclose wherein the campus network is a zero-trust network access (ZTNA) network (emphasis added).
However, Bernardi discloses wherein the campus network is a zero-trust network access (ZTNA) network([1254] FIG. 114 is a flowchart illustrating a non-limiting preferred embodiment of the Zero Trust Network Comparison with Real-Time Communications (RTC) Zero Trust Network Architecture (ZTNA) Approach. FIG. 114 shows Employees Partners, Things, Devices connecting to Campus connected to WAN connected to DC connected to CAP connected to Commercial Cloud, AWS, MS Network and CAP connected to IT, SaaS. WAN also connected to Security Stack connected to Network connected to Web/Internet).
Khanna and Anderson and Browne and Suemura are both considered to be analogous to the claimed invention because they are in the same field of tunneling the packet. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Khanna to incorporate the teachings of Anderson and the teaching of Browne, and teaching of Suemura including the teaching of Bernardi and providing the outer IP header includes a differentiated services code point (DSCP) value. Doing so would provide different services of communication, thereby to improve the service availability.
As per claim 11, this claim is rejected based on the same rational set forth in claim 3.
As per claim 21, this claim is rejected based on the same rational set forth in claim 3.
Claim(s) 15 is rejected under 35 U.S.C. 103 as being unpatentable over Khanna et al US 2008/0092229 in view of Anderson et al US 2008/0165679 in view of Browne et al US 2022/0006884 in view of Suemura et al US 2008/0232385 and Bendickson et al US 10,986076.
As per claim 15, Khanna in view of Anderson in view of Browne in view of Suemura discloses, the method of claim 9, the combination does not explicitly disclose wherein the inner header is a transmission control protocol/ Internet protocol (TCP/IP) header.
However, Bendickson discloses wherein the inner header is a transmission control protocol/ Internet protocol (TCP/IP) header (col 3-4, lines 64-67 and lines 1-10 respectively For example, the trusted nodes 102-108 and untrusted nodes 110-114 may both regulate the transmission of messages 120 through the Internet (122) and to, from, and within local networks 116. Each message 120 may include an unencrypted outer header 124, an encrypted inner header 126 (e.g., system-level header (SLH)), and a data payload 128 (e.g., data packet/target address). For example, the inner header 126 and data payload 128 may reside inside standard TCP/IP and may be separately encrypted according to separate standards or cryptographic protocols. The data payload 128 may be separately encrypted and only decryptable by a trusted recipient, e.g., to protect the data payload from header evaluation machinery. In some embodiments, portions of the data payload 128 (e.g., apart from the target source and destination addresses) may be further encrypted for security reasons.).
Khanna and Anderson and Browne and Suemura and Bendickson are both considered to be analogous to the claimed invention because they are in the same field of tunneling the packet. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Khanna to incorporate the teachings of Anderson and the teaching of Browne, and teaching of Suemura including the teaching of Bendickson and providing the outer IP header includes a differentiated services code point (DSCP) value. Doing so would provide different service of communication, thereby to improve the service availability.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABU S SHOLEMAN whose telephone number is (571)270-7314. The examiner can normally be reached EST: 9am-5pm.
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, JORGE ORTIZ CRIADO can be reached at 571-272-7624. 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.
/ABU S SHOLEMAN/Primary Examiner, Art Unit 2496
Prosecution Insights