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 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. Applicant's submission filed on 09/17/2026 has been entered.
Response to Arguments
In response to communication filed on 09/17/2026, applicant amends claims 2 and 3. Applicant adds new claims 4-20. The following claims, 1-20 are presented for examination.
2.1 Applicant’s arguments, pages 2-5, filed 09/17/2026, with respect to the rejection of claims 1-19 have been fully considered, but they are not persuasive.
Applicant argues (1) The cited outer-tunnel decryption does not establish encryption bypass: Claim 1 requires an inner VPN channel established over an outer VPN channel, selective transmission of unencrypted and encrypted streams through the respective channels, and bypass of both encryption and decryption for the unencrypted VPN channel. These limitations must be considered together. The Office Action, pages 7-8 and 11, relies on Vanik paragraph [0051] and FIG. 2. That passage describes two encryption layers and subsequent decryption, including decryption associated with outer tunnel 200. Plaintext appearing after that operation does not establish transmission through an outer channel that bypasses encryption and decryption. Applicant acknowledges Vanik's nested tunnels; the disputed feature is the encryption treatment of the claimed outer channel. Feyzibehnagh supplies alternative encrypted and unencrypted routes. Even accepting that teaching, the rejection must explain how its bypass route is integrated with Vanik's nesting while satisfying the claimed outer-channel treatment. The stated objective of enabling dual VPN connectivity does not explain replacing outer-tunnel encryption with the claimed bypass. Thus, the combination as articulated leaves this relationship unresolved.
(2) Updating routing information is not the identified new-session table update
Feyzibehnagh paragraph [0080]. That paragraph concerns delivery of routing information, including destination lists, from an intelligence server to a security device. The cited delivery of routing information does not itself identify adding the detected session to a session table. Applicant does not dispute that Feyzibehnagh discloses destination-based route selection or stored routing lists. The remaining question is where the proposed combination teaches the separately recited update with the new session, rather than an update of destination-routing information. Identifying receipt of traffic in FIG. 8 and periodic distribution of routing information does not, without further explanation, establish that operation. Applicant respectfully requests identification of the particular teaching or supported reasoning supplying this limitation in the proposed combination.
In response to applicant’s arguments, (1), Feyzibehnagh discloses “the security device determines, in response to the determinations of acts 803, 807, 811, and 815 that the traffic that is not on the red list or green list, has low entropy, and has a low value-to-cost ratio for encryption, that the traffic is to be routed over an unencrypted VPN (e.g., VPN 235 of FIG. 2)” (0129), “The different configurations of the different tunnels 235-241 may relate to different security and/or encoding parameters, and the security device 207 may choose a tunnel via which to transmit a traffic flow based on one or more characteristics of the traffic flow. … selecting a network path from a group of paths (e.g., using the Internet 211 or one of the VPNs 235, 237, 239, and 241) for routing each traffic flow, where the selected path has the selected security parameters (e.g., encryption or compression)“ (0075-0076), the unencrypted VPN 235 provides for transmitting traffic flows to a relay server without encrypting the traffic … the compressed VPN 237 and the uncompressed VPN 239 both handle encrypted traffic” (0087-0088) (Figure 2: unencrypted VPN 235, premium VPN) (Figure 8), “the security device determines that the traffic is to be routed over an unencrypted VPN (e.g., VPN 235 of FIG. 2), 0129) and “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), an inner VPN channel is established over the outer VPN channel (inner VPN, outer VPN, Figure 2).
Therefore Examiner holds that the combination of Feyzibehnagh and Vanik discloses an inner VPN channel established over an outer VPN channel, selective transmission of unencrypted and encrypted streams through the respective channels, and bypass of both encryption and decryption for the unencrypted VPN channel.
In response to applicant’s arguments, (2), Feyzibehnagh et al. discloses storing routing information (e.g. numeric network addresses and/or security parameters) for the security device 207 to use in selectively routing traffic, 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).
Upon further consideration, the rejection of claims 1-20 is set forth below.
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-20 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 (The different configurations of the different tunnels 235-241 may relate to different security and/or encoding parameters, and the security device 207 may choose a tunnel via which to transmit a traffic flow based on one or more characteristics of the traffic flow. … selecting a network path from a group of paths (e.g., using the Internet 211 or one of the VPNs 235, 237, 239, and 241) for routing each traffic flow, where the selected path has the selected security parameters (e.g., encryption or compression), 0075-0076), the unencrypted VPN 235 provides for transmitting traffic flows to a relay server without encrypting the traffic … the compressed VPN 237 and the uncompressed VPN 239 both handle encrypted traffic, 0087-0088) (Figure 2: unencrypted VPN 235, premium VPN) (Figure 8);
updating a session table with the new session (stores routing information (e.g. numeric network addresses and/or security parameters) for the security device 207 to use in selectively routing traffic, 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) (the security device determines, in response to the determinations of acts 803, 807, 811, and 815 that the traffic that is not on the red list or green list, has low entropy, and has a low value-to-cost ratio for encryption, 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), and wherein the inner VPN channel is established over the outer VPN channel (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).
Claim 4:
With respect to claim 4, Feyzibehnagh et al. discloses wherein traffic of the new session is encrypted before being received by the VPN device (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
bypassing encryption comprises transmitting the traffic over the unencrypted VPN channel without adding a further layer of encryption (the security device determines, in response to the determinations of acts 803, 807, 811, and 815 that the traffic that is not on the red list or green list, has low entropy, and has a low value-to-cost ratio for encryption, that the traffic is to be routed over an unencrypted VPN (e.g., VPN 235 of FIG. 2), 0129).
Claims 5, 17:
With respect to claim 5, 17, Feyzibehnagh et al. discloses wherein bypassing encryption is permitted only when the existing encryption of the traffic satisfies one or more encryption requirements (the security device determines, in response to the determinations of acts 803, 807, 811, and 815 that the traffic that is not on the red list or green list, has low entropy, and has a low value-to-cost ratio for encryption, that the traffic is to be routed over an unencrypted VPN (e.g., VPN 235 of FIG. 2), 0129).
Claim 6:
With respect to claim 6, Feyzibehnagh et al. discloses wherein the existing encryption comprises end-to-end encryption provided by a messaging application. (traffic flows may be communicated according to one or more stateful protocols, such as TCP, or protocols that otherwise include establishing a connection between a sender and a receiver, and the traffic flow may relate to such a connection. , include any suitable content, including web traffic (e.g., web pages), email communications or other messages, streaming media (e.g., music, video, etc.), or any other type of content that may be communicated via the Internet, as embodiments are not limited in this respect. 0050)
Vanik teaches an Internet Protocol Security (IPSec) Internet Key Exchange (IKE) VPN tunnel (e.g., IPSec IKE v1 or IKE v2), or a Transport Layer Security (TLS) VPN tunnel, (0025-0026).
Feyzibehnagh et al. and Vanik are analogous art because they are from the same field of endeavor of VPN tunneling.
The motivation for combining Feyzibehnagh et al. and Vanik is recited in claim 1.
Claim 7:
With respect to claim 7, Feyzibehnagh et al. discloses wherein the traffic is received through a first VPN tunnel into an enterprise network (such as networks for use by employees of a business, are often limited to devices at a particular physical premises, 0002)(Figure 1), and the unencrypted VPN channel comprises a second VPN tunnel extending between a local network and a remote network (a security device receives traffic entering or leaving a local network, for example by being connected between a device that is a modem and/or gateway at a boundary between a local network of a premises (e.g., a residential premises) and another network (e.g., a network of an internet service provider (ISP) for the premises), and a router or switch for the premises' local network, such as a wireless access point for the premises, 0033) (Figure 1, 101).
Vanik teaches a secure network access infrastructure 107 (Figure 2).
Feyzibehnagh et al. and Vanik are analogous art because they are from the same field of endeavor of VPN tunneling.
The motivation for combining Feyzibehnagh et al. and Vanik is recited in claim 1.
Claims 8, 18:
With respect to claims 8, 18, Feyzibehnagh et al. discloses wherein updating the session table with the new session (stores routing information (e.g. numeric network addresses and/or security parameters) for the security device 207 to use in selectively routing traffic, 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) comprises storing an indication of whether traffic of the new session is to be encrypted or is to bypass encryption ( The security device 107 may determine one or more parameters of the traffic flow and, based on characteristics of the traffic flow, the 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) (the security device 207 intercepts and retransmits the traffic flows in accordance with selected security parameters by selecting a network path from a group of paths (e.g., using the Internet 211 or one of the VPNs 235, 237, 239, and 241) for routing each traffic flow, where the selected path has the selected security parameters (e.g., encryption or compression). 0076).
Claims 9, 18:
With respect to claims 9, 18, Feyzibehnagh et al. discloses wherein traffic associated with an existing session is processed according to instructions previously stored for the existing session in the session table (The security device 107 may determine one or more parameters of the traffic flow and, based on characteristics of the traffic flow, the 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) (the security device 207 intercepts and retransmits the traffic flows in accordance with selected security parameters by selecting a network path from a group of paths (e.g., using the Internet 211 or one of the VPNs 235, 237, 239, and 241) for routing each traffic flow, where the selected path has the selected security parameters (e.g., encryption or compression). 0076).
Claim 10:
With respect to claim 10, Feyzibehnagh et al. discloses wherein the outer VPN channel carries traffic without encryption added by the VPN device, and the inner VPN channel carries traffic encrypted by the VPN device (the unencrypted VPN 235 provides for transmitting traffic flows to a relay server without encrypting the traffic … the compressed VPN 237 and the uncompressed VPN 239 both handle encrypted traffic, 0087-0088) (Figure 2: unencrypted VPN 235, premium VPN) (Figure 8).
Claim 11:
With respect to claim 11, Feyzibehnagh et al. discloses wherein the VPN tunnel connects a local enterprise network and a remote enterprise network through a public network (A virtual private network (VPN) is a networking tool that allows users to create or extend a private network using an underlying public (not private) network like the Internet, 0004) (such as networks for use by employees of a business, are often limited to devices at a particular physical premises, 0002)(Figure 1), (a security device receives traffic entering or leaving a local network, for example by being connected between a device that is a modem and/or gateway at a boundary between a local network of a premises (e.g., a residential premises) and another network (e.g., a network of an internet service provider (ISP) for the premises), and a router or switch for the premises' local network, such as a wireless access point for the premises, 0033) (Figure 1, 101).
Claim 12:
With respect to claim 12, Feyzibehnagh et al. discloses wherein the VPN device comprises a local VPN server that performs session routing, encryption, and VPN session routing (the intelligence server 117 may be used to configure the security device 107 to establish tunnel (e.g., VPN) connections with the relay servers 119a-b. , 0071) (the security device 207 intercepts and retransmits the traffic flows in accordance with selected security parameters by selecting a network path from a group of paths (e.g., using the Internet 211 or one of the VPNs 235, 237, 239, and 241) for routing each traffic flow, where the selected path has the selected security parameters (e.g., encryption or compression), 0076) (Figure 1).
Claim 13:
With respect to claim 13, Feyzibehnagh et al. discloses wherein the VPN device comprises an endpoint executing VPN software to establish VPN connectivity with an enterprise network (the intelligence server 117 may be used to configure the security device 107 to establish tunnel (e.g., VPN) connections with the relay servers 119a-b. , 0071) (the security device 207 intercepts and retransmits the traffic flows in accordance with selected security parameters by selecting a network path from a group of paths (e.g., using the Internet 211 or one of the VPNs 235, 237, 239, and 241) for routing each traffic flow, where the selected path has the selected security parameters (e.g., encryption or compression), 0076) (Figure 1).
Claim 14:
With respect to claim 14, Feyzibehnagh et al. discloses wherein a remote VPN server receiving traffic over the unencrypted VPN channel bypasses decryption of the traffic when no further encryption was applied for transmission 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) (the security device determines, in response to the determinations of acts 803, 807, 811, and 815 that the traffic that is not on the red list or green list, has low entropy, and has a low value-to-cost ratio for encryption, that the traffic is to be routed over an unencrypted VPN (e.g., VPN 235 of FIG. 2), 0129), (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).
Claim 15:
With respect to claim 15, Feyzibehnagh et al. discloses wherein the data communication network comprises a software-defined wide area network connecting geographically dispersed local area networks (communicates over any suitable wide area network, 0141) (101,105, internet, Figure 1)
Claim 16:
With respect to claim 16, Feyzibehnagh et al. discloses further comprising routing VPN traffic received at a remote VPN device to a destination identified for the VPN traffic (The process 800 may be implemented by a security device (e.g., 107 or 207 of FIGS. 1-2). The process allows the device to selectively route traffic over multiple network paths based on characteristics of the traffic., 0121) (Figure 8).
Claim 17:
With respect to claim 17, Feyzibehnagh et al. discloses wherein the code, when executed, causes encryption to be bypassed for traffic that is already encrypted only when the existing encryption satisfies one or more encryption requirements (the security device determines, in response to the determinations of acts 803, 807, 811, and 815 that the traffic that is not on the red list or green list, has low entropy, and has a low value-to-cost ratio for encryption, that the traffic is to be routed over an unencrypted VPN (e.g., VPN 235 of FIG. 2), 0129).
Claim 19:
With respect to claim 19, Feyzibehnagh et al. discloses wherein the processor, the network interface, and the memory are components of a local VPN server configured to communicate with a remote VPN server over the outer VPN channel and the inner VPN channel (A virtual private network (VPN) is a networking tool that allows users to create or extend a private network using an underlying public (not private) network like the Internet, 0004) (such as networks for use by employees of a business, are often limited to devices at a particular physical premises, 0002)(Figure 1), (a security device receives traffic entering or leaving a local network, for example by being connected between a device that is a modem and/or gateway at a boundary between a local network of a premises (e.g., a residential premises) and another network (e.g., a network of an internet service provider (ISP) for the premises), and a router or switch for the premises' local network, such as a wireless access point for the premises, 0033) (Figure 1, 101) (Figure 2).
Claim 20:
With respect to claim 20, Feyzibehnagh et al. discloses further comprising the remote VPN server, wherein the remote VPN server is configured to decrypt traffic for which VPN encryption was applied by the local VPN server (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 to bypass decryption for traffic transmitted over the unencrypted VPN channel without further encryption by the local VPN server (the security device determines, in response to the determinations of acts 803, 807, 811, and 815 that the traffic that is not on the red list or green list, has low entropy, and has a low value-to-cost ratio for encryption, that the traffic is to be routed over an unencrypted VPN (e.g., VPN 235 of FIG. 2), 0129).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure, (see PTO Form 892).
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., every other Friday off
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
