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
This is a Final Office action in response to communications received April 01, 2026. Claims 1-3 have been amended. Therefore, claims 1-3 are pending and addressed below.
Response to Amendments
Applicants amendments to claim 3 are sufficient to overcome the 35 USC 112(b) rejection of claim 3, rejection set forth in previous office action. Therefore the rejections are withdrawn.
Applicants amendments to claim 3 are sufficient to overcome the 35 USC 112(f) rejection of claim 3, rejection set forth in previous office action. Therefore the rejections are withdrawn.
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 1-3 are rejected under 35 U.S.C. 103 as being unpatentable over Feyzibehnagh et al. (US 2019/0215308 A1, publish date 07/11/0219) in view of Vanik (US 2025/0247270 A1, file date 01/25/2024).
Claims 1-3:
With respect to claims 1-3, Feyzibehnagh et al. discloses a computer-implemented method in a VPN device/A non-transitory computer-readable medium in a video surveillance system on a data communication network/A video surveillance system (security device 107, VPNs, Figures 1, 2 and 8) (The value of encrypting traffic may be determined based on the sensitivity or perceived sensitivity of the information in the traffic to the owner or occupier of the premises 101, and/or to the user or owner of devices 103, to maintains privacy, Peer-to-peer video gaming, 0087), for managing a combination of unencrypted streams and encrypted streams over a VPN channel/storing code that when executed, performs a method for automatically associating a surveillance security policy with a user on video based on Wi-Fi data (a security device for a premises network may be configured to receive traffic leaving the premises network and may be used to enforce network policies, 0044) (security device 107 may determine whether to route the traffic flow over the Internet 111 without applying any encryption or additional security parameters to the traffic, or whether to route the traffic flow via one of the tunnels 115., 0065) (VPNs 235-241 may provide different levels of security: the unencrypted VPN 235 provides for transmitting traffic flows to a relay server without encrypting the traffic, may route user traffic over the unencrypted VPN 235 in response to determining that the traffic is addressed to a destination that accepts VPN traffic, o maintains privacy, which may justify using encryption to maintain privacy, 0087), the method/video system comprising:
a processor (processing circuitry, Figure 2, 221) (processors, 1502, Figure 15));
a network interface communicatively coupled to the processor and to a data communication network (network interface, 223); and
a memory (Computer-readable storage media, 1506, Figure 15), communicatively coupled to the processor and storing instructions that, when executed by the processor:
establishing a VPN tunnel between two or more endpoints (tunnels, Figure 1, 115) (tunnels 115 may be implemented using any suitable tunneling technology, including virtual private networks (VPNs), 0060) (one or more of the tunnels is a Virtual Private Network (VPN). Different VPNs may have different security parameters, such as whether or not the data conveyed via the VPN is compressed or whether it is encrypted., 0042) and populating a session table with designated destination addresses for VPN tunneling (may evaluate is whether the network address included in the datagrams (in this case, for the destination server 113a) is for a server or a service, the security device 107 may have a stored list of such servers and determine that the network address included in the datagrams is for a server on the list, and route the traffic flow over the Internet 111 rather than any of the tunnels 115, 0065) (the intelligence server 217 may store network names (e.g., domain names) or network addresses (e.g., IP addresses) that are associated with network paths, maintain lists of domain names such as a first list of domains associated with traffic to be routed directly to the destination over the Internet 211 without using security parameters or a second list of domains associated with domains to be routed over the premium VPN 241, 0080) (Creating a list of entries for destinations: route traffic directly to destination, over unencrypted/encrypted VPN, Figure 8, 819, 813, 817), and
wherein the session table designates which of the destination addresses do not need encryption (Creating a list of entries for destinations: route traffic directly to destination, over unencrypted/encrypted VPN, Figure 8, 819, 813, 817);
detecting a new session of network traffic (where the security device receives user traffic, 0122, Figure 8, 801);
determining from destination address whether to use a VPN or non-VPN channel based on whether the destination address has been designated for VPN traffic based on the session table (Creating a list of entries for destinations: route traffic directly to destination, over unencrypted/encrypted VPN, Figure 8, 819, 813, 817), and
if the VPN channel is used, determining whether to encrypt prior to transmitting over the VPN channel (the security device selects, for transmission of traffic for the traffic flow, a VPN that transmits a traffic flow using encryption but not using compression (e.g., VPN 239 of FIG. 2), 0127) (the security device selects for the traffic flow a tunnel that uses by encryption and compression (e.g., VPN 237 of FIG. 2), 0128), wherein unencrypted is sent over an outer VPN channel and encrypted is sent over an inner VPN channel, and wherein the inner VPN channel is established over the outer VPN channel (tunnels, Figure 2) (tunnels 115 may be implemented using any suitable tunneling technology, including virtual private networks (VPNs), 0060) (one or more of the tunnels is a Virtual Private Network (VPN). Different VPNs may have different security parameters, such as whether or not the data conveyed via the VPN is compressed or whether it is encrypted, 0042);
updating a session table with the new session (The routing information may be transmitted to the security device 207 at any suitable interval, when routing information is updated, and/or at any other suitable time, 0080),
responsive to being sent over the unencrypted VPN channel, bypassing encryption prior to transmitting over the unencrypted VPN channel (the security device determines that the traffic is to be routed over an unencrypted VPN (e.g., VPN 235 of FIG. 2), 0129), and
responsive to being sent over the encrypted VPN channel, sending the new session for encryption prior to transmitting over the encrypted VPN channel (the security device selects, for transmission of traffic for the traffic flow, a VPN that transmits a traffic flow using encryption but not using compression (e.g., VPN 239 of FIG. 2), 0127) (the security device selects for the traffic flow a tunnel that uses by encryption and compression (e.g., VPN 237 of FIG. 2), 0128), and
wherein the unencrypted VPN channel also bypasses decryption upon receipt (the data is only unencrypted and visible at either end of the tunnel (e.g., the user's remote computer and the business' premises), 0004).
Vanik teaches inner VPN tunnel 202, outer VPN tunnel 200, (Figure 2), wherein unencrypted is sent over the outer VPN channel (The remaining once-encrypted data is then decrypted by the VPN client circuitry 110 of the mobile hardware VPN device 108 (e.g., in connection with the outer VPN tunnel 200) to reveal the unencrypted data from the secure network 104, 0051, Figure 2) and encrypted is sent over the inner VPN channel (unencrypted data stored at the secure network 104 flows to the second VPN server 222, where the data is encrypted via the second or inner VPN tunnel 202 established between the second VPN server 222 and VPN client circuitry 106 of the end device 102, 0051, Figure 2), and wherein the inner VPN channel is established over the outer VPN channel (inner VPN, outer VPN, Figure 2),
Feyzibehnagh et al. and Vanik are analogous art because they are from the same field of endeavor of VPN tunneling.
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to use Feyzibehnagh et al. in Vanik for wherein unencrypted is sent over the outer VPN channel and encrypted is sent over the inner VPN channel, and wherein the inner VPN channel is established over the outer VPN channel as claimed for purposes of for providing dual, nested VPN tunnels to enable an end device that supports one VPN tunnel (e.g., natively supports only one VPN tunnel) to exchange data with a secure network (see Vanik 0019).
Response to Remarks/Arguments
Applicant's arguments filed on April 01, 2026 have been fully considered but they are not persuasive. In the remarks, Applicant argues that:
Claim 1:
1- Feyzibehnagh et al. does not teach the claimed dual-channel arrangement in which unencrypted traffic is sent over an outer VPN channel while encrypted traffic is sent over an inner VPN channel.
Feyzibehnagh et al., as characterized in the Office Action, distinguishes between traffic routed directly, traffic routed over an unencrypted VPN, and traffic routed over an encrypted VPN. That is not the same as the presently claimed architecture. Feyzibehnagh et al. does not disclose the specific nested arrangement where one VPN channel is carried over another VPN channel, with traffic selectively mapped SO that unencrypted traffic goes over the outer VPN channel and encrypted traffic goes over the inner VPN channel. Feyzibehnagh et al. appears to use alternative traffic flows. The current claim require coordinated user of both channels in a specified layered relationship.
2 - Vanik discloses that tunnel arrangement, Vanik still does not teach the claimed session-table based selection and dynamic handling recited in the present claims.
Vanik, as described by the Examiner, is cited only for the nested tunnel concept, not for the claimed session-table logic that designates which destination addresses do not need encryption and updates the session table as new sessions are observed.
3 - The proposed combination is based on hindsight. The rejection combines a reference said to disclose routing traffic with differing security treatment and a second reference said to disclose nested VPN tunnels, but the rejection does not adequately explain why a person of ordinary skill would have modified Feyzibehnagh et al. to arrive at Applicant's claimed selective session-table driven architecture. The application's disclosure is not merely "nested VPN tunnels. The Office Action does not identify where this full logic is taught or suggested in the combination. Rather, the rationale appears to reconstruct Applicant's system by selectively extracting different high-level concepts from separate references.
In response to remark/arguments (1) and (2), Examiner respectfully disagrees.
Feyzibehnagh et al. discloses Figure 1, 115, security device 107 may determine whether to route the traffic flow over the Internet 111 without applying any encryption or additional security parameters to the traffic, or whether to route the traffic flow via one of the tunnels 115., 0065) (VPNs 235-241 may provide different levels of security: the unencrypted VPN 235 provides for transmitting traffic flows to a relay server without encrypting the traffic, may route user traffic over the unencrypted VPN 235 in response to determining that the traffic is addressed to a destination that accepts VPN traffic, o maintains privacy, which may justify using encryption to maintain privacy, 0087),
one or more of the tunnels is a Virtual Private Network (VPN). Different VPNs may have different security parameters, such as whether or not the data conveyed via the VPN is compressed or whether it is encrypted., 0042) Creating a list of entries for destinations: route traffic directly to destination, over unencrypted/encrypted VPN, Figure 8, 819, 813, 817). Vanik teaches inner VPN tunnel 202, outer VPN tunnel 200, (Figure 2),
The remaining once-encrypted data is then decrypted by the VPN client circuitry 110 of the mobile hardware VPN device 108 (e.g., in connection with the outer VPN tunnel 200) to reveal the unencrypted data from the secure network 104,
unencrypted data stored at the secure network 104 flows to the second VPN server 222, where the data is encrypted via the second or inner VPN tunnel 202 established between the second VPN server 222 and VPN client circuitry 106 of the end device 102, 0051, Figure 2. Therefore, Examiner maintains that combination of Feyzibehnagh et al. and Vanik teach and suggest the specific nested arrangement where one VPN channel is carried over another VPN channel, with traffic selectively mapped so that unencrypted traffic goes over the outer VPN channel and encrypted traffic goes over the inner VPN channel, coordinated user of both channels in a specified layered relationship.
In response to remark/arguments (3), Examiner respectfully disagrees. Both Feyzibehnagh et al. and Vanik teaches with traffic selectively mapped so that unencrypted traffic goes over the outer VPN channel and encrypted traffic goes over the inner VPN channel, coordinated user of both channels in a specified layered relationship. Feyzibehnagh et al. and Vanik are analogous art because they are from the same field of endeavor of VPN tunneling. It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to use Feyzibehnagh et al. in Vanik for wherein unencrypted is sent over the outer VPN channel and encrypted is sent over the inner VPN channel, and wherein the inner VPN channel is established over the outer VPN channel as claimed for purposes of for providing dual, nested VPN tunnels to enable an end device that supports one VPN tunnel (e.g., natively supports only one VPN tunnel) to exchange data with a secure network (see Vanik 0019).
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Helai Salehi whose telephone number is 571-270-7468. The examiner can normally be reached on Monday - Friday from 9 am to 5 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Jeff Pwu, can be reached on 571-272-6798. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/HELAI SALEHI/
Examiner, Art Unit 2433
/JEFFREY C PWU/ Supervisory Patent Examiner, Art Unit 2433
Prosecution Insights