Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Status of Claims
Claims 1-20 are subject to examination.
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.
Claims 1-20 are 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.
Remarks dated 12/4/24 contains, “Applicant herein amends various claims. Support for the amendments can be found in Applicant's originally filed specification.”. “Claims 1-20 stands rejected under 35 U.S.C. § 112, First Paragraph for allegedly failing to comply with the written description requirement. Applicant respectfully traverses the rejection. Nevertheless, for the sole purpose of advancing procession, Applicant herein amends the claims, as shown above. Applicant respectfully submits that these amendments render the § 112 rejection moot”
However, the remarks fail to provide any particular support in the specification for the amendments to the claims 1, 4, 5, 11, and 20.
Amended claim 1 contains, receiving, via a computer network, telemetry data of a traffic flow including a plurality of packets encrypted using a cryptographic protocol, the telemetry data of the traffic flow including cryptographic protocol data of the traffic flow, wherein the cryptographic protocol data of the traffic flow indicates multiple Transport Layer Security (TLS) features, the multiple TLS features including two or more of: a TLS version number, one or more ciphersuites offered by a source device, a ciphersuite selected by a destination device, a TLS sequence of record lengths and times, a record type, a handshake type, an extension type, a size of a cryptographic key, a supported elliptical curve, or a supported point format; classifying, using a machine learning classifier that is trained on the multiple TLS features, the traffic flow based on the cryptographic protocol data of the traffic flow, wherein the machine learning classifier classifies the traffic flow, the machine learning classifier being one of: a) a first machine learning classifier that classifies the traffic flow as a benign flow or malicious flow, a second machine learning classifier that classifies the traffic flow as a tunneled flow or non-tunneled flow, or a third machine learning classifier that classifies the traffic flow as a secure flow or insecure flow; and taking a remedial action with respect to the traffic flow based on the classifying of the traffic flow.
However, the specification contains, [0004] To that end, such systems can employ network telemetry systems that monitor traffic flowing through the network. Such network telemetry systems can collect, analyze, and store a variety of different types of information concerning traffic traversing the network.
The specification contains, The telemetry data can include other types of information regarding the flow.
The specification contains, [0028] Encryption in network traffic, and in data such as files that transit networks
Para 29 contains, traditional flow
Para 30 contains, training flows
Para 21 contains, A number of flows can traverse the network 100
[0030] A general framework for using a byte value distribution metric to solve one of these problems would be to collect, as training flows, positive and negative examples for a problem of interest (for instance, flows that make use of TLS (Transport Layer Security) as positive examples and non-TLS flows as negative examples) and extract the normalized byte value probability distribution and other elements of the training flows. Then, a machine learning classifier (e.g., 11-logistic regression) can be trained on this data. The classifier can then be applied to new telemetry data being exported by the switch 110a—110c or to data previously collected and stored by the telemetry backend system 120.
Para 31 contains, Thus, the telemetry backend system 120 can be configured to receive telemetry data regarding a flow, the telemetry data including a byte value distribution metric, and to classify the flow based (at least in part) on the byte value distribution metric. The telemetry backend system 120 can classify the flow using a machine learning classifier as described above. In some embodiments, the telemetry backend system 120 can take further action based on the classification. For example, the telemetry backend system 120 can generate an alert based on a classification of the flow as a malicious flow. As another example, the telemetry backend system 120 can kill the flow based on a classification of the flow as a malicious flow. As another example, the telemetry backend system 120 can restrict a flow based on a classification of the flow as a tunneled flow. As another example, the telemetry backend system can quarantine a device in response to one or more flows classified as malicious coming from that device. As another example, the telemetry backend system can set billing parameters (or take other actions) based on a classification of a flow as a tunneled flow. As another example, the telemetry backend system can initiate a full packet capture for flow classified as malicious.
[0051] At block 420, the telemetry backend system classifies the flow based on the byte value distribution metric. In some implementations, the telemetry backend system classifies the flow using a machine learning classifier. In some implementations, the telemetry backend system classifies the flow as a benign flow or a malicious flow. In some implementations, the telemetry backend system classifies the flow as a tunneled flow or a non-tunneled flow (e.g., a direct flow). In some implementations, the telemetry backend system classifies the flow as a TLS flow or a non-TLS flow.
[0052] As noted above, in some implementations, the telemetry data includes cryptographic protocol data. Thus, in some implementations, classifying the flow is further based on the cryptographic protocol data.
[0060] At block 620, the telemetry backend system classifies the flow based on the cryptographic protocol data. In some implementations, the telemetry backend system classifies the flow using a machine learning classifier. In some implementations, the telemetry backend system classifies the flow as a benign flow or a malicious flow. In some implementations, the telemetry backend system classifies the flow as a tunneled flow or a non-tunneled flow (e.g., a direct flow). In some implementations, the telemetry backend system classifies the flow as a secure flow or an insecure flow
[0065] TLS implementation (as opposed to TLS configuration) detection is more nuanced. Even if a device is using the latest version of TLS and only offering secure ciphersuites, there can still be vulnerabilities in the actual implementation. The telemetry backend system can receive TLS-specific features, in addition to other telemetry elements, to build a machine learning classifier that is able to determine the actual TLS implementation (e.g. CiscoSSL 4.0). This machine learning classifier can then monitor the live TLS-aware telemetry being collected to detect any vulnerable TLS implementations.
However, the specification does not contain, combination of claimed limitations,
Amended claim 1, receiving, via a computer network, telemetry data of a traffic flow including a plurality of packets encrypted using a cryptographic protocol, the telemetry data of the traffic flow including cryptographic protocol data of the traffic flow, wherein the cryptographic protocol data of the traffic flow indicates multiple Transport Layer Security (TLS) features, the multiple TLS features including two or more of: a TLS version number, one or more ciphersuites offered by a source device(non-TLS), a ciphersuite selected by a destination device(non-TLS), a TLS sequence of record lengths and times, a record type (non-TLS), a handshake type (non-TLS), an extension type(non-TLS), a size of a cryptographic key (non-TLS), a supported elliptical curve (non-TLS), or a supported point format (non-TLS); classifying, using a machine learning classifier that is trained on the multiple TLS features (along with any combination of (non-TLS features), the traffic flow based on the cryptographic protocol data of the traffic flow, wherein the machine learning classifier classifies the traffic flow, the machine learning classifier being one of: a) a first machine learning classifier that classifies the traffic flow (with any combination of TLS features and (non-TLS features) as a benign flow or malicious flow, a second machine learning classifier that classifies the traffic flow (with any combination of TLS features and (non-TLS features) as a tunneled flow or non-tunneled flow, or a third machine learning classifier that classifies the traffic flow (with any combination of TLS features and (non-TLS features) as a secure flow or insecure flow; and taking a remedial action with respect to the traffic flow (with any combination of TLS features and (non-TLS features) based on the classifying of the traffic flow.
Note: without the machine learning classifier trained with each of a Transport Layer Security (TLS) version number, one or more ciphersuites offered by a source device, a ciphersuite selected by a destination device, a TLS sequence of record lengths and times, a record type, a handshake type, an extension type, a size of a cryptographic key, a supported elliptical curve, and a supported point format; the machine learning classifier; it cannot classify into a) a benign flow or malicious flow, b) a tunneled flow or non-tunneled flow, or c) a secure flow or insecure flow.
The specification of this application does not implement any algorithm on how a machine learning classifier is indeed trained on to implement all the elements of the claim as shown below.
The specification is missing Machine learning (ML) algorithms which are step-by-step computational instructions that enable computers to learn patterns from data (please see all the claimed data of claim 1), make predictions, or take decisions without being explicitly programmed for every task, essentially allowing systems to improve with experience.
Note: A machine learning classifier as claimed for a Transport Layer Security (TLS) version number, one or more ciphersuites offered by a source device, a ciphersuite selected by a destination device, a TLS sequence of record lengths and times, a record type, a handshake type, an extension type, a size of a cryptographic key, a supported elliptical curve, and a supported point format; and (THAT IS TRAINED WITH a Transport Layer Security (TLS) version number, one or more ciphersuites offered by a source device, a ciphersuite selected by a destination device, a TLS sequence of record lengths and times, a record type, a handshake type, an extension type, a size of a cryptographic key, a supported elliptical curve, and a supported point format, and the machine learning classifier also classifies the traffic flow as: a) a benign flow or malicious flow, b) a tunneled flow or non-tunneled flow, or c) a secure flow or insecure flow, taking a remedial action with respect to the traffic flow based on the classifying of the traffic flow, which is not implemented in the specification.
As seen in the above paragraphs of the specification, there is no support of three different machine learning classifier that are indeed trained to:
a) a first machine learning classifier that classifies the traffic flow as a benign flow or malicious flow, a second machine learning classifier that classifies the traffic flow as a tunneled flow or non-tunneled flow, or a third machine learning classifier that classifies the traffic flow as a secure flow or insecure flow.
Claims 11 and 20 contain similar limitations of claim 1 and hence subject to the same rejections. Claims 2-10, 12-19 depend upon claims 1 and 11 respectively and hence subject to the same rejections.
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 1-20 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.
Claim 1 claims, “multiple Transport Layer Security (TLS) features, the multiple TLS features including two or more of: a TLS version number, one or more ciphersuites offered by a source device, a ciphersuite selected by a destination device, a TLS sequence of record lengths and times, a record type, a handshake type, an extension type, a size of a cryptographic key, a supported elliptical curve, or a supported point format; classifying, using a machine learning classifier that is trained on the multiple TLS features”, which renders the claim indefinite for failing to particularly point out and distinctly claim the subject matter.
A cipher suite is a bundle of cryptographic algorithms that TLS/SSL protocols use to establish a secure network connection, defining how data is encrypted, authenticated, and kept secure (confidentiality, integrity, authenticity) during a TLS handshake.
Hence, the claimed “ciphersuites” is not limited to “TLS ciphersuites” and also means “SSL ciphersuites”. Hence, the multiple TLS features including “SSL ciphersuites” renders the claim indefinite for failing to particularly point out and distinctly claim the subject matter.
Similarly, the claimed, one or more ciphersuites offered by a source device, a ciphersuite selected by a destination device, a record type, a handshake type, an extension type, a size of a cryptographic key, a supported elliptical curve, or a supported point format; do not contain “TLS” and hence, not limited to “TLS” features and rather belong to other well-known protocols in the art.
For example, A handshake type includes a negotiation process where two systems establish rules for secure communication, agreeing on encryption, authentication, and data exchange parameters before sending sensitive info, with common types being the TCP handshake etc.
Hence, the above claimed TLS features are not limited to “TLS features” and also means “other than TLS features”. Hence, the multiple TLS features including features without “TLS” renders the claim indefinite for failing to particularly point out and distinctly claim the subject matter.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being incomplete for omitting essential steps/elements, such omission amounting to a gap between the steps. See MPEP § 2172.01. The omitted steps are: implementing/using the telemetry “backend” system to classify the flow using the machine learning classifier, so that the telemetry backend system 120 can take further action based on the classification.
See para 51 of the specification: The telemetry backend system 120 can classify the flow using a machine learning classifier. The telemetry backend system 120 can take further action based on the classification.
Claims 11 and 20 contain similar limitations of claim 1 and hence subject to the same rejections. Claims 2-10, 12-19 depend upon claims 1 and 11 respectively and hence subject to the same rejections.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 11, is/are rejected under 35 U.S.C. 103 as being unpatentable over Akhter et al., 2015/0281028 Cisco Technology in view of Shanker et al., 2014/0082204, Cisco Technology and Goodall et al., 7683773, Ahmed et al., 9483742, and Yung 7,778,194.
Referring to claim(s) 1, 11, Akhter discloses an apparatus, comprising: network interface; a processor coupled to the network interface; and a memory configured to store instruction which when executed by the processor, configure the processor to: a tangible, non-transitory, computer-readable medium that stores program instructions causing a device to execute a process comprising (para 21, figure 1, 3, 4):
PNG
media_image1.png
296
518
media_image1.png
Greyscale
receiving, via a computer network, telemetry data of a traffic flow (para 21, 38, figure 1, 3, 4)
PNG
media_image2.png
342
542
media_image2.png
Greyscale
including a plurality of packets, the telemetry data of the traffic flow (para 38)
PNG
media_image3.png
195
557
media_image3.png
Greyscale
including a plurality of packets, the telemetry data of the traffic flow including data of the traffic flow (para 38)
Akhter-Cisco does not specifically mention about, which is well-known in the art, which Shanker-Cisco discloses, plurality of packets encrypted using a cryptographic protocol, cryptographic protocol data of the flow, para 2, 15, 16. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Akhter-Cisco to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide encrypting data of the flow. The encrypted data would enable secure transmission of data from one device to another device, and would provide security for the data in the system, para 2, 15, 16.
Akhter-Cisco and Shanker-Cisco do not specifically mention about, which is well-known in the art, which Goodall discloses wherein the data of the traffic flow indicates multiple Transport Layer Security (TLS) features including two or more of a TLS version number, ciphersuite offered by a source device, a ciphersuite selected by a destination device, a TLS sequence of record lengths and times, a record type, a handshake type, an extension type, a size of a cryptographic key, a supported elliptical curve, or a supported point format, (
Note: A cipher specification (CipherSpec) is a specific, named combination of algorithms used to secure a network connection, typically within the context of security protocols like Transport Layer Security (TLS) or its predecessor, SSL. In modern terminology, the term cipher suite is more common and essentially serves the same purpose, defining the complete set of algorithms for a secure session.
(82) EAP-Request, EAP-Type=EAP-TLS/TAG (TLS server hello, TLS change cipher spec, TLS finished).
68) EAP-Request, EAP-Type=EAP-TLS/TAG (TLS change cipher spec, TLS finished)
(84) EAP-Response, EAP-Type=EAP-TLS/TAG (TLS change cipher spec, TLS finished, TLS application data encoding tag telemetry data, TLS Encrypted Alert (Close-Notify)).
(90) In the example above, the telemetry data is transmitted in EAP packets using further encapsulation of the telemetry TLVs within TLS records which are themselves contained within EAP packets col., 10, lines 37 – 50.
The EAP header is followed by the TLS (Transport Layer Security) Record header 919 which precedes the TLS Record Data. The TLS Record Data contains the EAP data fields and, as described above, may include the TLVs including any embedded telemetry from the tag. The TLS Record Data is followed by the TLS Record MAC 923 and the packet is closed with the 802.11 FCS (Frame Check Sequence).
an EAP header 965, followed by a TLS Record Header 967, followed by the TLS Record Data 969 and then the TLS Record MAC 971. Notice that this is the same structure as in FIG. 9. As in the example of FIG. 9, the telemetry data may be embedded within the TLS Record Data in Type, Length, Value Fields or in another suitable location. As can be seen by comparing FIGS. 9 and 10, the conventional packet formats allow the telemetry data from the tag to be transmitted over a variety of different network protocols, para, 1, 2, col., 12.
Note:
A TLS Record Type defines the kind of data in a secure packet (like handshake messages, alerts, or actual application data), managed by the TLS Record Protocol to encrypt, authenticate, and compress data after the secure connection (handshake) is set up, ensuring confidentiality and integrity for internet traffic. Key types include handshake (negotiation), application_data (user info), and alert (errors).
The EAP header is followed by the TLS (Transport Layer Security) Record header 919 which precedes the TLS Record Data. The TLS Record Data contains the EAP data fields and, as described above, may include the TLVs including any embedded telemetry from the tag. The TLS Record Data is followed by the TLS Record MAC 923 and the packet is closed with the 802.11 FCS (Frame Check Sequence)., third last para, col., 11.
Note: The machine learning classifier merely classifies as what the backend can also do (see specification para 51). No where in the specification there is a support of the machine learning classifier indeed classifieds differently as compared to the backend/any other software/program. Classifying the flow using the protocol information is well-known in the art and adding of the machine learning for it do not make it novel.
Within each Attribute/Value pair, there may be an EAP header 965, followed by a TLS Record Header 967, followed by the TLS Record Data 969 and then the TLS Record MAC 971. Notice that this is the same structure as in FIG. 9. As in the example of FIG. 9, the telemetry data may be embedded within the TLS Record Data in Type, Length, Value Fields or in another suitable location., col., 11, lines 13-50.
(75) The full EAP-TLS handshake is expensive in terms of CPU time for the tag and the number of transmitted packets. In some cases, this may present a significant drain on the available power of the tag. If the tag relies on battery power, then the tag will last longer or may be made with a smaller battery, if such exchanges can be minimized or if the time and number of messages may be reduced. EAP-TLS supports a session resumption mechanism which allows a new connection to use an already-established master secret. Session resumption allows a tag to perform the most expensive parts of the handshake, that is the exchange of certificates and public key cryptographic operations, once and then resume the same session multiple times at much lower computational and transmission cost. This is useful when the tag is likely to transmit telemetry data several times during its journey from supplier to customer: Session resumption may also allow a special server to perform the full EAP-TLS handshake on behalf of the tag so that the session details and credentials can be downloaded to the tag before it commences its journey., 1st para, col., 10.
PNG
media_image4.png
273
632
media_image4.png
Greyscale
PNG
media_image5.png
261
622
media_image5.png
Greyscale
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Akhter-Cisco to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide a particular information in the data of the traffic flow. The data flow would enable transmission of the particular information from one device to another device, and would enable utilizing the data in the system, col., 11, lines 13-50. Akhter-Cisco also discloses wherein the traffic flow further includes unencrypted packet (para 21, 38, figure 1, 3, 4). Shanker-Cisco also discloses inspecting, by the device, the unencrypted packet to determine the cryptographic protocol data of the traffic flow, col., 1, line 58 – col., 2, lines 20.
Goodall, Akhter-Cisco and Shanker-Cisco do not specifically mention about, which is well-known in the art, which AHMED discloses classifying, using a machine learning classifier that is trained on the claimed multiple TLS features the traffic flow based on the cryptographic protocol data of the traffic flow where in the MLC classifies the traffic flow, the machine learning classifier being one of: a) a first machine learning classifier that classifies the traffic flow as a benign flow or malicious flow, a second machine learning classifier that classifies the traffic flow as a tunneled flow or non-tunneled flow, or a third machine learning classifier that classifies the traffic flow as a secure flow or insecure flow; to result in a classification of the traffic flow as a malicious flow, a tunneled flow, or an insecure flow, the traffic flow based on the cryptographic protocol data of the traffic flow, resulting in a classification of the traffic flow, col., 1, line 58 – col., 2, lines 20.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Akhter-Cisco to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide a particular information in the data of the traffic flow. The data flow would enable transmission of the particular information from one device to another device, and would enable utilizing after classification of the data in the system, col., 1, line 58 – col., 2, lines 20.
Goodall, Akhter-Cisco, AHMED and Shanker-Cisco do not specifically mention about, which is well-known in the art, which Yung discloses
taking a remedial action with respect to the traffic flow based on the classification of the traffic flow, col., 23, lines 1-20, col., 20, lines 46-63. Col., 5, line – Col., 6, line23.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Akhter-Cisco to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide a remedial action based on the classification of the flow. The remedial action would enable providing dropping or ignoring the flow. The dropping the flow would prevent any outcome of the further processing of the flow, col., 23, lines 1-20, col., 20, lines 46-63. Col., 5, line – Col., 6, line23.
Claim(s) 12, 2, is/are rejected under 35 U.S.C. 103 as being unpatentable over Akhter in view of Shanker-Cisco, Goodall, AHMED, Yung and Garg et al., 20140098669.
Referring to claim(s) 12, 2, Akhter-Cisco, Namblar, AHMED, Yung, and Bowen do not specifically mention about, which is well-known in the art, which Garg discloses, wherein the telemetry data of the traffic flow further includes at least one of: a source IP address of the traffic flow, a destination IP address of the traffic flow, a start time of the traffic flow, a stop time of the traffic flow, a protocol associated with the traffic flow, a number of bytes of the traffic flow, and a number of the plurality of packets, para 28. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Akhter-Cisco to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide a particular information in the data of the traffic flow. The data flow would enable transmission of the particular information from one device to another device, and would enable utilizing the information in the system, para 28.
Claim(s) 3, 13, is/are rejected under 35 U.S.C. 103 as being unpatentable over Akhter in view of Shanker-Cisco, Goodall, AHMED, Yung and Kampeas et al., 2015/0200860, and White et al., 2015/0052601.
Referring to claim(s) 3, 13, Akhter-Cisco, Shanker-Cisco, AHMED, Yung, and Goodall do not specifically mention about, which is well-known in the art, which Kampeas discloses, a sequence of packet lengths and times (SRLT) for the packet, para 43. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Akhter-Cisco to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide a particular information such as SRLT in the traffic flow. The data flow would enable transmission of the particular information such as SRLT from one device to another device, and would enable utilizing the information in the system, para 43.
AHMED, Yung, Akhter-Cisco, Shanker-Cisco, and Goodall do not specifically mention about, which is well-known in the art, which White discloses, a byte value distribution metric, para 175, 193, 82. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Akhter-Cisco to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide a particular information such as byte value distribution metric in the traffic flow. The data flow would enable transmission of the particular information such as such as byte value distribution metric from one device to another device, and would enable utilizing the information in the system, para 175, 193, 82.
Claim(s) 4, 14, 9, 19, is/are rejected under 35 U.S.C. 103 as being unpatentable over Akhter in view of Shanker-Cisco, Goodall, AHMED, Yung and Khalid et al., 9,432,389.
Referring to claim(s) 4, 14, Claim 1 contains citation for traffic flow and classifying using the machine learning classified, and cryptographic protocol data. Akhter-Cisco, Shanker-Cisco, AHMED, Yung, and Goodall do not specifically mention about, which is well-known in the art, which Khalid discloses, the first machine learning classifier classifying the flow as a benign flow or a malicious flow, col., 18, lines 4-24. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Akhter-Cisco to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide a classifier to receive and classify whether the flow contains malicious object or not. When the flow contains malicious object an action can be taken to secure the system as suggested, para col., 18, lines 4-24.
Referring to claim(s) 9, 19, Khalid discloses, performing one or more remedial actions based on the classification of the traffic flow, wherein the one or more remedial actions are selected from a group consisting of: generating an alert, stopping the traffic flow, quarantining a source device of the traffic flow, and initiating an upgrade of the source device of the traffic flow, col., 18, lines 4-24.
Claim(s) 5, 15, is/are rejected under 35 U.S.C. 103 as being unpatentable over Akhter in view of Shanker-Cisco, Goodall, AHMED, Yung and Matthews et al. 20110032942.
Referring to claim(s) 5, 15, Claim 1 contains citation for traffic flow and classifying using the machine learning classified, and cryptographic protocol data. Akhter-Cisco, Shanker-Cisco, AHMED, Yung, and Goodall do not specifically mention about, which is well-known in the art, which Matthews discloses, the second machine learning classifier classifying the flow as a tunneled flow or non-tunneled flow based on data of the traffic flow, para 125. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Akhter-Cisco to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide usage of flow with or without tunneling. A classification of the flow with or without tunneling would enable grouping of the flow data. The grouping would enable further particular processing of the flow data for outcome associated with the classifying, para 125.
Claim(s) 10, is/are rejected under 35 U.S.C. 103 as being unpatentable over Akhter in view of Shanker-Cisco, Goodall, AHMED, Yung, Buruganahalli et al., 9419942 and Bektchiev et al., 20170061129 .
Referring to claim(s) 10, Claim 1 contains citation for traffic flow and classifying using the machine learning classified, and cryptographic protocol data. Akhter-Cisco, Shanker-Cisco, AHMED, Yung, and Goodall do not specifically mention about, which is well-known in the art, which Buruganahalli discloses, identifying a device associated with the traffic flow using an TLS configuration based on the cryptographic protocol data of the traffic flow (
PNG
media_image6.png
611
567
media_image6.png
Greyscale
PNG
media_image7.png
723
586
media_image7.png
Greyscale
network traffic monitoring begins at 102. An IP address and port engine 104 determines an IP address and port number for a monitored traffic flow (e.g., a session) based on packet analysis. In some embodiments, user identification is then determined (e.g., user ID can be deduced based on the source IP address). As also shown in FIG. 1, an application signature check engine 108 identifying applications based on flow analysis). For example, APP-ID engine 108 can be configured to determine what type of traffic the session involves, such as HTTP traffic, HTTPS traffic, SSL/TLS traffic, SSH traffic, DNS requests, FTP traffic, unknown traffic, and various other types of traffic, and such classified traffic can be directed to an appropriate decoder, such as decoders 112, 114, and 116, to decode the classified traffic for each monitored session's traffic flow, col., 8, lines 54-64,
(67) FIG. 5 is a functional diagram of hardware components of a security device for providing destination domain extraction for secure protocols. The example shown is a representation of physical components that can be included in security device 402 (e.g., gateway, or server). In some embodiments, servers identified as external sites that are monitored for implementing policies using destination domain extraction for secure protocols. Security device 402 can also include a cryptographic engine 506 configured to perform encryption and decryption operations, and/or perform other tasks, col., 13, lines 30-40.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Akhter-Cisco to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide usage of well-known TLS. The TLS would enable implementing secure traffic flow. The encryption and decryption would also enable implementing secure traffic flow, col., 8, lines 54-64.
Akhter-Cisco, Shanker-Cisco, Buruganahalli, AHMED, Yung, and Goodall do not specifically mention about, which is well-known in the art, which Bektchiev discloses, insecure TLS configuration, para 120, 86.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Akhter-Cisco to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide usage of well-known insure TLS. The TLS would enable implementing secure traffic flow. The insecure TLS would also enable implementing traffic flow with renegotiations when no need for security, para 120, 86.
Claim(s) 6, 16, is/are rejected under 35 U.S.C. 103 as being unpatentable over Akhter in view of Shanker-Cisco, Goodall, AHMED, Yung and Nguyen et al., 20140059200 Cisco Technology.
Referring to claim(s) 6, 16, Claim 1 contains citation for traffic flow and classifying using the machine learning classified, and cryptographic protocol data. Akhter-Cisco, Shanker-Cisco, AHMED, Yung, and Goodall do not specifically mention about, which is well-known in the art, which Nguyen discloses, source device of the traffic flow, wherein the classification of the traffic flow (para 59, 42) is based further on the classification of a source device of the traffic flow (para 42, 43). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Akhter-Cisco to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide usage of classifying using the machine learning classifier, and cryptographic protocol data. The machine learning classifier would enable training it with classifying rules. The protocol would enable procedure that would be carried out for the communication associated with cryptographic for secure communication. With the classifying and protocol data, the traffic flow would be grouped using the classification rules, para 59, 42.
Claim(s) 7, 17, is/are rejected under 35 U.S.C. 103 as being unpatentable over Akhter in view of Shanker-Cisco, Goodall, AHMED, Yung and Nucci et al., 8180916.
Referring to claim(s) 7, 17, Claim 1 contains citation for traffic flow and classifying using the machine learning classified, and cryptographic protocol data. Akhter-Cisco, Shanker-Cisco, AHMED, Yung, and Goodall do not specifically mention about, which is well-known in the art, which Nucci discloses, determining cryptographic library of a source device of the traffic flow or a destination device of the traffic flow, wherein the classification of the traffic flow is based further on the cryptographic library (
PNG
media_image8.png
486
682
media_image8.png
Greyscale
a statistical analyzer configured to obtain a first plurality of packets associated with a first server in the network from a plurality of flows in the network traffic, extract a first plurality of features corresponding to the plurality of flows from the first plurality of packets, a signature generator configured to determine a first packet content signature based on the first plurality of features, a signature library comprising a plurality of packet content signatures, a distiller configured to qualify the first packet content signature for adding to the signature library, and to analyze a second plurality of packets associated a the second server in the network traffic based on the signature library to generate an analysis result, and determine a network application associated with the second server based on the analysis result, col., 4, lines 35-35,
the repository (120) includes a server matrix set (121) and a signature library (131). The signature library includes signatures (132a, 132b, etc.) corresponding to server tags (133a, 133b, etc.). In one or more embodiments, signature library (131) may be implemented as a database, a file, a linked list, or other suitable data structures, col., 6, lines 42-50.
to classify the processed traffic streams in real time using a list of known signatures (e.g., 132a, 132b, etc.) in the signature library, previously extracted by the signature generator (106). When full packets (i.e., header+payload) are collected from the traffic stream (114), the classifier (103) uses packet-content signatures to classify the traffic stream (114). When packet header records (i.e., packet headers or netflow-like records) are collected from the traffic streams (113), the classifier (103) uses flow-feature signatures. Every traffic stream for which a signature is available is classified (i.e., assigned a classification), col., 6, lines 60-67.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Akhter-Cisco to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide usage of a cryptographic library of a source or a destination device of the traffic flow. The library would enable classifying rules for the flow data based on cryptographic for securing the data. The secured data would enable procedure that would be carried out for the communication associated with cryptographic for secure communication. With the classified data based on the library, the traffic flow would be grouped using the classification rules such as signature for the security, col., 6, lines 42-50.
Claim(s) 8, 18, is/are rejected under 35 U.S.C. 103 as being unpatentable over Akhter in view of Shanker-Cisco, Goodall, AHMED, Yung and Nucci et al., 8180916.
Referring to claim(s) 8, 18, Claim 1 contains citation for traffic flow and classifying using the machine learning classified, and cryptographic protocol data. AHMED cryptographic protocol data of the traffic flow, para 40, 43. Nucci discloses, inferring the cryptographic library of the source device of the traffic flow or the destination device of the traffic flow based on the on the cryptographic library (
a statistical analyzer configured to obtain a first plurality of packets associated with a first server in the network from a plurality of flows in the network traffic, extract a first plurality of features corresponding to the plurality of flows from the first plurality of packets, a signature generator configured to determine a first packet content signature based on the first plurality of features, a signature library comprising a plurality of packet content signatures, a distiller configured to qualify the first packet content signature for adding to the signature library, and to analyze a second plurality of packets associated a the second server in the network traffic based on the signature library to generate an analysis result, and determine a network application associated with the second server based on the analysis result, col., 4, lines 35-35,
the repository (120) includes a server matrix set (121) and a signature library (131). The signature library includes signatures (132a, 132b, etc.) corresponding to server tags (133a, 133b, etc.). In one or more embodiments, signature library (131) may be implemented as a database, a file, a linked list, or other suitable data structures, col., 6, lines 42-50.
to classify the processed traffic streams in real time using a list of known signatures (e.g., 132a, 132b, etc.) in the signature library, previously extracted by the signature generator (106). When full packets (i.e., header+payload) are collected from the traffic stream (114), the classifier (103) uses packet-content signatures to classify the traffic stream (114). When packet header records (i.e., packet headers or netflow-like records) are collected from the traffic streams (113), the classifier (103) uses flow-feature signatures. Every traffic stream for which a signature is available is classified (i.e., assigned a classification), col., 6, lines 60-67.
Claim(s) 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Akhter et al., 2015/0281028 Cisco Technology in view of Shanker et al., 2014/0082204, Cisco Technology and Goodall et al., 7683773, AHMED et al., 20100250918, Yung 7,778,194, and Li et al., CN 1294723 C.
Referring to claim(s) 20, Akhter discloses an apparatus, comprising: network interface; a processor coupled to the network interface; and a memory configured to store instruction which when executed by the processor, configure the processor to: a tangible, non-transitory, computer-readable medium that stores program instructions causing a device to execute a process comprising (para 21, figure 1, 3, 4):
PNG
media_image1.png
296
518
media_image1.png
Greyscale
receiving, via a computer network, telemetry data of a traffic flow (para 21, 38, figure 1, 3, 4)
PNG
media_image2.png
342
542
media_image2.png
Greyscale
including a plurality of packets, the telemetry data of the traffic flow (para 38)
PNG
media_image3.png
195
557
media_image3.png
Greyscale
including a plurality of packets, the telemetry data of the traffic flow including data of the traffic flow (para 38)
Akhter-Cisco does not specifically mention about, which is well-known in the art, which Shanker-Cisco discloses, plurality of packets encrypted using a cryptographic protocol, cryptographic protocol data of the flow, para 2, 15, 16. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Akhter-Cisco to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide encrypting data of the flow. The encrypted data would enable secure transmission of data from one device to another device, and would provide security for the data in the system, para 2, 15, 16.
Akhter-Cisco and Shanker-Cisco do not specifically mention about, which is well-known in the art, which Goodall discloses wherein the data of the traffic flow indicates multiple Transport Layer Security (TLS) features including two or more of a TLS version number, ciphersuite offered by a source device, a ciphersuite selected by a destination device, a TLS sequence of record lengths and times, a record type, a handshake type, an extension type, a size of a cryptographic key, a supported elliptical curve, or a supported point format, (
Note: A cipher specification (CipherSpec) is a specific, named combination of algorithms used to secure a network connection, typically within the context of security protocols like Transport Layer Security (TLS) or its predecessor, SSL. In modern terminology, the term cipher suite is more common and essentially serves the same purpose, defining the complete set of algorithms for a secure session.
(82) EAP-Request, EAP-Type=EAP-TLS/TAG (TLS server hello, TLS change cipher spec, TLS finished).
68) EAP-Request, EAP-Type=EAP-TLS/TAG (TLS change cipher spec, TLS finished)
(84) EAP-Response, EAP-Type=EAP-TLS/TAG (TLS change cipher spec, TLS finished, TLS application data encoding tag telemetry data, TLS Encrypted Alert (Close-Notify)).
(90) In the example above, the telemetry data is transmitted in EAP packets using further encapsulation of the telemetry TLVs within TLS records which are themselves contained within EAP packets col., 10, lines 37 – 50.
The EAP header is followed by the TLS (Transport Layer Security) Record header 919 which precedes the TLS Record Data. The TLS Record Data contains the EAP data fields and, as described above, may include the TLVs including any embedded telemetry from the tag. The TLS Record Data is followed by the TLS Record MAC 923 and the packet is closed with the 802.11 FCS (Frame Check Sequence).
an EAP header 965, followed by a TLS Record Header 967, followed by the TLS Record Data 969 and then the TLS Record MAC 971. Notice that this is the same structure as in FIG. 9. As in the example of FIG. 9, the telemetry data may be embedded within the TLS Record Data in Type, Length, Value Fields or in another suitable location. As can be seen by comparing FIGS. 9 and 10, the conventional packet formats allow the telemetry data from the tag to be transmitted over a variety of different network protocols, para, 1, 2, col., 12.
Note:
A TLS Record Type defines the kind of data in a secure packet (like handshake messages, alerts, or actual application data), managed by the TLS Record Protocol to encrypt, authenticate, and compress data after the secure connection (handshake) is set up, ensuring confidentiality and integrity for internet traffic. Key types include handshake (negotiation), application_data (user info), and alert (errors).
The EAP header is followed by the TLS (Transport Layer Security) Record header 919 which precedes the TLS Record Data. The TLS Record Data contains the EAP data fields and, as described above, may include the TLVs including any embedded telemetry from the tag. The TLS Record Data is followed by the TLS Record MAC 923 and the packet is closed with the 802.11 FCS (Frame Check Sequence)., third last para, col., 11.
Note: The machine learning classifier merely classifies as what the backend can also do (see specification para 51). No where in the specification there is a support of the machine learning classifier indeed classifieds differently as compared to the backend/any other software/program. Classifying the flow using the protocol information is well-known in the art and adding of the machine learning for it do not make it novel.
Within each Attribute/Value pair, there may be an EAP header 965, followed by a TLS Record Header 967, followed by the TLS Record Data 969 and then the TLS Record MAC 971. Notice that this is the same structure as in FIG. 9. As in the example of FIG. 9, the telemetry data may be embedded within the TLS Record Data in Type, Length, Value Fields or in another suitable location., col., 11, lines 13-50.
(75) The full EAP-TLS handshake is expensive in terms of CPU time for the tag and the number of transmitted packets. In some cases, this may present a significant drain on the available power of the tag. If the tag relies on battery power, then the tag will last longer or may be made with a smaller battery, if such exchanges can be minimized or if the time and number of messages may be reduced. EAP-TLS supports a session resumption mechanism which allows a new connection to use an already-established master secret. Session resumption allows a tag to perform the most expensive parts of the handshake, that is the exchange of certificates and public key cryptographic operations, once and then resume the same session multiple times at much lower computational and transmission cost. This is useful when the tag is likely to transmit telemetry data several times during its journey from supplier to customer: Session resumption may also allow a special server to perform the full EAP-TLS handshake on behalf of the tag so that the session details and credentials can be downloaded to the tag before it commences its journey., 1st para, col., 10.
PNG
media_image4.png
273
632
media_image4.png
Greyscale
PNG
media_image5.png
261
622
media_image5.png
Greyscale
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Akhter-Cisco to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide a particular information in the data of the traffic flow. The data flow would enable transmission of the particular information from one device to another device, and would enable utilizing the data in the system, col., 11, lines 13-50. Akhter-Cisco also discloses wherein the traffic flow further includes unencrypted packet (para 21, 38, figure 1, 3, 4). Shanker-Cisco also discloses inspecting, by the device, the unencrypted packet to determine the cryptographic protocol data of the traffic flow, col., 1, line 58 – col., 2, lines 20.
Goodall, Akhter-Cisco and Shanker-Cisco do not specifically mention about, which is well-known in the art, which AHMED discloses classifying, using a machine learning classifier that is trained on the claimed multiple TLS features the traffic flow based on the cryptographic protocol data of the traffic flow where in the MLC classifies the traffic flow, the machine learning classifier being one of: a) a first machine learning classifier that classifies the traffic flow as a benign flow or malicious flow, a second machine learning classifier that classifies the traffic flow as a tunneled flow or non-tunneled flow, or a third machine learning classifier that classifies the traffic flow as a secure flow or insecure flow; to result in a classification of the traffic flow as a malicious flow, a tunneled flow, or an insecure flow, the traffic flow based on the cryptographic protocol data of the traffic flow, resulting in a classification of the traffic flow, col., 1, line 58 – col., 2, lines 20.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Akhter-Cisco to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide a particular information in the data of the traffic flow. The data flow would enable transmission of the particular information from one device to another device, and would enable utilizing after classification of the data in the system, col., 1, line 58 – col., 2, lines 20.
Goodall, Akhter-Cisco, AHMED and Shanker-Cisco do not specifically mention about, which is well-known in the art, which Yung discloses
taking a remedial action with respect to the traffic flow based on the classification of the traffic flow, col., 23, lines 1-20, col., 20, lines 46-63. Col., 5, line – Col., 6, line23.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Goodall to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide a remedial action based on the classification of the flow. The remedial action would enable providing dropping or ignoring the flow. The dropping the flow would prevent any outcome of the further processing of the flow, col., 23, lines 1-20, col., 20, lines 46-63. Col., 5, line – Col., 6, line23.
Goodall, Akhter-Cisco, AHMED, Yung and Shanker-Cisco do not specifically mention about, which is well-known in the art, which Li discloses gateway label edge router, claim 1.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Akhter-Cisco to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide executing a process. Similar to a processor in claim 11, gateway label edge router would enable performing process., Besides claimed processing, the gateway label edge router would enable receiving a packet that is destined for a domain, claim 1.
Response to Arguments
Remarks/Arguments filed 12/4/25, pages 9-18 have been fully considered but they are not persuasive. Therefore, rejection of claims 1-20 is maintained.
Regarding Remarks/Arguments for the amended limitations, the rejections are updated accordingly. Please see above updated rejections for the amended claims.
PNG
media_image9.png
554
670
media_image9.png
Greyscale
Akhter discloses an apparatus, comprising: network interface; a processor coupled to the network interface; and a memory configured to store instruction which when executed by the processor, configure the processor to: a tangible, non-transitory, computer-readable medium that stores program instructions causing a device to execute a process comprising (para 21, figure 1, 3, 4):
PNG
media_image1.png
296
518
media_image1.png
Greyscale
receiving, via a computer network, telemetry data of a traffic flow (para 21, 38, figure 1, 3, 4)
PNG
media_image2.png
342
542
media_image2.png
Greyscale
including a plurality of packets, the telemetry data of the traffic flow (para 38)
PNG
media_image3.png
195
557
media_image3.png
Greyscale
including a plurality of packets, the telemetry data of the traffic flow including data of the traffic flow (para 38)
Akhter-Cisco does not specifically mention about, which is well-known in the art, which Shanker-Cisco discloses, plurality of packets encrypted using a cryptographic protocol, cryptographic protocol data of the flow, para 2, 15, 16. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Akhter-Cisco to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide encrypting data of the flow. The encrypted data would enable secure transmission of data from one device to another device, and would provide security for the data in the system, para 2, 15, 16.
Akhter-Cisco and Shanker-Cisco do not specifically mention about, which is well-known in the art, which Goodall discloses wherein the data of the traffic flow indicates multiple Transport Layer Security (TLS) features including two or more of a TLS version number, ciphersuite offered by a source device, a ciphersuite selected by a destination device, a TLS sequence of record lengths and times, a record type, a handshake type, an extension type, a size of a cryptographic key, a supported elliptical curve, or a supported point format, (
Note: A cipher specification (CipherSpec) is a specific, named combination of algorithms used to secure a network connection, typically within the context of security protocols like Transport Layer Security (TLS) or its predecessor, SSL. In modern terminology, the term cipher suite is more common and essentially serves the same purpose, defining the complete set of algorithms for a secure session.
(82) EAP-Request, EAP-Type=EAP-TLS/TAG (TLS server hello, TLS change cipher spec, TLS finished).
68) EAP-Request, EAP-Type=EAP-TLS/TAG (TLS change cipher spec, TLS finished)
(84) EAP-Response, EAP-Type=EAP-TLS/TAG (TLS change cipher spec, TLS finished, TLS application data encoding tag telemetry data, TLS Encrypted Alert (Close-Notify)).
(90) In the example above, the telemetry data is transmitted in EAP packets using further encapsulation of the telemetry TLVs within TLS records which are themselves contained within EAP packets col., 10, lines 37 – 50.
The EAP header is followed by the TLS (Transport Layer Security) Record header 919 which precedes the TLS Record Data. The TLS Record Data contains the EAP data fields and, as described above, may include the TLVs including any embedded telemetry from the tag. The TLS Record Data is followed by the TLS Record MAC 923 and the packet is closed with the 802.11 FCS (Frame Check Sequence).
an EAP header 965, followed by a TLS Record Header 967, followed by the TLS Record Data 969 and then the TLS Record MAC 971. Notice that this is the same structure as in FIG. 9. As in the example of FIG. 9, the telemetry data may be embedded within the TLS Record Data in Type, Length, Value Fields or in another suitable location. As can be seen by comparing FIGS. 9 and 10, the conventional packet formats allow the telemetry data from the tag to be transmitted over a variety of different network protocols, para, 1, 2, col., 12.
Note:
A TLS Record Type defines the kind of data in a secure packet (like handshake messages, alerts, or actual application data), managed by the TLS Record Protocol to encrypt, authenticate, and compress data after the secure connection (handshake) is set up, ensuring confidentiality and integrity for internet traffic. Key types include handshake (negotiation), application_data (user info), and alert (errors).
The EAP header is followed by the TLS (Transport Layer Security) Record header 919 which precedes the TLS Record Data. The TLS Record Data contains the EAP data fields and, as described above, may include the TLVs including any embedded telemetry from the tag. The TLS Record Data is followed by the TLS Record MAC 923 and the packet is closed with the 802.11 FCS (Frame Check Sequence)., third last para, col., 11.
Note: The machine learning classifier merely classifies as what the backend can also do (see specification para 51). No where in the specification there is a support of the machine learning classifier indeed classifieds differently as compared to the backend/any other software/program. Classifying the flow using the protocol information is well-known in the art and adding of the machine learning for it do not make it novel.
Within each Attribute/Value pair, there may be an EAP header 965, followed by a TLS Record Header 967, followed by the TLS Record Data 969 and then the TLS Record MAC 971. Notice that this is the same structure as in FIG. 9. As in the example of FIG. 9, the telemetry data may be embedded within the TLS Record Data in Type, Length, Value Fields or in another suitable location., col., 11, lines 13-50.
(75) The full EAP-TLS handshake is expensive in terms of CPU time for the tag and the number of transmitted packets. In some cases, this may present a significant drain on the available power of the tag. If the tag relies on battery power, then the tag will last longer or may be made with a smaller battery, if such exchanges can be minimized or if the time and number of messages may be reduced. EAP-TLS supports a session resumption mechanism which allows a new connection to use an already-established master secret. Session resumption allows a tag to perform the most expensive parts of the handshake, that is the exchange of certificates and public key cryptographic operations, once and then resume the same session multiple times at much lower computational and transmission cost. This is useful when the tag is likely to transmit telemetry data several times during its journey from supplier to customer: Session resumption may also allow a special server to perform the full EAP-TLS handshake on behalf of the tag so that the session details and credentials can be downloaded to the tag before it commences its journey., 1st para, col., 10.
PNG
media_image4.png
273
632
media_image4.png
Greyscale
PNG
media_image5.png
261
622
media_image5.png
Greyscale
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Akhter-Cisco to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide a particular information in the data of the traffic flow. The data flow would enable transmission of the particular information from one device to another device, and would enable utilizing the data in the system, col., 11, lines 13-50. Akhter-Cisco also discloses wherein the traffic flow further includes unencrypted packet (para 21, 38, figure 1, 3, 4). Shanker-Cisco also discloses inspecting, by the device, the unencrypted packet to determine the cryptographic protocol data of the traffic flow, col., 1, line 58 – col., 2, lines 20.
Goodall, Akhter-Cisco and Shanker-Cisco do not specifically mention about, which is well-known in the art, which AHMED discloses classifying, using a machine learning classifier that is trained on the claimed multiple TLS features the traffic flow based on the cryptographic protocol data of the traffic flow where in the MLC classifies the traffic flow, the machine learning classifier being one of: a) a first machine learning classifier that classifies the traffic flow as a benign flow or malicious flow, a second machine learning classifier that classifies the traffic flow as a tunneled flow or non-tunneled flow, or a third machine learning classifier that classifies the traffic flow as a secure flow or insecure flow; to result in a classification of the traffic flow as a malicious flow, a tunneled flow, or an insecure flow, the traffic flow based on the cryptographic protocol data of the traffic flow, resulting in a classification of the traffic flow, col., 1, line 58 – col., 2, lines 20.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Akhter-Cisco to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide a particular information in the data of the traffic flow. The data flow would enable transmission of the particular information from one device to another device, and would enable utilizing after classification of the data in the system, col., 1, line 58 – col., 2, lines 20.
Goodall, Akhter-Cisco, AHMED and Shanker-Cisco do not specifically mention about, which is well-known in the art, which Yung discloses
taking a remedial action with respect to the traffic flow based on the classification of the traffic flow, col., 23, lines 1-20, col., 20, lines 46-63. Col., 5, line – Col., 6, line23.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Akhter-Cisco to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide a remedial action based on the classification of the flow. The remedial action would enable providing dropping or ignoring the flow. The dropping the flow would prevent any outcome of the further processing of the flow, col., 23, lines 1-20, col., 20, lines 46-63. Col., 5, line – Col., 6, line23.
Conclusion
Classifying data is Classifying data, whether it is done by the telemetry backend system 120 or some other device/software/entity.
The specification contains, The telemetry backend system 120 can classify the flow using a machine learning classifier, para 51. The telemetry backend system 120 can take further action based on the classification, para 51.
However, the specification does not contain, on how the claimed machine learning classifier is indeed trained for all the claimed elements of the claim and classifying differently as compared to the telemetry backend system of para 51 of the specification.
Rather the specification contains that the telemetry backend system itself does the classification and only uses the machine learning classifier without any further details (para 51). As claimed, the specification does not contain machine learning classifier that indeed does more as compared to the “telemetry backend system 120”.
The specification is missing Machine learning (ML) algorithms which are step-by-step computational instructions that enable computers to learn patterns from data (please see all the claimed data of claim 1), make predictions, or take decisions without being explicitly programmed for every task, essentially allowing systems to improve with experience.
As seen in the above rejections, plurality of prior arts of Cisco Technology, such as Shanker et al., 2014/0082204 are part of the above rejections.
Pertinent Reference:
Bisti et al., 20210126858 [0019] In addition to improve customers' satisfaction, the evolution towards Intelligent Transportation Systems (ITS) will require a new generation of services for control, automation and monitoring. The implementation of real-time video surveillance for remote surveillance of trains and the installation of a typically of sensors and actuators for remote diagnostic and telemetry will demand for broadband connectivity that can ensure reliability, customizable QoS (Quality of Service) and high bandwidth.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HARESH PATEL whose telephone number is (571)272-3973. The examiner can normally be reached on M-F 9-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, Jorge L. Ortiz-Criado, can be reached at (571) 272-7624. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HARESH N PATEL/Primary Examiner, Art Unit 2496