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 .
Claim Objections
Claims 6-8, 17, 19 are objected to because of the following informalities:
In claim 6, the terms “TCP” and “TCL” should be spelled out.
Depending claims 7, 8, 19 are objected to with the same rationale.
In claim 17, line 2, the terms “SSL” and “TLS” should be spelled out.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 4-8, 10, 12, 14, 17-19 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 4, line 3, the term “said database” has no antecedent basis. Depending claims 5-8, 19 are rejected with the same rationale.
Regarding claim 10, line 5, the term “said database” has no antecedent basis. Depending claims 12, 14, 17 are rejected with the same rationale.
Regarding claim 18, line 3, the term “said database” has no antecedent basis.
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 (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 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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 9, 11, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Savarese et al. (Pub No.: 2024/0048493) in view of Gorsica, IV et al. (Pub No.: 2020/0344213).
Regarding claim 1, Savarese et al. discloses a system (client-server system in fig. 1) for detecting proxied network connections (DPNC), comprising:
a network sensor (read as VPN policy engine 22 and/or collector 28 within VPN client 20 in fig. 1) coupled with an electronic data network (read as public or private network in para. 0073) and configured to receive network traffic including packets for a network connection, to extract metadata features (read as metadata information in para. 0081) from said packets, and to transmit the extracted metadata features (Savarese et al. see fig. 1, client 10, application 12, VPN client 20, VPN policy engine 22, collector 28; fig. 5, network flow information 514; para. 0072, 0073, 0077, 0081, 0093; VPN policy engine 22 informs collector 28 of the packet and reputation. After VPN policy engine 22 has processed the packet to the actual host, its associated reputation data and a determination of how to handle the packet will have been made, i.e., connect through local proxy, connect through VPN tunnel 26, or block, VPN policy engine 22 informs collector 28 of the packet, reputation and network flow metadata. In para. 0093, … This network flow information can include the collector data from client and metadata about the network flows 511, 512, 513). The VPN policy engine processes and extracts packet to determine of how to handle the packet and to inform collector of the network flow metadata. In fig. 5, the network flow information 514 can include the collector data from client and metadata (e.g., information/features) about the network flows 511-513;
a software module (see application 12 in fig. 1) adapted to initiated by a client device (see client 10 in para. 0072) and to generate network traffic (see unprotected network flows in fig. 1) from said client device to one or more of said plurality of network sensors (Savarese et al. see fig. 1, application 12, client 10 and VPN client 20; para. 0072, 0081; In the client 10, which can be a mobile device, e.g., laptops, netbooks, smartphones, handheld devices, workstations, PDAs, iPads, tablet computers, etc., one or more applications can be stored in a memory and can be executed by a processor. In executing an application 12, a socket 14 can be established for transmitting data,). The application (e.g., browser) is initiated by a client 10 such as a mobile device and to generate traffic data from the client 10 to the VPN client 20; and
a server (a server 530 including machine learning 532, VPN server pool 531 and reporting engine 535 in fig. 5 and para. 0091) configured to receive said extracted metadata features, to analyze said extracted metadata features and to determine whether said network connection was proxied based on a comparison of at least one of said extracted metadata features with an expected metadata feature (read as categories of interest, reputations (e.g., severe risk, high risk, moderate risk, low risk and unknown reputation) in para. 0094), and to generate an indicator (read as alert in para. 0175) indicating a likelihood that said network connection is proxied (Savarese et al. see fig. 5, network flows 511-513; para. 0091, 0093-0097, 0099-0107, 0175, 0178; all attempted network flows 511-513 are captured at the client or client device 510 and, depending upon the currently configured policy of the client, are routed either directly to their intended destinations 513 via a local proxy to a public or private network, proxied through the tunnel 511 and to their intended destinations 512 via VPN server pool, or blocked, ... Analysis servers 534 will periodically retrieve and process network flow metadata 518 from data storage 533, depending on the specific needs of the algorithms, including machine learning algorithms, being employed, and produce zero or more alerts. In para. 0096, …By way of non-limiting example, the system can detect that a user has accessed a website that is not typically used by other users in the deployment and is uploading large amounts of information, such as uploading data to dropbox. This behavior will create an alert and policy trigger sent down to clients.). Thus, the Analysis server uses network flow metadata 518 for network flows (e.g., proxied connection 511) to analyze/compare the metadata with the configured triggering policies (see para. 0105 wherein policy may be configured such that all traffic is routed through the VPN tunnel) to generate an alert (e.g., when configured policy is triggered) to indicate a low likelihood that the traffic is proxied/VPN.
However, Savarese et al. does not explicitly disclose a plurality of sensors.
Gorsica, IV et al. from the same or similar fields of endeavor discloses a plurality of sensors residing in a computing device (e.g., VPN device) (Gorsica, IV et al. see fig. 6, device 600 (VPN device), sensors 618; para. 0100, 0106; an example electronic device 600 that can be implemented as a computing device, a wearable device, or a VPN endpoint device. In para. 0106, The electronic device 600 also optionally includes one or more sensors 618.).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the disclosure of Savarese et al. and to implement with a plurality of sensors within a computing device as taught by Gorsica, IV et al.
The motivation would be to improve network scalability.
Regarding claim 9, Savarese et al. discloses the feature wherein said client is connected to a web server (Savarese et al. see server 530 and/or 3rd party servers 520 in fig. 5), and said software module is embedded in web page accessed by said client device and configured to be initiated by the web page on the client device to generate network traffic to one or more of said plurality of network sensors (Savarese et al. see para. 0081; An exemplary flow diagram of an operation of the client 10 and VPN server pool 100 is depicted in FIG. 2. The process 200 begins when an application, e.g., on a browser, chooses to connect to a host by querying a host name at 201, …The VPN server pool will return the retrieved reputation data for the host to VPN policy engine and VPN policy engine will forward network flows to the collector for recording at 207.). The client coupled to a web server (server 530 and/or 3rd party servers) accesses the application/browser (displays web page) and initiates a query to a host name to obtain reputation data. The VPN server pool will return the retrieved reputation data to the collector/sensor.
Regarding claim 11, Savarese et al. discloses the feature wherein said client is connected to an application server (Savarese et al. see server 530 and/or 3rd party servers 520 in fig. 5), and said software module is embedded in an application accessed by said client device and configured to be initiated by access to the application by the client device to generate network traffic from said client device to one or more of said plurality of network sensors (Savarese et al. see para. 0081; An exemplary flow diagram of an operation of the client 10 and VPN server pool 100 is depicted in FIG. 2. The process 200 begins when an application, e.g., on a browser, chooses to connect to a host by querying a host name at 201, …The VPN server pool will return the retrieved reputation data for the host to VPN policy engine and VPN policy engine will forward network flows to the collector for recording at 207.). The client coupled to an application server (server 530 and/or 3rd party servers) accesses the application and initiates a query to a host name to obtain reputation data. The VPN server pool will return the retrieved reputation data to the collector/sensor.
Regarding claim 20, Savarese et al. discloses the feature wherein said plurality of network sensors are configured to store said extracted metadata features in a database, and said server is coupled with said database and configured to access said stored metadata features (Savarese et al. see fig. 1, VPN server pool 100 and data gateway 114; para. 0077, 0080; VPN policy engine 22 informs collector 28 of the packet, reputation and network flow metadata. Data gateway 114 receives the network flow information and/or metadata from the downloaded collector data and unpacks or normalizes the downloaded data.). The data gateway 114 receives metadata from the downloaded collector data.
Claim(s) 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Savarese et al. (Pub No.: 2024/0048493) in view of Gorsica, IV et al. (Pub No.: 2020/0344213) as applied to claim 1 above, and further in view of Gizis et al. (Pub No.: 2023/0379377).
Regarding claim 2, Savarese et al. in view of Gorsica, IV et al. does not explicitly disclose the feature wherein said server is configured to determine whether said network connection was proxied based at least on a calculation of latency for the packets relating said network connection and a comparison of the calculated latency with an expected latency.
Gizis et al. from the same or similar fields of endeavor discloses the feature wherein said server is configured to determine whether said network connection was proxied based at least on a calculation of latency for the packets relating said network connection and a comparison of the calculated latency with an expected latency (Gizis et al. see para. 0042, …If the direct connection between the client devices is experiencing connection degradation, such as latency, jitter and/or packet errors, the VPN may be invoked to manage the data traffic until a threshold period of time has passed where the traffic is not experiencing any unacceptable levels of data degradation and the VPN can again be bypassed in favor of a direct connection without the VPN.) Thus, the VPN server 112 determines that the latency of the connection is above a threshold, it determines that the connection is not proxied and will invoke to manage the data traffic.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the disclosure of Savarese et al. in view of Gorsica, IV et al. and to implement with the feature as taught by Gizis et al. wherein the VPN server determines whether network connection was proxied based on latency.
The motivation would be to improve transmission reliability.
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Savarese et al. (Pub No.: 2024/0048493) in view of Gorsica, IV et al. (Pub No.: 2020/0344213) as applied to claim 1 above, and further in view of Wang (Pub No.: 2015/0373039).
Regarding claim 4, Savarese et al. in view of Gorsica, IV et al. does not explicitly disclose the feature wherein each network sensor is further configured to extract metadata features for each packet of the connection and to transmit the metadata features for each packet in said database.
Wang from the same or similar fields of endeavor discloses the feature wherein each network sensor is further configured to extract metadata features for each packet of the connection and to transmit the metadata features for each packet in said database (Wang see fig. 3, sensor engines 200A; para. 0080; where the network sensor engine 200 generates metadata from at least a portion of the collected data. For example, the network sensor engine 200 may extract metadata from different data such as extracting data from packet headers, extracting data from logs, extracting information from flow based collection records, and/or extracting information from host telemetry information.). Each of the sensors extracts metadata (e.g., information/features) from connection flows and transmit the metadata information in data analysis engine 220a or database.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the disclosure of Savarese et al. in view of Gorsica, IV et al. and to implement with the feature as taught by Wang wherein each of the sensors extracts metadata features from connection flows and transmits it to a database.
The motivation would be to improve transmission efficiency.
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Savarese et al. (Pub No.: 2024/0048493) in view of Gorsica, IV et al. (Pub No.: 2020/0344213) and Wang (Pub No.: 2015/0373039) as applied to claim 4 above, and further in view of Boyce et al. (Pat No.: 11,310,142).
Regarding claim 5, Savarese et al. in view of Gorsica, IV et al. and Wang does not explicitly disclose the feature wherein said metadata features for each packet include at least one of Layer 3 IP fields, Layer 4 fields, and application layer fields, a timestamp for a packet observation, and a direction of the packet.
Boyce et al. from the same or similar fields of endeavor discloses the feature wherein said metadata features for each packet include at least one of Layer 3 IP fields, Layer 4 fields, and application layer fields, a timestamp for a packet observation, and a direction of the packet (Boyce et al. see fig. 2, Tables 201-204; column 4, lines 12-29, lines 43-50; In the example of FIG. 2, a metadata record may carry an annotation metadata (see Table 202), a flow metadata (see Table 203), or a protocol metadata (see Table 204). Protocol metadata may be for a layer 2, layer 4, layer 5, layer 6, or layer 7 protocol.).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the disclosure of Savarese et al. in view of Gorsica, IV et al. and Wang and to implement with the feature as taught by Boyce et al. wherein the metadata features include at least one of Layer 3 IP fields, Layer 4 fields, and application layer fields, a timestamp for a packet observation, and a direction of the packet.
The motivation would be to improve transmission reliability.
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Savarese et al. (Pub No.: 2024/0048493) in view of Gorsica, IV et al. (Pub No.: 2020/0344213) as applied to claim 1 above, and further in view of Berger et al. (Pub No.: 2022/0100869).
Regarding claim 10, Savarese et al. in view of Gorsica, IV et al. does not explicitly disclose the feature wherein said software module causes said client device to generate an HTTPS GET REQUEST directed to at least one of said plurality of network sensors, and said network sensors are configured to extract metadata features of each packet associated with the HTTPS GET REQUEST and store said extracted metadata data features in said database.
Berger et al. from the same or similar fields of endeavor discloses the feature wherein said software module causes said client device to generate an HTTPS GET REQUEST directed to at least one of said plurality of network sensors, and said network sensors are configured to extract metadata features of each packet associated with the HTTPS GET REQUEST and store said extracted metadata data features in said database (Berger et al. see fig. 1, sensors 121, 123, ,125, 127, agent 130; para. 0039, 0043, 0044, 0047, 0049, 0137; Source sensors 121 may be instrumented to methods that extract data from received external requests, like methods that process incoming HTTP requests and extract data from portions of such requests like e.g., query strings, header values or other request portions.). The application causes the virtual machine to generate/receives external request (e.g., HTTP request) and transmits the request to the sensors 121-127, wherein the sensors extract metadata features of the packets associated with the request and forward the metadata 122, 124, 126, 128 (see fig. 1) to agent/database.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the disclosure of Savarese et al. in view of Gorsica, IV et al. and to implement with the feature as taught by Berger to receive HTTP request by different sensors and to extract metadata features from each of the packets associated with the request and forward the metadata features to a database for further analysis.
The motivation would be to decrease transmission error.
Claim(s) 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Savarese et al. (Pub No.: 2024/0048493) in view of Gorsica, IV et al. (Pub No.: 2020/0344213) as applied to claim 1 above, and further in view of Matsuda et al. (Pub No.: 2009/0310500).
Regarding claim 13, Savarese et al. in view of Gorsica, IV et al. does not explicitly disclose the feature wherein a unique session ID is generated using IP address, IP protocol, and transport layer port fields to distinguish network flows.
Matsuda et al. from the same or similar fields of endeavor discloses the feature wherein a unique session ID is generated using IP address, IP protocol, and transport layer port fields to distinguish network flows (Matsuda et al. see para. 0101; it generates a TCP session ID from a combination of a source IP address, a source port number, a destination IP address, and a destination port number included in a TCP/IP packet received (step S2)… a TCP session ID is an identifier used for determining whether received TCP/IP packets belong to the same session (connection). Even if an IP address and a port number corresponding to a source are replaced with an IP address and a port number corresponding to a destination and vice versa, the determination that these sessions are the same can be made on the basis of a TCP session ID.). Thus, the TCP session ID is generated using IP address (source IP address), IP protocol (destination IP address), and a destination port of TCP/IP packet.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the disclosure of Savarese et al. in view of Gorsica, IV et al. and to implement with the feature as taught by Matsuda et al. wherein a unique session ID is generated using IP address, IP protocol and transport layer (TCP/IP) port fields.
The motivation would be to provide transmission reliability.
Claim(s) 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Savarese et al. (Pub No.: 2024/0048493) in view of Gorsica, IV et al. (Pub No.: 2020/0344213) as applied to claim 1 above, and further in view of Ricafort et al. (Pub No.: 2016/0050224).
Regarding claim 15, Savarese et al. in view of Gorsica, IV et al. does not explicitly disclose the feature wherein said indicator is a score.
Ricafort et al. from the same or similar fields of endeavor discloses the feature wherein said indicator is a score (Ricafort et al. see para. 0009; where the alert comprises information that at least partly indicates the user data or the traffic data that contributed to the risk score exceeding the threshold value).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the disclosure of Savarese et al. in view of Gorsica, IV et al. and to implement with the feature as taught by Ricafort et al. wherein the alert includes score threshold.
The motivation would be to enhance indication features.
Claim(s) 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Savarese et al. (Pub No.: 2024/0048493) in view of Gorsica, IV et al. (Pub No.: 2020/0344213) as applied to claim 1 above, and further in view of Yawalkar et al. (Pub No.: 2022/0272127).
Regarding claim 16, Savarese et al. in view of Gorsica, IV et al. does not explicitly disclose the feature wherein said software module is a JavaScript library.
Yawalkar et al. from the same or similar fields of endeavor discloses the feature wherein said software module is a JavaScript library (Yawalkar et al. see fig. 6, client application and security web module; para. 0043; the web module described herein may be coded as JavaScript code and provided to the client web browser application as an additional resource when the web browser requests the web application.).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the disclosure of Savarese et al. in view of Gorsica, IV et al. and to implement with the feature as taught by Yawalkar et al. wherein software module is JavaScript library.
The motivation would be to enhance dynamic user experiences.
Claim(s) 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Savarese et al. (Pub No.: 2024/0048493) in view of Gorsica, IV et al. (Pub No.: 2020/0344213) as applied to claim 1 above, and further in view of Atluri et al. (Pub No.: 2008/0059542).
Regarding claim 18, Savarese et al. in view of Gorsica, IV et al. does not explicitly disclose the feature wherein said application server is configured to extract metadata features from packet flows relating to execution of an application on said application server by said client device, and to store said metadata features in said database.
Atluri et al. from the same or similar fields of endeavor discloses the feature wherein said application server is configured to extract metadata features from packet flows relating to execution of an application on said application server by said client device, and to store said metadata features in said database (Atluri et al. see fig. 2, application server 102, application module 200, filter module 202; para. 0077; a meta-data information (e.g., data write location information on the storage device) may be extracted from the data write. In operation 706, the meta-data information of the data write may be compared with other data write (e.g., using the data analyzer 210 as illustrated in FIG. 2) on an application server storage (e.g., the application server storage 104). In operation 708, it may determined whether the data write overlaps with other data write on the application server storage.).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the disclosure of Savarese et al. in view of Gorsica, IV et al. and to implement with the feature as taught by Atluri et al. wherein the meta-data may be extracted by the application server and stored in application server storage.
The motivation would be to provide redundancy.
Allowable Subject Matter
Claim 3 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claims 6-8, 12, 14, 17, 19 would be allowable if rewritten to overcome the rejection(s) under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Kim et al. (Pub No.: 2014/0047543) discloses network attacks are detected by a protocol engine that works in conjunction with one or more streaming protocol analyzers. The protocol engine receives network packets over a computer network and generates metadata of the network packets. The metadata are placed in a transport envelope, which is streamed over the computer network. The transport envelope is received over the computer network. After receiving the transport envelope over the computer network, the metadata are extracted from the transport envelope and provided to the one or more streaming protocol analyzers, which analyze the metadata to detect network attacks.
Li et al. (Pub No.: 2018/0367620) discloses systems and methods for providing a session layer connection between two or more network endpoints. Session layer connections created and maintained using embodiments of the present disclosure use endpoint identifiers (EIDs) and allow for session layer continuity when a lower-layer connection is broken because of network failures or the movement of an endpoint from one network connection to another.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KAN YUEN whose telephone number is (571)270-1413. The examiner can normally be reached Monday - Friday 10:30am-7pm.
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, Ricky Ngo can be reached at 571-272-3139. 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.
/KAN YUEN/Primary Examiner, Art Unit 2464