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 .
Response to Amendment
This office action is in response to amendment/reconsideration filed on 08/13/2026, the amendment/reconsideration has been considered. Claims 2, 7, 9, 14, 16 and 21 have been amended. Claims 2-21 are pending for examination as cited below.
Response to Arguments
Applicant’s arguments with respect to amended claim(s) have been considered but are moot in view of the new grounds of rejection necessitated by claim amendments.
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.
The factual inquiries 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.
Claim(s) 2-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Aluvala et al. (Pub. No.: US 2017/0078336 A1), hereinafter “Alu” in view of Karunakaran et al. (Pub. No.: US 2016/0219060 A1), hereinafter “Karu”.
As to claim 2. Alu discloses, a method for providing split-tunneled network connections on a per-application basis (Alu, Abstract), the method comprising:
receiving, by a network driver, network traffic originating from a client application executing on a client device (Alu, Client device executes a monitor application and a network tunnel adapter i.e. virtual network driver. The network tunnel adaptor 113 can correspond to a virtual network device. The network tunnel adaptor 113 can simulate a hardware network device and can operate on packets at layer3 of the OSI model. It further discloses that packets sent by the client application 109 to the network tunnel adaptor 113 can be injected by the network adaptor 113 into the network stack of the operating system. Also see [0021]);
determining whether the client application that originated the network traffic is a managed application by inspecting a list of managed applications to check whether the client application is included in the list (Alu, [0027], the approved application list 123 to determine whether the client application 109 is an approved application. For example, the monitor application 106 can compare the file name or file system path of the newly instantiated client application 109 to a list of file names or file system paths included in the approved application list 123. As another example, the monitor application 106 can compare the digital signature of the newly instantiated client application 109 with a list of digital signatures included in the approved application list 123.);
in response to determining that the client application is a managed application (Alu, [0027]),
sending a connection request from the network driver to a tunnel client (Alu, fig.3, [0020], the monitor application 106 can create either a network tunnel adaptor 113 or a network tap adaptor 116 for use by the client application 109 to communicate over a VPN and [0038], step 313, the monitor application 106 can determine whether the client application 109 is authorized to access a VPN, as previously described. In response to determining that the client application 109 is authorized to access a VPN, at step 316 the monitor application 106 can create or otherwise instantiate a VPN connection),
wherein the tunnel client, in response to the connection request, evaluates one or more routing policies to determine routing information for the network traffic, the one or more routing policies being based on the client application, a destination of the network traffic, or a type of the network traffic (Alu, [0018], a separate VPN configuration 126 can be used for each client application 109 included in the approved application list 123. For example, an enterprise may prefer that network traffic sent and received from particular client applications 109 be routed through a particular VPN. Also, [0017], the VPN configuration 126 can specify which Domain Name System (DNS) servers to use with the network tunnel adaptor 113 or the network tap adaptor 116, which IP address or addresses to assign to or associate with the network tunnel adaptor 113 or the network tap adaptor 116,);
receiving a connection response containing the routing information (Alu, [0027], If the identifier of the client application 109 is included in the approved application list 123, then the monitor application 106 can determine that the client application 109 is authorized to use a VPN. In this case, the process proceeds to step 216. However, if the identifier of the client application 109 is not included in the approved application list 123, then the monitor application 106 can determine that the client application 109 is unauthorized to use the VPN.); and
forwarding the network traffic to either a tunneled connection or a bypass connection depending on the connection response (Alu, [0027], see above.).
Alu however is silent to disclose explicitly, plurality of routing policies; plurality of routing policies being based on the client application, a destination of the network traffic, or a type of the network traffic, wherein the plurality of routing policies apply to the client application and specify that first network traffic originating from the client application and having a first destination is to be routed through a tunneled connection and second network traffic originating from the same client application and having a second destination is to be routed through a bypass connection.
Karu however discloses a similar concept in the same field of endeavor including, plurality of routing policies (Karu, [0027], [0031],[0035-0036], These passages disclose configured destination dependent routing outcomes and per-app policies.);
plurality of routing policies being based on the client application a destination of the network traffic, or a type of the network traffic, (Karu, [0026], places client app 106 under management and provides configuration data to supervise its connection requests/traffic through tunnel plug-in 110. In [0027] further configures the plugin to selectively direct traffic from that application. And in [0036], expressly states that policies may be enforced on “on a per app and/or per tunnel basis.),
a destination of the network traffic, or a type of the network traffic, wherein the plurality of routing policies apply to the client application and specify that first network traffic originating from the client application and having a first destination is to be routed through a tunneled connection (Karu, [0027], client app 106 generates traffic addressed to nodes associated with security proxy server 116. More specifically, [0031], describes the same client app requesting a connection to IdP proxy 120, identified by its URL. Map the first destination to the security proxy/Idp Proxy. Additionally, [0027], sends security proxy addressed traffic through tunnel 112 and [0031], expressly requires traffic directed to Idp Proxy 120 to be sent “only via a secure tunnel.”) and
second network traffic originating from the same client application and having a second destination is to be routed through a bypass connection (Karu, [0027] the same client app 106 also generates traffic addressed to cloud based service 108. Map the second destination to cloud based service 108. Further [0027], forwards service addressed traffic directly to cloud based service 108, contrasting it with traffic sent through tunnel 112. In [0035] describes “advanced split tunneling capabilities,” including direct forwarding to a service provider. Direct forwarding maps to bypassing the secure tunnel. Further explanation can be found in fig.2, step 202-210, [0039], the tunnel client receives a connection request, determines whether its destination requires a secure tunnel and either forwards it directly or establishes /uses the tunnel.).
Therefore, before the effective filing date of the instant application it would have been obvious to one of the skilled in the art to incorporate the teachings of “Karu” e.g., teaches brining client 106 under management and configuring tunnel plugin to selectively direct the traffic” into those of Alu e.g., identifying a client application as approved for VPN access by checking an approved application list and providing VPN connectivity for that application. Both references address controlled network access by client applications. The modification would permit security sensitive authentication/proxy traffic to use a secure tunnel while allowing service traffic not requiring that tunnel to reach its destination directly. This would provide finer grained routing control.
As to claim 3. Alu discloses, further comprising: in response to determining that the client application is not a managed application, sending the network traffic as requested by the client application (Alu,fig.2, step 213-203, [0027], when the application is not approved, the system does not create a VPN interface and instead returns to normal processing).
As to claim 4. Alu discloses, wherein forwarding the network traffic to a tunneled connection further comprises connecting to a relay service that routes the network traffic through a tunnel server over a virtual private network (VPN) connection (Alu, [0020]-[0021], after detecting a first network packet…the monitor application 106 can initiate…the VPN… and then relay the first network packet, as well as subsequence network packets… to the virtual network adaptor. The monitor application 106 can create a network tunnel adapter 113 or a network tap adaptor 116 for use by the client application 109 to communicate over a VPN.).
As to claim 5. Alu discloses, wherein forwarding the network traffic to a bypass connection further comprises forwarding the network traffic over a network directly to a remote host (Alu, [0027], if the identifier of the client application 109 is not included in the approves list of applications, then the monitor application 106 can determine that the client application 109 is not authorized to use the VPN.).
As to claim 6. Alu discloses, wherein the network driver impersonates a driver or interface provided by an operating system of the client device such that the network driver intercepts all network traffic from all client applications executing on the client device (Alu, [0014]-[0015], describes the virtual adaptors as OS-level network devices. Any application sending IP(L3) or Ethernet(L2) packets must send them through the OS network stack, which routes them though the impersonating virtual adaptor and [0021], …the monitor application 106 can then relay the first network packet, as well as subsequent network packet from the client application 109 to the virtual network adaptor.).
As to claim 7. Alu discloses, wherein the client application is specifically configured to use the network driver instead of a driver or interface provided by the operating system of the client device (Alu, [0020], when an application is approved, the system “creates a network tunnel adaptor 113 or network tap adaptor 116 for use by the client application 109 to communication over a VPN. [0014]-[0015], these virtual adaptors, simulate a hardware network device. [0021], thereby impersonating the OS-provided network interface. The monitor application then relays, the first network packet, as well as subsequent network packets from the client application to the virtual adaptor, ensuring that the client application uses the impersonating network driver rather than the OS’s default driver.).
As to claim 8. Alu discloses, further comprising: terminating a connection for the network traffic in response to determining that the routing information indicates that the network traffic is to be blocked (Alu, fig.2, step-226, [0030], describes whether the client application is still sending traffic: “the monitor application 106 can determine that the client application 109 is no longer using the VPN because the client application 109 has failed to send or receive any packets within a determined period of time. [0021], closes or disables the VPN connection.).
As to claims 9 and 16 are rejected for same rationale as discussed above for claim 2.
As to claims 10 and 17 are rejected for same rationale as discussed above for claim 3.
As to claims 11 and 18 are rejected for same rationale as discussed above for claim 4.
As to claims 12 and 19 are rejected for same rationale as discussed above for claim 5.
As to claims 13 and 20 are rejected for same rationale as discussed above for claim 6.
As to claims 14 and 21 are rejected for same rationale as discussed above for claim 7.
As to claim 15 are rejected for same rationale as discussed above for claim 8.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Please see the attached PTO-892.
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TAUQIR HUSSAIN whose telephone number is (571)270-1247. The examiner can normally be reached M-F 7:00 - 8:00 with IFP.
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, Vivek Srivastava can be reached on 571 272-7304. 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.
/Tauqir Hussain/Primary Examiner, Art Unit 2446
