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 .
Claims 1-20 and 35 are pending.
Claims 21-33 are cancelled.
Claim 35 in newly added.
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 12/30/2025 has been entered.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 34 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claim 34 recites “determine an extent of permission a user of the client device has to send data packets…to identify whether the data packet is permitted to be sent over the network”. However specification fails to explain how to determine an extent of permission a user…has”. How it has been determined. Specification fails to explain and define “extent of permission”. What exactly “extent of permission” means.
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.
The term “extent of permission” in claim 34 is a relative term which renders the claim indefinite. The term “extent of permission” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. The metes and bound of the term “extent of permission” it unclear.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20, 34 and 35 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
The claims when analyzed under 2019 Revised Patent Subject Matter Eligibility Guidance, are directed to abstract idea. Claim 1 for example, recites a method and, therefore, is a process. The claim recites the limitation of: "receiving…data packet"; “extracting data from the data packet”; “producing a fingerprint of the software application from the extracted data”; “comparing the fingerprint of the software application to a whitelist library of fingerprints of authorised software applications …”; “…permitting the data packet to proceed from the client to the destination…”. These limitations, under broadest reasonable interpretation are directed performance of the limitation in a human mind. That is, nothing in the claim element precludes the step from practically being performed in the mind. For example, the claim encompasses a human simply receiving…data packet; extracting data from the data packet; producing a fingerprint of the software application from the extracted data; comparing the fingerprint of the software application to a whitelist library of fingerprints of authorised software applications; …permitting the data packet to proceed from the client to the destination… Thus, the claim recites a mental process when analyzed under step 2A prong 1.
Claim is further analyzed in step 2A prong 2, to evaluate whether the claim as a whole integrates the recited judicial exception into a practical application of the exception. This evaluation is performed by identifying whether there are any additional elements recited in the claim beyond the judicial exception, and evaluating those additional elements individually and in combination to determine whether the claim as a whole integrates the exception into a practical application. However, each of the remaining limitation ("a network”), (“the client”), (“a destination”), (“computer network”), (“external network”), (“a gateway”) appears to be generic computer functions which do not constitute meaningful limitations that would amount to significantly more than the abstract idea. The combination of these additional element is no more than generic computer functions. Thus, even in combination, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limitations on practicing the abstract idea.
Claim is additionally analyzed under Step 2B to evaluates whether the claim as a whole amount to significantly more than the recited exception, whether any additional element, or combination of additional elements, adds an inventive concept to the claim. When claims evaluated under step 2B, it is no more than what is well-understood, routine, conventional activity in the field. The specification does not provide any indication anything other than a generic computer component. The mere “receiving…data packet; extracting data from the data packet; producing a fingerprint of the software application from the extracted data; comparing the fingerprint of the software application to a whitelist library of fingerprints of authorised software applications; …permitting the data packet to proceed from the client to the destination…" is a well-understood, routing and conventional function when it is claimed in a merely generic manner as it is here.
Regarding Claim 2, merely adds an additional abstract idea, namely stating that “denying the data packet….denying the data packet to proceed…” No additional elements are introduced in claim 2 that would integrate the judicial exception into a practical application. As a whole, claim 2 fails to integrate the judicial exception into a practical application is found non‐statutory under 35 U.S.C. 101 with the addition of the abstract idea.
Regarding Claim 3, merely adds an additional abstract idea, namely stating that “comparing the fingerprints to the blacklist library of fingerprints…so to identify…fingerprints is in the blacklist library”; “dropping the data packet….triggering further investigation…”. No additional elements are introduced in claim 3 that would integrate the judicial exception into a practical application. As a whole, claim 3 fails to integrate the judicial exception into a practical application is found non‐statutory under 35 U.S.C. 101 with the addition of the abstract idea.
Regarding Claim 4, merely adds an additional abstract idea, namely stating that “storing records…determining whether the client device is permitted to use the software application…”. No additional elements are introduced in claim 4 that would integrate the judicial exception into a practical application. As a whole, claim 4 fails to integrate the judicial exception into a practical application is found non‐statutory under 35 U.S.C. 101 with the addition of the abstract idea.
Regarding Claim 5, merely adds an additional abstract idea, namely stating that “applying rule or rule set to the whitelist library and blacklist library…”; “identifying whether the data packet is permitted to be sent over the network”. No additional elements are introduced in claim 5 that would integrate the judicial exception into a practical application. As a whole, claim 5 fails to integrate the judicial exception into a practical application is found non‐statutory under 35 U.S.C. 101 with the addition of the abstract idea.
Claim 6, merely adds an additional abstract idea, namely stating that “sending the fingerprint…returning an indication as to whether the fingerprint of the software application in in the whitelist…”. No additional elements are introduced in claim 6 that would integrate the judicial exception into a practical application. As a whole, claim 6 fails to integrate the judicial exception into a practical application is found non‐statutory under 35 U.S.C. 101 with the addition of the abstract idea.
Claim 7, merely adds an additional abstract idea, namely stating that “permitting or denying of the data traffic…”. No additional elements are introduced in claim 7 that would integrate the judicial exception into a practical application. As a whole, claim 7 fails to integrate the judicial exception into a practical application is found non‐statutory under 35 U.S.C. 101 with the addition of the abstract idea.
Claim 8, do not add any additional abstract ideas or elements as already present, respectively, in claims 1-7. For that reason, claims 8 is rejected using the same rational as claims 1-7.
Regarding Claim 9: recites a method and, therefore, is a process. The claim recites the limitation of: "permitting of data traffic…”; “receiving a transport layer security handshake data packet…”; extracting data from the packet”; “hashing the extracted data”; “comparing the hashed data to a list of hashes of software application that are not authorized to transmit data…”. These limitations, under broadest reasonable interpretation are directed performance of the limitation in a human mind or by human. That is, nothing in the claim element precludes the step from practically being performed in the mind or by human. For example, the claim encompasses a human simply permitting of data traffic…; receiving a transport layer security handshake data packet…; extracting data from the packet; hashing the extracted data; comparing the hashed data to a list of hashes of software application that are not authorized to transmit data… Thus, the claim recites a mental process when analyzed under step 2A prong 1.
Claim is further analyzed in step 2A prong 2, to evaluate whether the claim as a whole integrates the recited judicial exception into a practical application of the exception. This evaluation is performed by identifying whether there are any additional elements recited in the claim beyond the judicial exception, and evaluating those additional elements individually and in combination to determine whether the claim as a whole integrates the exception into a practical application. However, each of the remaining limitation ("a network”), (“a client device”), (“a destination”), (“computer network”), (“external network”), (“a gateway”) appears to be generic computer functions which do not constitute meaningful limitations that would amount to significantly more than the abstract idea. The combination of these additional element is no more than generic computer functions. Thus, even in combination, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limitations on practicing the abstract idea.
Claim is additionally analyzed under Step 2B to evaluates whether the claim as a whole amount to significantly more than the recited exception, whether any additional element, or combination of additional elements, adds an inventive concept to the claim. When claims evaluated under step 2B, it is no more than what is well-understood, routine, conventional activity in the field. The specification does not provide any indication anything other than a generic computer component. The mere "permitting of data traffic…”; “receiving a transport layer security handshake data packet…”; extracting data from the packet”; “hashing the extracted data”; “comparing the hashed data to a list of hashes of software application that are not authorized to transmit data…” is a well-understood, routing and conventional function when it is claimed in a merely generic manner as it is here.
Regarding Claim 10, merely adds an additional abstract idea, namely stating that “disallowing the handshake data packet to be transmitted over the network in the event that the hashed data is on the list of hashes of applications that are not authorised on the network…”. No additional elements are introduced in claim 10 that would integrate the judicial exception into a practical application. As a whole, claim 10 fails to integrate the judicial exception into a practical application is found non‐statutory under 35 U.S.C. 101 with the addition of the abstract idea.
Regarding Claim 11, merely adds an additional abstract idea, namely stating that “comparing the hashed data to a list of hashes of application that are authorized to be transmitted…”. No additional elements are introduced in claim 11 that would integrate the judicial exception into a practical application. As a whole, claim 11 fails to integrate the judicial exception into a practical application is found non‐statutory under 35 U.S.C. 101 with the addition of the abstract idea.
Regarding Claim 12, merely adds an additional abstract idea, namely stating that “disallowing the handshake data packet to be transmitted over the network in the event that the hashed data is not on the list of hashes of applications that are authorised on the network.” No additional elements are introduced in claim 12 that would integrate the judicial exception into a practical application. As a whole, claim 12 fails to integrate the judicial exception into a practical application is found non‐statutory under 35 U.S.C. 101 with the addition of the abstract idea.
Regarding Claim 13, merely adds an additional abstract idea, namely stating that “permitting data traffic over a network…”; “receiving a transport layer security handshake data packet…”; “extracting data from the packet.” “hashing the extracted data”. “comparing the hashed data to a list of hashes of applications that are authorised to be transmitted over the network”. No additional elements are introduced in claim 13 that would integrate the judicial exception into a practical application. As a whole, claim 13 fails to integrate the judicial exception into a practical application is found non‐statutory under 35 U.S.C. 101 with the addition of the abstract idea.
Regarding Claim 14, merely adds an additional abstract idea, namely stating that “disallowing the handshake data packet to be transmitted over the network to the destination in the event that the hashed data is not on the list of hashes of applications that are authorised on the network” No additional elements are introduced in claim 14 that would integrate the judicial exception into a practical application. As a whole, claim 14 fails to integrate the judicial exception into a practical application is found non‐statutory under 35 U.S.C. 101 with the addition of the abstract idea.
Regarding Claim 15, merely adds an additional abstract idea, namely stating that “the list of hashes is determined…” No additional elements are introduced in claim 15 that would integrate the judicial exception into a practical application. As a whole, claim 15 fails to integrate the judicial exception into a practical application is found non‐statutory under 35 U.S.C. 101 with the addition of the abstract idea.
Regarding Claim 16, recites a device and, therefore, is a apparatus. The claim recites the limitation of: "permitting of data traffic…”; “receiving a transport layer security handshake data packet…”; extracting data from the received packet”; “producing a fingerprint of the extracted data”; “comparing the fingerprint to a whitelist library of fingerprints of authorised software applications so as to identify whether the fingerprint is in the whitelist library…”; “an output for signalling the data packet from the client is permitted to proceed from the client device to the destination…”. These limitations, under broadest reasonable interpretation are directed performance of the limitation in a human mind or by human. That is, nothing in the claim element precludes the step from practically being performed in the mind. For example, the claim encompasses a human simply "permitting of data traffic…”; “receiving a transport layer security handshake data packet…”; extracting data from the received packet”; “producing a fingerprint of the extracted data”; “comparing the fingerprint to a whitelist library of fingerprints of authorised software applications so as to identify whether the fingerprint is in the whitelist library…”; “an output for signalling the data packet from the client is permitted to proceed from the client device to the destination…”. Thus, the claim recites a mental process when analyzed under step 2A prong 1.
Claim is further analyzed in step 2A prong 2, to evaluate whether the claim as a whole integrates the recited judicial exception into a practical application of the exception. This evaluation is performed by identifying whether there are any additional elements recited in the claim beyond the judicial exception, and evaluating those additional elements individually and in combination to determine whether the claim as a whole integrates the exception into a practical application. However, each of the remaining limitation (“a device”), (“a computer network”), (“a processor”), ("a network”), (“a client device”), (“a destination”), (“computer network”), (“external network”), (“a gateway”) appears to be generic computer functions which do not constitute meaningful limitations that would amount to significantly more than the abstract idea. The combination of these additional element is no more than generic computer functions. Thus, even in combination, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limitations on practicing the abstract idea.
Claim is additionally analyzed under Step 2B to evaluates whether the claim as a whole amount to significantly more than the recited exception, whether any additional element, or combination of additional elements, adds an inventive concept to the claim. When claims evaluated under step 2B, it is no more than what is well-understood, routine, conventional activity in the field. The specification does not provide any indication anything other than a generic computer component. The mere "permitting of data traffic…”; “receiving a transport layer security handshake data packet…”; extracting data from the received packet”; “producing a fingerprint of the extracted data”; “comparing the fingerprint to a whitelist library of fingerprints of authorised software applications so as to identify whether the fingerprint is in the whitelist library…”; “an output for signalling the data packet from the client is permitted to proceed from the client device to the destination…” is a well-understood, routing and conventional function when it is claimed in a merely generic manner as it is here.
Regarding Claim 17, merely adds an additional abstract idea, namely stating that “wherein the signalling is also that the data packet signalled as being permitted is data traffic…” No additional elements are introduced in claim 15 that would integrate the judicial exception into a practical application. As a whole, claim 15 fails to integrate the judicial exception into a practical application is found non‐statutory under 35 U.S.C. 101 with the addition of the abstract idea.
Regarding Claim 18, merely adds an additional abstract idea, namely “the data traffic related to the transport layer security handshake data packet is traffic directed to a network connected service having a destination address included in the extracted data”. No additional elements are introduced in claim 18 that would integrate the judicial exception into a practical application. As a whole, claim 18 fails to integrate the judicial exception into a practical application is found non‐statutory under 35 U.S.C. 101 with the addition of the abstract idea.
Regarding Claim 19, merely adds an additional abstract idea, namely “the output is further configured to signal data is not permitted to proceed through the network or through the gateway to the external network when the fingerprint is not in the whitelist library”. No additional elements are introduced in claim 19 that would integrate the judicial exception into a practical application. As a whole, claim 19 fails to integrate the judicial exception into a practical application is found non‐statutory under 35 U.S.C. 101 with the addition of the abstract idea.
Regarding Claim 20, merely adds an additional abstract idea, namely “wherein the processor is configured to compare the fingerprint produced from the extracted data to those fingerprints in the whitelist library that specifies authorised software applications that the client device is permitted to send over the network according to an identity of a user of the client device”. No additional elements are introduced in claim 20 that would integrate the judicial exception into a practical application. As a whole, claim 20 fails to integrate the judicial exception into a practical application is found non‐statutory under 35 U.S.C. 101 with the addition of the abstract idea.
Regarding Claim 34, merely adds an additional abstract idea, namely “wherein the list of hashes is determined according to the identity of the client”. No additional elements are introduced in claim 34 that would integrate the judicial exception into a practical application. As a whole, claim 34 fails to integrate the judicial exception into a practical application is found non‐statutory under 35 U.S.C. 101 with the addition of the abstract idea.
Regarding Claim 35, merely adds an additional abstract idea, namely “applying a rule or rule set to the fingerprint to determine an extent of permission a user of the client device has… send data packets… identify whether the data packet is permitted to be sent over the network”. No additional elements are introduced in claim 34 that would integrate the judicial exception into a practical application. As a whole, claim 34 fails to integrate the judicial exception into a practical application is found non‐statutory under 35 U.S.C. 101 with the addition of the abstract idea.
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 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) 1-3, 5-8, and 16, 35 are rejected under 35 U.S.C. 103 as being unpatentable over Lam et al (U. S. PGPub. No. 2019/0089678 A1) (hereinafter “Lam”) in view of Wang et al, (U. S. Pat. No. 10,805,320 B1) (hereinafter “Wang”) and Krishnamurthy et al. (U. S. Pat. No. 6,760,343 B1) (hereinafter “Krishnamurthy”).
Regarding claim 1, Lam teaches:
a method of permitting data traffic over a network, comprising (Lam: [0017] Firewalls typically deny or permit network transmission based on a set of rules. These sets of rules are often referred to as policies (e.g., security policies, which can also include network policies and/or network security policies). For example, a firewall can filter inbound traffic by applying a set of rules or policies to prevent unwanted outside traffic from reaching protected devices. A firewall can also filter outbound traffic by applying a set of rules or policies (e.g., allow, block, monitor, notify, log, and/or other actions can be specified in firewall rules or firewall policies, which can be triggered based on various criteria, such as described herein). the absence of a valid process ID association for a network session is an abnormality that a firewall can use to detect and block such traffic. [0040] In this example, the firewall can utilize the process ID information to apply a fine-grained security policy. For instance, the firewall can apply a fine-grained security policy that determines whether a process executed on an EP is allowed to access a certain resource on the enterprise network, in which a match operation on the digest can be performed to identify if the process is benign/known, malicious, or unknown, and whether for benign/known process matches that such processes may be allowed to access the resource being protected by the firewall);
producing a fingerprint of the software application from the extracted data (Lam: [0052] Digests generated for application programs and other executables can change when the application programs/executables are updated. [0039] In one embodiment, the process ID information is stored as a digest of the…executable associated with the process that initiated the network session (e.g., using a hash function, such as MD5, SHA-2, (=fingerprint of the software application) or another hash function performed by the agent on the EP)).
comparing the fingerprint of the software application to a whitelist library of fingerprints of authorized software applications so as to identify whether the fingerprint is in the whitelist library (Lam: [0040], a match operation on the digest can be performed to identify if the process is benign/known, malicious, or unknown, and whether for benign/known process matches that such processes may be allowed to access the resource being protected by the firewall [0046] As another example, a match based on process ID information can be performed at the network device firewall to determine whether process ID information is an unknown process and/or a malware process, and a policy can be applied to block unknown processes and/or a malware process (e.g., a digest for the process does not match a known, trusted executable/application (=whitelist)and/or does match previously identified malware executable) from access to protected resources on the enterprise network),
in the event that the fingerprint is in the whitelist library (Lam: [0057] In some embodiments, integration with a security service to identify benign or malware processes is provided for enhanced security. For example, a list of known binary digests can be provided to a firewall from a security service (e.g., a commercially available security service, such as the WildFire™ cloud-based malware analysis environment provided by Palo Alto Networks®), and the firewall can match them to a list of approved(=whitelist)/denied APP IDs for those processes.), one or both of: within the network permitting the data packet to proceed from the client to the destination over the network (Lam: [0056] Integration with a Security Service to Identify Benign or Malware Processes. [0069] In some embodiments, selective punting (e.g., tunneling) of network traffic is performed based on process ID information associated with the network traffic. For example, a known/trusted/whitelisted process ID digest (e.g., based on an EP security policy) can be allowed to continue to its destination on a shortest path);
And when the destination is reached via connected external network permitting the data packet to proceed from the client to the destination before the data packet exits the network for the destination via a gateway to the connected external network (Lam: [0016], A firewall generally protects networks from unauthorized access while permitting authorized communications to pass through the firewall. [0017], Firewalls typically deny or permit network transmission based on a set of rules. These sets of rules are often referred to as policies (e.g., security policies, which can also include network policies and/or network security policies). For example, a firewall can filter inbound traffic by applying a set of rules or policies to prevent unwanted outside traffic from reaching protected devices).
Lam does not explicitly disclose, however in an analogous art Wang discloses:
receiving a transport layer security handshake data packet sent over a computer network from a software application running on a client device from within the computer network (Wang: [Col 4, lines 35-38], During the handshake phase, the network security device 230 may receive a Client Hello message from the TLS application 211 running on the client device 250-1. [Col 5, lines 10-18], (26) The TLS cryptographic protocol has a handshake phase during which the client and the server agrees on a cryptographic algorithm and other connection setup, and a data transfer phase during which encrypted data is transmitted between the client and the server. In the example of FIG. 3, during the handshake phase, the agent 210 receives a client handshake message in the form of a Client Hello message that is sent by a TLS application 211 running on the client device 250 (step 301)) before the data packet proceed to a destination (Wang:(Col 7, lines lines 54-58], (42) In one embodiment, in each enterprise computer network 220, a network security device 230 receives all network traffic between client devices 250 of the enterprise computer network 220 and external server devices. This allows the network security device 230 to inspect, and block if needed, network traffic going into and out of the enterprise computer network 220… Examiner’s Note: In the cited paragraph “the network security device inspect, and block if needed, network traffic going into and out of the enterprise computer network. It means traffic is getting inspected before it going into or out of enterprise network (=internal network). This process is happening within the enterprise network which read on claimed limitation.)
It would be obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to modify Lam’s method of generating digest of application program and based on comparing hash, determine whether data traffic allowed to pass through firewall or block the data transmission by applying Wang’s method of receiving a client hello message sent by TLS application which is running on the client device in order to inspecting network traffic (Wang: [Col 1, line 10])
Lam in view of Wang does not explicitly disclose extracting data from the data packet;
however, in an analogous art, Krishnamurthy discloses:
extracting data from the data packet (Krishnamurthy: [Col15, lines 42-47], (60) With reference now to FIG. 25, a flowchart of a process for extracting a message from a data packet is depicted in accordance with a preferred embodiment of the present invention. This process begins by receiving a data packet (step 2500). The gateway header and message are extracted from the payload portion of the data packet (step 2502) [Col 2, lines 35-37], (11) The link or connection may be to another gateway or to a node, which extracts the message and header information from the data packet. [Col 11, lines 44-47], This message is in the form of a data packet used for transport on an IP network….the message is extracted from the data field in the data packets (step 1202))
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Lam in view of Wang by applying the well-known technique as disclosed by Krishnamurthy’s method of extracting a message from a data packet in order to provide improved method for sending and receiving massages between two nodes in a communication system (Krishnamurthy: [Col 1, lines 9-11])
Regarding Claim 35, Lam in view of Wang and Krishnamurthy teaches:
The method of claim 1 (see rejection of claim 1 above),
applying a rule or rule set to the fingerprint to determine an extent of permission a user of the client device has to send data packets from each of a plurality of software applications to identify whether the data packet is permitted to be sent over the network (Lam: [0038], The firewall can then implement a fine-grained security policy based on APP ID and process ID information…[0039], the process ID information is stored as a digest of the file name of the binary/executable associated with the process that initiated the network session (e.g., using a hash function, such as MD5, SHA-2, or another hash function performed by the agent on the EP) [0040], the firewall can utilize the process ID information to apply a fine-grained security policy. For instance, the firewall can apply a fine-grained security policy that determines whether a process executed on an EP is allowed to access a certain resource on the enterprise network, in which a match operation on the digest can be performed to identify if the process (=data traffic) is benign/known, malicious, or unknown, and whether for benign/known process matches that such processes may be allowed to access the resource being protected by the firewall.).
Regarding claim 2, Lam in view of Wang and Krishnamurthy teaches,
The method of claim 1 (see rejection of claim 1 above),
in the event that the fingerprint is not in the whitelist library (Lam: [0063], the firewall/network device performs a responsive action (e.g., allow, block/drop, hold/quarantine, log, throttle, and/or perform other responsive actions) based on a fine-grained security policy using the correlated APP ID and process ID information (e.g., and in some cases, in combination with other information), within the network denying data packet proceeding from the client to the destination over the network and/or (Lam: [0069]…unknown/untrusted/blacklisted process ID digest (e.g., based on the EP security policy) can be punted/redirected to a designated firewall for further inspection as further described below) denying the data packet to proceed from the client to the connected external network (Lam: [0095] FIG. 3 is a diagram illustrating another network architecture for providing fine-grained policy enforcement and/or outbound/inbound lateral traffic punting based upon process risk in accordance with some embodiments. As shown in FIG. 3, client devices 304A, 304B, and 304C are in communication with the Internet 306 (=external network) and various web sites, cloud services, and/or other remote servers/sites shown as servers 308A-C via a network device 302 (e.g., a data appliance, such as similarly described above with respect to FIG. 2).).
Regarding claim 3, Lam in view of Wang and Krishnamurthy teaches:
The method of claim 1 (see rejection of claim 1 above),
comparing the fingerprint to a blacklist library of fingerprints of unauthorized software applications so as to identify whether the fingerprint is in the blacklist library (Lam: [0110], network device 602 is in communication with security service 610, and, in some cases, the network device provides the correlated APP ID and process ID information (e.g., the malware process and digest mapping, and potentially other information, such as user ID, content ID, URL, and/or other information) to the security service, which can perform further analysis of the process (e.g., the security service can provide a verdict based on determining whether the process is malware (and should be added to a blacklist of unauthorized processes for the associated APP ID) or is known/trusted (and should be added to a whitelist of authorized processes for the associated APP ID))
wherein in the event that the fingerprint is in the blacklist library dropping the data packet either when it is in the network or before it exits the network via gateway (Lam: [0069] In some embodiments, selective punting (e.g., tunneling) of network traffic is performed based on process ID information associated with the network traffic. For example, a known/trusted/whitelisted process ID digest (e.g., based on an EP security policy) can be allowed to continue to its destination on a shortest path, whereas an unknown/untrusted/blacklisted process ID digest (e.g., based on the EP security policy) can be punted/redirected to a designated firewall for further inspection as further described below)
wherein in the event that the fingerprint is not in the whitelist library or the blacklist library (Lam: [0046], a policy can be applied to block unknown processes and/or a malware process (e.g., a digest for the process does not match a known, trusted executable/application and/or does match previously identified malware executable) from access to protected resources on the enterprise network. In this example, Trojanware (e.g., previously identified Trojanware or new, not yet identified Trojanware) can be blocked from attempting to modify passwords for user accounts on protected resources), then the method further comprises triggering further investigation of the software application (Lam: [0047], a network session associated with an unknown process or session from Eps (e.g., EP devices) without a trusted agent installed (e.g., an Internet of Things (IoT) device or guest device on the enterprise network) may be blocked from accessing sensitive servers and flagged for extended inspections (=triggering further investigation of the software application)…)
Regarding claim 5, Lam in view of Wang and Krishnamurthy teaches:
The method of claim 3 (see rejection of claim 3 above),
applying a rule or rule set to the whitelist library and blacklist library to define an extent of permission the client device has to send further data packets from each of a plurality of software applications identify whether the data packet is permitted to be the sent over the network. (Lam: [0038], The firewall can then implement a fine-grained security policy based on APP ID and process ID information…[0039], the process ID information is stored as a digest of the file name of the binary/executable associated with the process that initiated the network session (e.g., using a hash function, such as MD5, SHA-2, or another hash function performed by the agent on the EP) [0040], the firewall can utilize the process ID information to apply a fine-grained security policy. For instance, the firewall can apply a fine-grained security policy that determines whether a process executed on an EP is allowed to access a certain resource on the enterprise network, in which a match operation on the digest can be performed to identify if the process (=data traffic) is benign/known, malicious, or unknown, and whether for benign/known process matches that such processes may be allowed to access the resource being protected by the firewall).
Regarding claim 7, Lam in view of Wang and Krishnamurthy teaches:
The method of claim 6 (see rejection of claim 6 above),
permitting or denying of data traffic is performed by an intrusion security device on the network (Lam: [0069] In some embodiments, selective punting (e.g., tunneling) of network traffic is performed based on process ID information associated with the network traffic. For example, a known/trusted/whitelisted process ID digest (e.g., based on an EP security policy) can be allowed to continue to its destination on a shortest path, whereas an unknown/untrusted/blacklisted process ID digest (e.g., based on the EP security policy) can be punted/redirected to a designated firewall for further inspection as further described below)
Regarding claim 8, Lam in view of Wang and Krishnamurthy teaches:
The method of claim 7 (see rejection of claim 7 above),
wherein the computer network is a secured local network and when the destination is reached via the connected external network (Lam: [0094] In one embodiment, data appliance 202 includes a firewall component, such as firewall 100 as described above, to protect the network and clients within the protected network 210, which is in communication with the Internet 214 and various servers, such as servers 216, 218, and 220 (e.g., web servers, mail servers, file servers, and/or other types of servers),
the indication as to whether the software application is on the whitelist is provided to the intrusion security device (Lam: [0087], A known protocol decoder engine 112 decodes and analyzes traffic flows using known protocols (e.g., a known protocol decoder component of firewall 100 for applying various signatures for the known protocol) and reports (=indication) the monitored traffic analysis to a report and enforce policy engine 120 (e.g., a report and enforce policy component of firewall 100 for performing reporting and enforcement actions based on a policy, such as further described below). Identified traffic (no decoding required) engine 114 reports the identified traffic to the report and enforce policy engine 120), within the secured local network, and when the data packet is permitted to proceed from the client to the destination, the data packet proceeds from the intrusion security device via the gateway to the connected external network and traverses the external network to the destination (Lam: [0017] Firewalls typically deny or permit network transmission based on a set of rules. These sets of rules are often referred to as policies (e.g., security policies, which can also include network policies and/or network security policies). For example, a firewall can filter inbound traffic by applying a set of rules or policies to prevent unwanted outside traffic from reaching protected devices. A firewall can also filter outbound traffic by applying a set of rules or policies (e.g., allow, block, monitor, notify, log, and/or other actions can be specified in firewall rules or firewall policies, which can be triggered based on various criteria, such as described herein).
Regarding claim 16, Lam discloses:
A network connection (Lam: [0093], FIG. 2 is a diagram of a network architecture…a data appliance 202 (e.g., a network device that includes security functions, such as a security appliance/device that includes a firewall, a gateway that includes security functions, such as a security gateway, a server that includes security functions, and/or any other network device that includes a firewall function as described herein) is at the perimeter of a protected network 210, which includes clients 204, 206, and 208 (e.g., desktop computers, laptop computers, tablet computers/tablets, smart phones, and/or other types of client devices that can access data on enterprise network 210 using network communications (wired or wireless network communications, and/or can transfer data from the client device and/or other devices on enterprise network 210 to a local storage, such as a portable storage device/USB storage device) [0095] As shown in FIG. 3, client devices 304A, 304B, and 304C are in communication with the Internet 306 and various web sites, cloud services, and/or other remote servers/sites shown as servers 308A-C via a network device 302 (e.g., a data appliance, such as similarly described above with respect to FIG. 2).);
A processor (Lam: [0014], a processor, such as a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor).
This claim contains identical limitations found within that of claim 1 above albeit directed to a different statutory category (apparatus claim), and for this reason the same rationale of rejection is used where applicable grounds of rejection are applied to claim 16.
Claim(s) 4, 6, 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Lam et al (U. S. PGPub. No. 2019/0089678 A1) (hereinafter “Lam”) in view of Wang et al. (U. S. Pat. No. 10,805,320 B1) (hereinafter “Wang”) and Krishnamurthy et al. (U. S. Pat. No. 6,760,343 B1) (hereinafter “Krishnamurthy”); and in further view of ALTHOUSE et al (US 2018/0324153 A1) (hereinafter “Althouse").
Regarding claim 4, Lam in view of Wang and Krishnamurthy teaches:
The method of claim 1 (see rejection of claim 1 above),
Lam in view of Wang and Krishnamurthy does not explicitly disclose:
determining whether the client device is permitted to use the software application on the network according to the identified fingerprint and in the event that the device is permitted to use the software application on the network allowing the handshake data packet to be transmitted over the network;
However, in an analogous art, Althouse teaches:
determining whether the client device is permitted to use the software application on the network according to the identified fingerprint and in the event that the device is permitted to use the software application on the network allowing the handshake data packet to be transmitted over the network (Althouse: [0041], The database system 210 may be configured to include metadata for at least some of the stored fingerprint records, for example, indicating timestamps, IP address, or a security indicator such as “OK” (permit access))
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Lam in view of Wang and Krishnamurthy by applying the well-known technique as disclosed by Alhouse’e method of hashing extracted data. The motivation is to generate client fingerprints by applying hash function to client ID)
Regarding claim 6, Lam in view of Wang and Krishnamurthy teaches:
The method of claim 1 (see rejection of claim 1 above),
Lam in view of Wang and Krishnamurthy does not explicitly disclose:
sending the fingerprint from a sniffing device on the network to a remote service for comparing to the whitelist library of fingerprints of authorized software applications, and returning an indication as to whether the fingerprint of the software application is in the whitelist from the remote service to the sniffing device;
However, Althouse teaches:
sending the fingerprint from a sniffing device on the network to a remote service for comparing to the whitelist library of fingerprints of authorized software applications, and returning an indication as to whether the fingerprint of the software application is in the whitelist from the remote service to the sniffing device (Althouse: [0051] FIG. 3 shows a simplified flow diagram of an example process for fingerprinting a client based on a Transport Layer Security (TLS) or SSL client hello packet. The first step calls for monitoring packet data traffic over a network, step 302. Various tools such as Bro are known for this function. Another option may be Wireshark (=sniffing device), a network packet analyzer. Next is detecting a client hello packet CHP received from a client seeking to begin a session, step 304.)
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Lam in view of Wang and Krishnamurthy by applying the well-known technique as disclosed by Alhouse’e method of hashing extracted data. The motivation is to generate client fingerprints by applying hash function to client ID).
Regarding claim 17, Lam and Wang and Krishnamurthy teaches:
The method of claim 16 (see rejection of claim 16 above) teaches,
Lam, Wang and Krishnamurthy does not explicitly disclose:
wherein the signalling is also that the data packet signalled as being permitted is data traffic related to transport layer security handshake data packet;
However, Althouse teaches:
wherein the signalling is also that the data packet signalled as being permitted is data traffic related to transport layer security handshake data packet (Althouse: [0009] FIG. 3 shows a simplified flow diagram of an example process for fingerprinting a client based on a Transport Layer Security (TLS) client hello packet).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Lam in view of Wang and Krishnamurthy by applying the well-known technique as disclosed by Alhouse’e method of hashing extracted data. The motivation is to generate client fingerprints by applying hash function to client ID)
Regarding claim 18, Lam and Wang, Krishnamurthy and Althouse teaches:
The method of claim 17 (see rejection of claim 17 above),
wherein the data traffic related to the transport layer security handshake data packet is traffic directed to a network connected service having a destination address included in the extracted data (Althouse: [0041] Selected elements of FIGS. 1A and 1B are shown in FIG. 2, with the reference numbers retained. A fingerprint system 205 may be coupled to a fingerprint database system 210. The database 210 may be configured to store client fingerprints generated by the system 205 based on SSL client sessions that traverse the network 14 from a client 220 to access the system 16 as explained in more detail below. The database system 210 may be configured to include metadata for at least some of the stored fingerprint records, for example, indicating timestamps, IP address, or a security indicator such as “OK” (permit access), “Block Access,” “Suspicious” etc.).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Lam in view of Wang and Krishnamurthy by applying the well-known technique as disclosed by Alhouse’e method of hashing extracted data. The motivation is to generate client fingerprints by applying hash function to client ID)
Regarding claim 19, Lam and Wang and Krishnamurthy teaches:
The method of claim 16 (see rejection of claim 16 above),
Lam and Krishnamurthy does not explicitly disclose:
wherein the output is further configured to signal data traffic related to the software application from the client device is not permitted to send the data packet over the network when in the event that the fingerprint is not in the whitelist library;
However, Althouse teaches:
wherein the output is further configured to signal data packet is not permitted to proceed through the network or through the gateway to the external network when in the event that the fingerprint is not in the whitelist library (Althouse: [0041] Selected elements of FIGS. 1A and 1B are shown in FIG. 2, with the reference numbers retained. A fingerprint system 205 may be coupled to a fingerprint database system 210. The database 210 may be configured to store client fingerprints generated by the system 205 based on SSL client sessions that traverse the network 14 from a client 220 to access the system 16 as explained in more detail below. The database system 210 may be configured to include metadata for at least some of the stored fingerprint records, for example, indicating timestamps, IP address, or a security indicator such as “OK” (permit access), “Block Access,” “Suspicious” etc.).)
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Lam in view of Wang and Krishnamurthy by applying the well-known technique as disclosed by Alhouse’e method of hashing extracted data. The motivation is to generate client fingerprints by applying hash function to client ID).
Claim(s) 9, 11, 13, 15, and 34 are rejected under 35 U.S.C. 103 as being unpatentable over Lam et al (U. S. PGPub. No. 2019/0089678 A1) (hereinafter “Lam”) in view of Wang et al. (U. S. Pat. No. 10,805,320 B1) (hereinafter “Wang”) and Krishnamurthy et al. (U. S. Pat. No. 6,760,343 B1) (hereinafter “Krishnamurthy”); and in further view of ALTHOUSE et al (US 2018/0324153 A1) (hereinafter “Althouse) in view of Bohannon (U. S. Pat. No. 9,787,643 B2) (hereinafter “Bohannon”)
Regarding Claim 9, Lam teaches:
a method of permitting data traffic over a network, comprising (Lam: [0017] Firewalls typically deny or permit network transmission based on a set of rules. These sets of rules are often referred to as policies (e.g., security policies, which can also include network policies and/or network security policies). For example, a firewall can filter inbound traffic by applying a set of rules or policies to prevent unwanted outside traffic from reaching protected devices. A firewall can also filter outbound traffic by applying a set of rules or policies (e.g., allow, block, monitor, notify, log, and/or other actions can be specified in firewall rules or firewall policies, which can be triggered based on various criteria, such as described herein). the absence of a valid process ID association for a network session is an abnormality that a firewall can use to detect and block such traffic. [0040] In this example, the firewall can utilize the process ID information to apply a fine-grained security policy. For instance, the firewall can apply a fine-grained security policy that determines whether a process executed on an EP is allowed to access a certain resource on the enterprise network, in which a match operation on the digest can be performed to identify if the process is benign/known, malicious, or unknown, and whether for benign/known process matches that such processes may be allowed to access the resource being protected by the firewall)
Lam does not explicitly disclose:
receiving a transport layer security handshake data packet sent over a computer network from a software application running on a client device from within the computer network before the data packet proceed to a destination;
However, in analogous art Wang disclose:
receiving a transport layer security handshake data packet from a client device sent over a network (Wang: [Col 4, lines 35-38], During the handshake phase, the network security device 230 may receive a Client Hello message from the TLS application 211 running on the client device 250-1. [Col 5, lines 10-18], (26) The TLS cryptographic protocol has a handshake phase during which the client and the server agrees on a cryptographic algorithm and other connection setup, and a data transfer phase during which encrypted data is transmitted between the client and the server. In the example of FIG. 3, during the handshake phase, the agent 210 receives a client handshake message in the form of a Client Hello message that is sent by a TLS application 211 running on the client device 250 (step 301)) before it proceeds to a destination outside of the network via a gateway to an external network (Wang:(Col 7, lines lines 54-58], (42) In one embodiment, in each enterprise computer network 220, a network security device 230 receives all network traffic between client devices 250 of the enterprise computer network 220 and external server devices. This allows the network security device 230 to inspect, and block if needed, network traffic going into and out of the enterprise computer network 220… Examiner’s Note: In the cited paragraph “the network security device inspect, and block if needed, network traffic going into and out of the enterprise computer network. It means traffic is getting inspected before it going into or out of enterprise network (=internal network). This process is happening within the enterprise network which read on claimed limitation.)
It would be obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to modify Lam’s method of generating digest of application program and based on comparing hash, determine whether data traffic allowed to pass through firewall or block the data transmission by applying Wang’s method of receiving a client hello message sent by TLS application which is running on the client device in order to inspecting network traffic (Wang: [Col 1, line 10])
Lam in view of Wang does not explicitly disclose:
extracting data from the packet;
hashing the extracted data;
comparing the hashed data to a list of hashes of applications that are not authorized to transmit data over the network.
However, Krishnamurthy teaches:
extracting data from the packet (Krishnamurthy: [Col15, lines 42-47], (60) With reference now to FIG. 25, a flowchart of a process for extracting a message from a data packet is depicted in accordance with a preferred embodiment of the present invention. This process begins by receiving a data packet (step 2500). The gateway header and message are extracted from the payload portion of the data packet (step 2502) [Col 2, lines 35-37], (11) The link or connection may be to another gateway or to a node, which extracts the message and header information from the data packet. [Col 11, lines 44-47], This message is in the form of a data packet used for transport on an IP network….the message is extracted from the data field in the data packets (step 1202))
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Lam in view of Wang by applying the well-known technique as disclosed by Krishnamurthy’s method of extracting a message from a data packet in order to provide improved method for sending and receiving massages between two nodes in a communication system (Krishnamurthy: [Col 1, lines 9-11]).
Lam in view of Wang Krishnamurthy does not explicitly disclose:
hashing the extracted data;
comparing the hashed data to a list of hashes of applications that are not authorized to transmit data over the network.
However, in an analogous art, Althouse teaches:
hashing the extracted data (Althouse: [0051] In some embodiments, the mapping of step 310 may apply a hash function to the client ID to form the client fingerprint. In one embodiment, the hash function may return a fingerprint (a string of characters) 32 characters long);
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Lam in view of Wang and Krishnamurthy by applying the well-known technique as disclosed by Althouse’e method of hashing extracted data. The motivation is to generate client fingerprints by applying hash function to client ID).
The Lam in view of Wang, Krishnamurthy and Althouse does not explicitly disclose:
comparing the hashed data to a list of hashes of applications that are not authorized to transmit data over the network.
However, in an analogous art, Bohannon teaches:
comparing the hashed data to a list of hashes of software applications that are not authorized to transmit data over the network (Bohannon: [Col 3, lines 62-64], The client hello message can also include a cipher suite (=list of hashes), which is a list of ciphers schemes available on the client device 106. [Col 9, lines 1-7], In these embodiments, at block 324, the client proxy 304 can determine which of the predicted cipher suites matches the selected cipher suite in the server certificate. If a match is found, the client proxy 304 can then generate and send the matching client key exchange message to the server device 306.)
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Lam in view of Wang, Krishnamurthy and Althouse by applying the well-known technique as disclosed by Bohannon’s method of determine which of the predicted cipher suites matches the selected cipher suite in the server certificate. The motivation is to allows client/server applications to detect the security risks, such as message tampering, message interception, and message forgery (Bohannon:[Col 1, lines 30-33]).
Regarding Claim 11, the combination Lam in view of Wang, Krishnamurthy and Althouse, Bohannon teaches:
The method of claim 9 (see rejection of claim 9 above),
comparing the hashed data to a list of hashes of applications that are authorized to be transmitted over on the network (Bohannon: [Col 6, lines 19-24], (29) The client finished message is a hash of the entire conversation thus far, which provides further authentication of the client device 106. This message is a verification that the client device 106, who is sending the client finished message is truly the client device 106 who sent the client hello message).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Lam in view of Wang, Krishnamurthy and Althouse by applying the well-known technique as disclosed by Bohannon’s method of message verification in order to determine the authenticate client device which is trying to communicate with the server. The motivation is to allows client/server applications to detect the security risks, such as message tampering, message interception, and message forgery (Bohannon:[Col 1, lines 30-33]).
Regarding Claim 13, Lam discloses:
a method of permitting data traffic over a network, comprising (Lam: [0017] Firewalls typically deny or permit network transmission based on a set of rules. These sets of rules are often referred to as policies (e.g., security policies, which can also include network policies and/or network security policies). For example, a firewall can filter inbound traffic by applying a set of rules or policies to prevent unwanted outside traffic from reaching protected devices. A firewall can also filter outbound traffic by applying a set of rules or policies (e.g., allow, block, monitor, notify, log, and/or other actions can be specified in firewall rules or firewall policies, which can be triggered based on various criteria, such as described herein). the absence of a valid process ID association for a network session is an abnormality that a firewall can use to detect and block such traffic. [0040] In this example, the firewall can utilize the process ID information to apply a fine-grained security policy. For instance, the firewall can apply a fine-grained security policy that determines whether a process executed on an EP is allowed to access a certain resource on the enterprise network, in which a match operation on the digest can be performed to identify if the process is benign/known, malicious, or unknown, and whether for benign/known process matches that such processes may be allowed to access the resource being protected by the firewall):
Lam does not explicitly disclose:
receiving a transport layer security handshake data packet from a client device sent over a network before the data packet proceeds to a destination outside of the network via a gateway to an external network ;
However Wang teaches:
receiving a transport layer security handshake data packet from a client device sent over a network (Wang: [Col 4, lines 35-38], During the handshake phase, the network security device 230 may receive a Client Hello message from the TLS application 211 running on the client device 250-1. [Col 5, lines 10-18], (26) The TLS cryptographic protocol has a handshake phase during which the client and the server agrees on a cryptographic algorithm and other connection setup, and a data transfer phase during which encrypted data is transmitted between the client and the server. In the example of FIG. 3, during the handshake phase, the agent 210 receives a client handshake message in the form of a Client Hello message that is sent by a TLS application 211 running on the client device 250 (step 301)) before the data packet proceeds to a destination outside of the network via a gateway to an external network (Wang:(Col 7, lines lines 54-58], (42) In one embodiment, in each enterprise computer network 220, a network security device 230 receives all network traffic between client devices 250 of the enterprise computer network 220 and external server devices. This allows the network security device 230 to inspect, and block if needed, network traffic going into and out of the enterprise computer network 220… Examiner’s Note: In the cited paragraph “the network security device inspect, and block if needed, network traffic going into and out of the enterprise computer network. It means traffic is getting inspected before it going into or out of enterprise network (=internal network). This process is happening within the enterprise network which read on claimed limitation.)
It would be obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to modify Lam’s method of generating digest of application program and based on comparing hash, determine whether data traffic allowed to pass through firewall or block the data transmission by applying Wang’s method of receiving a client hello message sent by TLS application which is running on the client device in order to inspecting network traffic (Wang: [Col 1, line 10]).
Lam in view of Wang does not explicitly disclose:
extracting data from the packet;
However, in an analogous art, Krishnamurthy teaches:
extracting data from the packet (Krishnamurthy: [Col15, lines 42-47], (60) With reference now to FIG. 25, a flowchart of a process for extracting a message from a data packet is depicted in accordance with a preferred embodiment of the present invention. This process begins by receiving a data packet (step 2500). The gateway header and message are extracted from the payload portion of the data packet (step 2502) [Col 2, lines 35-37], (11) The link or connection may be to another gateway or to a node, which extracts the message and header information from the data packet. [Col 11, lines 44-47], This message is in the form of a data packet used for transport on an IP network….the message is extracted from the data field in the data packets (step 1202))
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Lam in view of Wang by applying the well-known technique as disclosed by Krishnamurthy’s method of extracting a message from a data packet in order to provide improved method for sending and receiving massages between two nodes in a communication system (Krishnamurthy: [Col 1, lines 9-11]).
Lam in view of Wang and Krishnamurthy does not explicitly disclose:
hashing the extracted data;
comparing the hashed data to a list of hashes of applications that are authorized to be transmitted over the network.
However, in an analogous art, Althouse teaches:
hashing the extracted data (Althouse: [0060] Next these strings are hashed, preferably using the MD5 algorithm, to produce the SSL Client Fingerprint. It is 128 bits long or 32 hex characters)
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Lam in view of Wang, Krishnamurthy by applying the well-known technique as disclosed by Alhouse’e method of hashing extracted data. The motivation is to generate client fingerprints by applying hash function to client ID).
Lam in view of Wang, Krishnamurthy and Althouse does not explicitly disclose:
comparing the hashed data to a list of hashes of applications that are authorized to be transmitted over the network
However, in an analogous art, Bohannon teaches:
comparing the hashed data to a list of hashes of applications that are authorized to be transmitted over the network (Bohannon [Col 6, lines 19-24], (29) The client finished message is a hash of the entire conversation thus far, which provides further authentication of the client device 106. This message is a verification that the client device 106, who is sending the client finished message is truly the client device 106 who sent the client hello message).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Lam in view of Wang, Krishnamurthy, Althouse by applying the well-known technique as disclosed by Bohannon’s method of determine which of the predicted cipher suites matches the selected cipher suite in the server certificate. The motivation is to allows client/server applications to detect the security risks, such as message tampering, message interception, and message forgery (Bohannon:[Col 1, lines 30-33]).
Regarding claim 15, the combination Lam in view of Wang, Krishnamurthy, Althouse, Bohannon teaches:
the method of claim 9 (see rejection of claim 9 above),
wherein the list of hashes is determined according to an identity of a user of the client device (Bohannon: [Col 6, lines 6-9], provides for the client write MAC secret (= identity of the client) is a key added to client message hashes. The client device 106 uses the client write MAC secret to create the initial hash. The server device 108 uses it to authenticate client messages. [Col 6, lines 19-24], provides the client finished message is a hash of the entire conversation thus far, which provides further authentication of the client device 106. This message is a verification that the client device 106, who is sending the client finished message is truly the client device 106 who sent the client hello message).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Lam in view of Wang, Krishnamurthy, Althouse by applying the well-known technique as disclosed by Bohannon’s method of message verification in order to determine the authenticate client device which is trying to communicate with the server. The motivation is to allows client/server applications to detect the security risks, such as message tampering, message interception, and message forgery (Bohannon:[Col 1, lines 30-33]).
Regarding claim 34, this claim contains identical limitations found within that of claim 15 above and for this reason the same rationale of rejection is used where applicable grounds of rejection are applied to claim 34.
Claim(s) 10, 12, 14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Lam et al (U. S. PGPub. No. 2019/0089678 A1) (hereinafter “Lam”) in view of Wang et al. (U. S. Pat. No. 2018/0324153 A1) (hereinafter “Wang”) and Krishnamurthy et al. (U. S. Pat. No. 6,760,343 B1) (hereinafter “Krishnamurthy”); and in further view of ALTHOUSE et al (US 2018/0324153 A1) (hereinafter “Althouse) in view of Bohannon (U. S. Pat. No. 9,787,643 B2) (hereinafter “Bohannon”) and Ramsey et al. (U. S. PGPub. No. 2012/0117640 A1) (hereinafter “Ramsey”)
Regarding Claim 10, the combination Lam in view of Wang, Krishnamurthy, Althouse and Bohannon teaches:
The method of claim 9 (see rejection of claim 9 above),
The Lam in view of Wang, Krishnamurthy and Althouse and Bohannon does not explicitly disclose:
disallowing the handshake data packet to be transmitted over the network in the event that the hashed data is on the list of hashes of applications that are not authorized on the network
However, in an analogous art, Ramsey teaches:
disallowing the handshake data packet to be transmitted over the network in the event that the hashed data is on the list of hashes of applications that are not authorized on the network (Ramsey: [0061] If the firewall 225 determines that a packet should be rejected, the firewall 225 can transmit a reset packet to the source of the packet indicating that the packet has been rejected by the firewall 225. Similar to the reject determination, the firewall 225 can deny a packet by dropping the packet immediately without forwarding the packet to the secured network 270.).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Lam in view of Wang, Krishnamurthy and Althouse and Bohannon by applying the well-known technique as disclosed by Ramsey of denying the packet by dropping the packet. The motivation is the process of protect a secured computer network from external threats originating from another computer network such as internet (Ramsey: [0019]).
Regarding claim 12, the combination Lam in view of Wang and Krishnamurthy, Althouse and Bohannon teaches:
The method of claim 9 (see rejection of claim 9 above),
The combination Lam in view of Wang and Krishnamurthy, Althouse and Bohannon does not explicitly disclose:
disallowing the handshake data packet to be transmitted over the network in the event that the hashed data is not on the list of hashes of applications that are authorized on the network.
However, in an analogous art, Ramsey teaches:
disallowing the handshake data packet to be transmitted over the network in the event that the hashed data is not on the list of hashes of applications that are authorized on the network (Ramsey: [0061] If the firewall 225 determines that a packet should be rejected, the firewall 225 can transmit a reset packet to the source of the packet indicating that the packet has been rejected by the firewall 225. Similar to the reject determination, the firewall 225 can deny a packet by dropping the packet immediately without forwarding the packet to the secured network 270.).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Lam in view of Wang and Krishnamurthy, Althouse and Bohannon by applying the well-known technique as disclosed by Ramsey of denying the packet by dropping the packet. The motivation is the process of protect a secured computer network from expternal threats originating from another computer network such as internet (Ramsey: [0019]).
Regarding Claim 14, the combination Lam in view of Wang, Krishnamurthy, Althouse and Bohannon teaches:
The method of claim 13 (see rejection of claim 13 above),
The combination Lam in view of Wang, Krishnamurthy, Althouse and Bohannon does not explicitly disclose, but in an analogous art, Ramsey teaches:
disallowing the handshake data packet to be transmitted over the network in the event that the hashed data is not on the list of hashes of applications that are authorized on the network to the destination in the event that the hashed data is not on the list of hashes of applications that are authorized on the network (Ramsey: [0061] If the firewall 225 determines that a packet should be rejected, the firewall 225 can transmit a reset packet to the source of the packet indicating that the packet has been rejected by the firewall 225. Similar to the reject determination, the firewall 225 can deny a packet by dropping the packet immediately without forwarding the packet to the secured network 270.).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Lam in view of Wang and Krishnamurthy, Althouse and Bohannon by applying the well-known technique as disclosed by Ramsey of denying the packet by dropping the packet. The motivation is the process of protect a secured computer network from expternal threats originating from another computer network such as internet (Ramsey: [0019]).
Regarding claim 20, Lam in view of Wang and Krishnamurthy teaches:
The method of claim 16 (see rejection of claim 16 above),
Lam in view of Wang and Krishnamurthy does not explicitly disclose:
wherein the processor is configured to compare the fingerprint produced from the extracted data to those fingerprints in the whitelist library that specify authorized software applications that the client device is permitted to send over the network according to the identity of the client device (Ramsey: [0021], However, the IDS can employ one or more signatures to determine whether a data packet can pass through the intrusion detection system. The IDS can also reject, accept or deny a packet based upon the comparison with the one or more signatures. A signature can comprise all aspects of a packet including header and data, such as an electronic mail message or news posting. [0026], if the IDS is unavailable, the firewall can be configured to pass a packet if no match occurs when the firewall rule(s) and packet are compared).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Lam in view of Wang, Krishnamurthy by applying the well-known technique as disclosed by Ramsey’s method of comparing signatures (fingerprints) with the list of trusted packets, in order to protect a secured computer network from external threats originating from another computer network such as the Internet (Ramsey: [0019]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Refer to PTO-892, Notice of References Cited for a listing of analogous art.
Janakiraman (U. S. 2020/0137021 A1): A system may identify a resource deployed in a computer, where discovery protocol data traffic is unencrypted. The system may receive metadata associated with the discovery protocol data traffic, update the computer network based at least in part on the information included in the metadata, and provide a response to the client. The system may authenticate a request from the client to access the resource using an encrypted protocol, and provide, to the client, access to the resource upon authentication, according to a resource attribute.
PASTORE et al. (U. S. 2022/0131885 A1): The present disclosure relates to a method for tracing malicious endpoints in direct communication with an application back end using TLS fingerprinting techniques, comprising the steps of: providing a reverse proxy configured to intercept the traffic exchanged between a client and an application back end; providing a processing unit in which a default algorithm resides and placed in signal communication with the reverse proxy; intercepting by means of the reverse proxy each TLS Client HELLO directed to the application back end and generating a TLS Client HELLO hash by means of the default algorithm; intercepting and processing by means of the reverse proxy each HTTP request generated by the client and directed to the application back end to extract the Client User Agent from the intercepted HTTP request; processing the Client User Agent by means of the default algorithm to generate a Client User Agent hash; processing by means of the default algorithm the TLS Client HELLO hash and the Client User Agent hash to determine whether the TLS Client HELLO hash is common or anomalous for the Client User Agent hash of the client; performing one or more attack protection actions of the Man-In-The-Middle type if the TLS Client HELLO hash is anomalous for the Client User Agent hash of the client.
Dahan et al. (U. S. Pat. No. 11,012,492 B1): Methods, apparatus and computer software products implement embodiments of the present invention that include protecting a computing system by defining a list of network access messages that are indicative of human use of computing devices, and extracting, from data traffic transmitted over a data network connecting a plurality of the computing devices to multiple Internet sites, respective transmissions from the computing devices to the Internet sites. A given transmission including one of the network access messages in the list is detected in the transmissions from a given computing device, and the given computing device is classified as being operated by a human in response to detecting the given transmission. Upon identifying suspicious content in the transmissions from a subset of the computing devices that includes the given computing device, any suspicious transmissions from the given computing device are ignored in response to the classification.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RUPALI DHAKAD whose telephone number is (571)270-3743. The examiner can normally be reached M-F 8:30-5:30.
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, Alexander Lagor can be reached at 5712705143. 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.
/R.D./Examiner, Art Unit 2437
/ALI S ABYANEH/Primary Examiner, Art Unit 2437
Prosecution Insights