DETAILED ACTION
This action is in response to communication filed on 8/19/2025
Claims 1-20 are pending.
Claims 1, 11, and 20 have been amended.
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 .
Response to Arguments
Applicant's arguments filed 8/19/2025 have been fully considered but they are not persuasive.
In the communication filed, applicant argues in substance that:
Song does not anticipate the limitation “determining a first path or a second path as a target path by querying a correspondence relationship between network addresses and target paths of resources, wherein the first path is a path passing through a physical network interface card, and the second path is directed to a predetermined secure tunnel” because Song does not teach or suggest that the tunnel selector determines whether to transmit traffic through a secure tunnel to a remote server based on a target network address and a target path of any resource as cited in remarks, pg. 12.
In response to argument [a], Examiners respectfully disagrees.
The above limitation above is interpreted as the system looks up (queries) a stored association (correspondence relationship) to select either:
A “first path” (direct, unsecured via physical NIC, e.g., for low-risk resources).
A “second path” (secure tunnel, e.g., VPN-like for protected resources).
This mapping ensures packets are routed appropriately based on the resource’s security requirements, preventing unauthorized access or leaks.
Song teaches split network tunneling based on traffic inspection, where a network client inspects packets, queries policies based on addresses, and determines paths (direct via physical interface or secure tunnel). Under BRI, Song anticipates this limitation under 35 U.S.C. § 102, as its “dynamic policies” and “network security polices” serve as the “correspondence relationship” queried to map addresses/resource s to paths.
Song’s network client (e.g., module in FIG. 1) acquires packets with target addresses (e.g., domain/IPs) and inspects them. The inspection module queries “network security policies 120” and “dynamic policies” which outline rules for data access, web browsing, etc., to determine the path based on the target address/resource. If the resource is protected, (e.g., corporate owed), it routes via secure tunnel (second path); otherwise, direct transmission (first path via device’s physical interface). This query uses the policies as a mapping between addresses/resources and paths (see Song; [0033, 0035]; “based at least in part on the parsed data and one or more dynamic policies, the inspection component of the network client may determine to block the traffic from transmission, send the traffic directly to a destination host, and/or send the traffic through a secure tunnel connection to a remote server” teaches querying policies to select path based on address-parsed data and “the inspection component of the network client may, based at least in part on one or more dynamic policies, determine to transmit the traffic over a secure tunnel to a remote corporate server associated with the corporate-owned resource” teaches explicit query of policies for address/resource to choose secure tunnel path).
Song’s “dynamic policies” and “network security policies 120” functions as the “correspondence relationship” to target paths (direct to host via physical interface or secure tunnel). The query occurs during inspection, where the address/resource is checked against policies to select the path. The function of the inspection is a specific lookup for routing, as policies dictate path based on resource type/address (e.g., if corporate resource, then use tunnel). Therefore, Song’s policy based routing teaches the limitation as it achieves the same select tunneling for security.
Song does not anticipate the limitation “determining access permission for a target resource corresponding to the target network address” because Song’s permission-related judgement depend solely on dynamic inspection of traffic content without any consideration of the target network address of the data packet as cited in remarks, pg. 13.
In response to argument [b], Examiners respectfully disagrees.
The limitation above is interpreted as evaluating whether access to the resource at the target address is allowed or denied.
Song teaches a system for split network tunneling based on traffic inspection, where a network client evaluates packet destination to decide access (allow/block) as part of security actions. During inspection, Song’s network client (e.g., inspection module 108 in FIG. 1) extracts domain names or address from packets and determines a “reputation” (a score of status indicating trustworthiness), which servers as the access permission evaluation. If reputation is positive (allowed), access proceeds (direct or tunneled); if reputation is negative (denied), block access (see Song; [0034]; retrieve reputation data associated with the domain name. Based on the reputation data retrieved, the network client may determine to block or allow access to that domain).
Song’s “reputation” determination is equivalent to “access permission” under BRI, as it evaluates whether the resource (domain/host at the address) is safe/allowed for access, resulting in allow (transmit) or deny (block/discard). This mirrors Wang’s security-focused evaluation, occurring after packet acquisition and during categorization for path/security actions (direct vs. tunnel vs. block). Therefore, Song’s “reputation” checks as a common permission mechanism in network security, directly teaching the limitation.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 9/17/2025 and 9/23/2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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.
Claims 1-3, 5-6, 8-13, 15-16, and 18-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Song et al. (US 2019/0372937).
Regarding claim 1, Song discloses a network data packet processing method, comprising:
acquiring a network data packet from a first process, the network data packet having a target network address (see Song; [0053, 0054]; at step 304, one or more of the systems described herein provide a network client that may perform an inspection of the network traffic. For example, receiving module 104 may, as part of system 200 in FIG. 2, transmit the network traffic to parser module 106. Parser module 106 may include multiple different parsers. The inspection module 108 may extract a domain name from the parsed data);
determining a first path or a second path by querying a correspondence relationship between network addresses and target paths of resources, wherein the first path is a path passing through a physical network interface card, and the second path is directed to a predetermined secure tunnel (see Song; [0033, 0035]; “based at least in part on the parsed data and one or more dynamic policies, the inspection component of the network client may determine to block the traffic from transmission, send the traffic directly to a destination host, and/or send the traffic through a secure tunnel connection to a remote server” teaches querying policies to select path based on address-parsed data and “the inspection component of the network client may, based at least in part on one or more dynamic policies, determine to transmit the traffic over a secure tunnel to a remote corporate server associated with the corporate-owned resource” teaches explicit query of policies for address/resource to choose secure tunnel path);
determining an access permission for a target resource corresponding to the target network address (see Song; [0034]; retrieve reputation data associated with the domain name. Based on the reputation data retrieved, the network client may determine to block or allow access to that domain); and
processing the network data packet according to the target path and the access permission (see Song; [0056]; the network client that may perform security action to protect the computing device from computer malware. For example, security action module 114 may, as part of system 200 in FIG. 2, receive data (e.g., categorization of the network traffic) from inspection module 108. The security action module 114 may determine, in response to the data received, that the traffic should be blocked, transmitted through direct transmission to a destination host, or through secure transmission to a remote server).
Regarding claim 2, Song discloses the method according to claim 1, wherein processing the network data packet according to the target path and the access permission comprises:
determining whether the first process is a security process (see Song; [0067]; if the traffic requires additional security, proxy connect 518 may transmit the device traffic to secure socket 524, which may establish a secure tunnel with remote server 532 and transmit the traffic accordingly);
determining, according to the access permission, whether the target resource corresponding to the target network address is allowed to be accessed by the security process, in response to the first process being a security process (see Song; [0067]; Proxy connect may determine at channel determination 520, based on data from a tunnel selector of the inspection module 108, which channel (e.g., channel type, channel and destination to transmit the traffic);
transmitting the network data packet over the target path in response to the target resource being allowed to be accessed by the security process (see Song; [0067]; if the traffic requires additional security, proxy connect 518 may transmit the device traffic to secure socket 524, which may establish a secure tunnel with remote server 532 and transmit the traffic accordingly); and
discarding the network data packet in response to the target source being not allowed to be accessed by the security process (see Song; [0069]; if the domain name reputation is negative (e.g., is below a designated threshold value), the security action performed by the network client 504 may include proxy socket 516 blocking access 528 to a domain of the domain name).
Regarding claim 3, Song discloses the method according to claim 1, further comprising:
determining, according to the access permission, whether the target resource corresponding to the target network address is allowed to be accessed by the non-security process in response to the first process being a non-security process (see Song; [0058]; the security action module 114 may determine to transmit the traffic based on data received from the inspection module 108);
transmitting the network data packet over the target path in response to the target resource being allowed to be accessed by the non-security process (see Song; [0058]; The security action module 114 may determine to directly transmit the traffic to a designated destination host. In other words, does not require secure transmission); and
discarding the network data packet in response to the target source being not allowed to be accessed by the non-security process (see Song; [0056]; the security action module 114 may determine, in response to the data received, that the traffic should be blocked).
Regarding claim 5, Song discloses the method according to claim 1, further comprising:
determining a second process from local processes in response to the first process being a non-security process and an outbound request of a local loopback being initiated by the first process, and establishing a connection between the first process and the second process in response to the second process being a non-security process, or skipping establishing the connection between the first process and the second process in response to the second process is a security process; or
determining, in response to the first process being a non-security process and an outbound request of a non-local loopback being initiated by the first process, whether an outbound resource corresponding to the outbound request is allowed to be accessed by the non-security process, and establishing a connection between the first process and the outbound resource in response to the outbound resource allows access by the non-security process, or skipping establishing the connection between the first process and the outbound resource in response to the outbound resource being not allowed to be accessed by the non-security process (see Song; [0052]; all network traffic for computing device 206 may be directed or redirected to a network client of the computing device 206. The network client may provide split tunneling capabilities, allowing some of the network traffic to directly access destination hosts or the Internet, while other traffic may be routed through a remote sever for additional security).
Regarding claim 6, Song discloses the method according to claim 1, further comprising:
determining a second process from local processes in response to the first process being a security process and an outbound request of a local loopback being initiated by the first process, and establishing a connection between the first process and the second process in response to the second process being a security process, or skipping establishing the connection between the first process and the second process in response to the second process being a non-security process; or
determining, in response to the first process being a security process and an outbound request of a non-local loopback being initiated by the first process, whether an outbound resource corresponding to the outbound request is allowed to be accessed by the security process, and establishing a connection between the first process and the outbound resource in response to the outbound resource being allowed to be accessed by the security process, or skipping establishing the connection between the first process and the outbound resource in response to the outbound resource being not allowed to be accessed by the security process (see Song; [0052]; all network traffic for computing device 206 may be directed or redirected to a network client of the computing device 206. The network client may provide split tunneling capabilities, allowing some of the network traffic to directly access destination hosts or the Internet, while other traffic may be routed through a remote sever for additional security).
Regarding claim 8, Song discloses the method according to claim 1, wherein the method further comprises:
prior to determining the first path or the second path as the target path according to the target network address of the network data packet, constructing a domain name system (DNS) request using the first process (see Song; [0053]; receiving module 104 may, as part of system 200 in FIG. 2, transmit the network traffic to parser module 106); and
transmitting the DNS request to a local proxy process such that the proxy process parses the DNS request (see Song; [0053]; Parser module 106 may include multiple different parsers. Parser module 106 may select a parser based on the network traffic and may parse the network traffic using the selected parser).
Regarding claim 9, Song discloses the method according to claim 8, wherein the method further comprises:
after transmitting the DNS request to the local proxy process such that the proxy process parses the DNS request, determining, in response to the first process being a security process, whether the target resource corresponding to a domain name carried in the DNS request is allowed to be accessed by the security process (see Song; [0054]; the inspection module 108 may extract a domain name from the parsed data and may use the domain name to obtain reputation data. The reputation data may be stored locally or on a remote computing device. The reputation data may be a numeric value of a given scale that indicates a positive or negative data associated with the domain name (e.g., number of incident reports, detection of malware on the domain, etc.));
transmitting a response packet corresponding to the DNS request over UDP port 53 in response to the target resource corresponding to the domain name being allowed to be accessed by the security process (see Song; [0069]; If the domain name reputation is positive, the security action may include proxy socket 516 allowing access to the domain of the domain name); and
prohibiting transmitting a response packet over the UDP port 53 in response to the target resource corresponding to the domain name being not allowed to be accessed by the security process (see Song; [0057]; if the security action module 114 determines to block access to an external resource, such as a destination host, remote server, or the like, the security action module 114 may communicate with a proxy socket of a network client executing on the computing device to block access to the resource and to transmit a message to the user indicating that access to the external resource has been block).
Regarding claim 10, Song discloses the method according to claim 9, wherein the method further comprises:
after transmitting the response packet corresponding to the DNS request over the UDP port 53 in response to the target resource corresponding to the domain name being allowed to be accessed by the security process, parsing out a mapping relationship between the domain name and the target network address from the response packet (see Song; [0069]; The parsed data may be transmitted to the inspection module 108. A web filter of the inspection module 108 obtain a domain name extracted by the parser module 106 from the network traffic and may determine a reputation of the domain name. If the domain name reputation is positive, the security action may include proxy socket 516 allowing access to the domain of the domain name); and
caching the mapping relationship (see Song; [0054]; the reputation data may be stored locally or on a remote computing device).
Regarding claim(s) 11-13, 15-16, 18-19, and 20 do(es) not teach or further define over the limitation in claim(s) 1-3, 5-6, 8-9 and 1 respectively. Therefore claim(s) 11-13, 15-16, 18-19 and 20 is/are rejected for the same rationale of rejection as set forth in claim(s) 1-3, 5-6, 8-9 and 1 respectively.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 4 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Song et al. (US 2019/0372937) in view of Chung (US 11,863,528).
Regarding claim 4, Song discloses the invention substantially, however the prior art does not explicitly disclose the method according to claim 1, wherein the method further comprises prior to acquiring the network data packet from the first process:
acquiring a first configuration file and a second configuration file, wherein the first configuration file is indicative of a correspondence relationship between network addresses and target paths of resources, the second configuration file is indicative of an access permission for each respective resource of the resources, and the access permission for the respective resource is used for indicating that the resource is only allowed to be accessed by the security process, the respective resource is only allowed to be accessed by the non-security process, or the respective resource is only allowed to be accessed by the security process and the non-security process.
Chung in the field of the same endeavor discloses techniques for generating a set of destination IP address to be added into a firewall whitelist. In particular, Chung teaches the following:
acquiring a first configuration file and a second configuration file, wherein the first configuration file is indicative of a correspondence relationship between network addresses and target paths of resources, the second configuration file is indicative of an access permission for each respective resource of the resources, and the access permission for the respective resource is used for indicating that the resource is only allowed to be accessed by the security process, the respective resource is only allowed to be accessed by the non-security process, or the respective resource is only allowed to be accessed by the security process and the non-security process (see Chung; col. 1/lines 65-col. 2/lines13; detx 11; reverse proxy service can associate a reverse proxy with a plurality of virtual computing resource endpoints, assign a destination IP address to the reverse proxy, and provide the destination IP address to be added into the firewall so that such destination IP address can be allowlisted. Once the destination IP address is added into the firewall allowlist, the client computer may communicate with the virtual computing resources without the need of constantly updating the firewall as the virtual computing resources are added dynamically).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to modify the prior art with the teaching of Chung to incorporate techniques for generating a set of destination IP address to be added into a firewall whitelist. One would have been motivated because Chung simplifies firewall management by abstracting dynamic endpoints to static IP addresses, reducing the need for frequent updates to accommodate dynamically commissioned or decommissioned virtual resources.
Regarding claim(s) 14, do(es) not teach or further define over the limitation in claim(s) 4 respectively. Therefore claim(s) 14 is/are rejected for the same rationale of rejection as set forth in claim(s) 4 respectively.
Claims 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Song et al. (US 2019/0372937) in view of Kommula et al. (US 10,764,249).
Regarding claim 7, Song discloses the invention substantially, however the prior art does not explicitly disclose the method according to claim 1, further comprising:
in response to the first process being a security process and an inbound request of a non-local loopback being received by the first process, ignoring the inbound request.
Kommula in field of the same endeavor discloses techniques for anti-spoofing in overlay networks where a gateway device verifies the legitimacy of network packets by comparing tunnel identifiers derived from the packet outer and inner headers to ensure the source virtual machine’s traffic aligns with the expected network tunnel, dropping packets if mismatches occur. In particular, Kommula teaches the following:
in response to the first process being a security process and an inbound request of a non-local loopback being received by the first process, ignoring the inbound request (see Kommula; col. 15/lines 37-48; detx 53; anti-spoofing module 324 checks whether the source virtual IP address is associated with (assigned to) VM-A1 204A1, VM-A2 204A2, or VM-A3 204A3. If the source virtual IP address is not listed in VPN table 328 as a valid VM, then anti-spoofing module 324 drops the inbound packet (424)).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to modify the prior art with the teaching of Kommula to incorporate techniques for anti-spoofing in overlay networks. One would have been motivated because Kommula enhances the prior art by leveraging tunnel identifiers verification to detect and block malicious packets attempting to impersonate legitimate virtual machines, thereby improving security in virtualized, multi-tenant cloud data center environments without requiring complex additional infrastructure.
Regarding claim(s) 17, do(es) not teach or further define over the limitation in claim(s) 7 respectively. Therefore claim(s) 17 is/are rejected for the same rationale of rejection as set forth in claim(s) 7 respectively.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
For the reason above, claims 1-20 have been rejected and remain pending.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JIMMY H TRAN whose telephone number is (571)270-5638. The examiner can normally be reached Monday-Friday 9am-5pm PST.
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, Chris Parry can be reached at 571-272-8328. 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.
JIMMY H TRAN
Primary Examiner
Art Unit 2451
/JIMMY H TRAN/Primary Examiner, Art Unit 2451
Prosecution Insights